Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF

[Junio C Hamano <gitster@pobox.com>]

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