🐛 Sub-optimal diff highlighting in a simple change

[waldyrious]

Adding a separate issue for the topic originally mentioned at #245:

Here's the delta output (notice the within-line highlights of removed/added text):

And here's what diff-so-fancy/diff-highlight shows (not the best possible result, but a better default):

Finally, here's delta with --word-diff-regex = ., which is the most accurate highlighting:

I'd expect delta to provide better highlighting by default — not necessarily the best possible result shown above; doing the same as diff-highlight would have been satisfactory.

[waldyrious]

Responding to @dandavison's comment in #245:

Do you think diff-highlight and diff-so-fancy in delta should default to using the original, simpler, diff highlight algorithm? On the one hand there is something appealing in being able to say that delta --diff-highlight aims for a pixel-for-pixel emulation, and OTOH I do find that the dynamic programming algorithm often gives more helpful results.

I would prefer the diff parsing algorithm to be kept orthogonal to the display style. diff-highlight's algorithm won't be better than delta's all the time (or, I imagine, most of the time), so it would be a disservice to users to default to a worse (on average) algorithm only because they prefer a given visual style.

[waldyrious]

I just came across a similar issue, where diff-highlight's algorithm produces a better output than delta's:

delta:

diff-highlight:

There is indeed, in semantic terms, no shared content between the two larger hunks, so diff-highlight is "right"* to not highlight any content in them; but to be fair, markup characters and whitespace are shared between the hunks, by the very nature of HTML. Maybe delta's algorithm could try to ignore such markup characters (and maybe whitespace) when calculating the similarity between two blocks?

_{* Not by its merits, but for the same reason a stopped clock is right twice a day — it just doesn't try to match differently-sized hunks.}