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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 26, 2018, 23:31 UTC
Message-ID: <xmqqva4jv2kc.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <f06b734a-fc8e-221a-c983-f2ab9daba17f@kdbg.org>

Johannes Sixt <j6t@kdbg.org> writes:

Show 15 quoted lines

> 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.