Johannes Sixt <j6t@xxxxxxxx> 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.
