Open cqx931 opened 4 years ago
Great catch. I actually encountered this recently when working on tests for the proposed VIA piece. But it seems to me that if we want to get programmatic control over the initial diff processing of supply texts then we could end up using something like jsdiff (entirely independent of git installation). What do you think? I could try plugging this into a branch on the repo and then integrate it with your parser, assuming this is possible. Should I make a fork from 2.0 to do this? If so, you should let me know when best to make the fork, since this would be best after you've finished any on-going parser fixes/changes ... right?
And Sally! Check this out: https://observablehq.com/@shadoof/jsdiff We can definitely make JsDiff work for us. This also shows how great Observable is for quick investigation of packages!
Hi John, this looks great. I think it's safer to fork the master branch at this moment for another process for git diff. As long as the final format of the generated diff file remains more or less the same, it should be a rather easy merge with what ever changes that's going to happen to the parser in 2.0.
Will do ... later in the week.
The current git diff command we are using might ignore lines in the original files if more than three lines in a sequence are the same in the a/b files, with 3 being the default size of context. For a generalized parser to work, we will need to force the context size to match the total length of the document(the longer one) so that the documents won't be chunked by the git diff command.
There might be different ways of doing this if we ended up using other tools, but here is a reference for git diff: https://stackoverflow.com/questions/13627598/how-to-get-git-diff-with-full-context