Make the word highlighting colors follow the hunk rather than the line

[Urgau]

While looking at one of the example from #2394, I found my-self a bit perplex at the word highlighting we do.

In particular regarding the color we use which currently follows the color of the line, but that doesn't really make sense, as we want to show what was removed/added between the two part of the hunk, and for that red/green are the standard colors.

This PR therefor changes the word highlighting to always show removed words in red, and added words in green (EDIT: except in a removed line where we use orange, see below). An attempt is made to dim the color for a removed line, where knowing exactly what changed is less relevant.

Light theme:

Currently	This PR
	V1 & V2

Dark theme:

Currently	This PR
	V1 & V2

First commit is the actual change, second commit is a refactor/simplification and the other are the orange change.

Testing: http://localhost:8000/gh-range-diff/rust-lang/miri/98cb1d3d48fa7c8e97994050bfd69e8f3da2a1a7..3f8007e19b8cac3d08fb07579bde3217c58807e4/e0b3afbdd5362aa348abc6661ed6417d1a21f58c..d811aaf958594156e2ce38365b835c361aa88de9

@RalfJung does the new colors make sense to you?

[RalfJung]

For - +/+ + lines, I agree the new colors are strictly better, That's just "changes to the code being added" and it should be red/green.

For + -/- - lines, I am less sure. The green makes it look like there's text being added, but it's really "more text being removed" or "text was added on master". I have no idea how to best indicate that with colors...

Maybe hovering that text could show a tooltip explaining this? Like, "this word was recently added on main; this diff indicates that it is being added to the code removed by this PR".

[Urgau]

A tooltip could work, but requires the user to hover which I think is less than ideal.

Maybe we shouldn't be using green for word added to the removal, but using an intermediate color like orange? It's an intermediate color that doesn't have the meaning of green but is still distinctive.

Slightly modified example:

[RalfJung]

requires the user to hover which I think is less than ideal.

Yeah that was just meant as a way for the user to discover the meaning of the color. Adding it to the legend at the top could also work.

I like the orange! I wonder if - - lines should also use a different color then, though it already is a darker shade of red than - + which is good.

[Urgau]

I wonder if - - lines should also use a different color then, though it already is a darker shade of red than - + which is good.

Yeah, it's already a dimmed red variant, which doesn't like an issue for - -.

I like the orange!

Then that's settled, let's use a orange for + -.

Juts noting that I had to use a slightly darker orange to respect the minimum contrast requirements, still works well IMO.

[RalfJung]

That darker orange does get quite close to the red though. I guess we'll see in practice whether that is a problem.

[fmease]

What if you used the original lighter orange but had the text be black (in the first image it's white)? Wouldn't that uphold a good contrast ratio? Or would that look awful in some way?

[Urgau]

Here the lighter orange with a black text. It's quite good in terms of contrast, but I can tell if it's better than the darker orange with white text.

Maybe it should be even lighter?

Or even more orange?

[RalfJung]

How does it look next to a - - line? Is it odd that one of them uses black text and the other white text?

[Urgau]

It would look like these:

[Urgau]

And the one currently implemented in the PR (with the white text and darker orange), looks like this:

[RalfJung]

It would look like these:

I strongly prefer all of those over the currently implemented one.

Among the alternatives with black text, I have a mild preference for the 3rd variant (strong orange).

[Urgau]

Sure, works for me. Changed it.