Am 27.11.18 um 00:31 schrieb Junio C Hamano: > Johannes Sixt <j...@kdbg.org> writes: > >> Am 26.11.18 um 04:04 schrieb Junio C Hamano: >>> That does not sound right. I would understand it if both lines >>> showed ^M at the end, and only the one on the postimage line had it >>> highlighted as a trailing-whitespace. >> I agree that this is a (small?) weakness. But... >> >>> When we are producing a colored output, we know we are *not* writing >>> for machines, so one way to do it would be to turn CR at the end of >>> the line into two letter "^" "M" sequence on our end, without relying >>> on the terminal and/or the pager. I dunno. >> ... this goes too far, IMO. It is the pager's task to decode control >> characters. > It was tongue-in-cheek suggestion to split a CR into caret-em on our > end, but we'd get essentially the same visual effect if we added a > rule: > > When producing a colored output (not limited to whitespace > error coloring of diff output), insert <RESET> before a CR > that comes immediately before a LF. > > Then, what Frank saw in the troublesome output would become > > <RED> -something <RESET> CR <RESET> LF > <GREEN> +something_new <RESET> <BG_RED> CR <RESET> LF > > and we'll let the existing pager+terminal magic turn that trailing > CR on the preimage line into caret-em, just like the trailing CR on > the postimage line is already shown as caret-em with the current > output. > > And a good thing is that I do not think that new rule is doing any > decode of control chars on our end. We are just producing colored > output normally.
Hmm... I think I now understand what caused the confusion here. It was my mistake: I didn't consider that EOL characters are whitespace characters, too. :/ Nevertheless, I still think that eol (CR, LF) and "normal" whitespace (space, tab) should be distinguished and marked/displayed differently, because they are playing different roles. Your suggestion seems to be a good solution for that. Regards, Frank
