From: Frank Schäfer <fschaefer.oss@googlemail.com>
Date: Tue, 27 Nov 2018 20:06:55 GMT
Subject: Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF
Message-ID: <b69f9626-7a6f-521a-1b4e-8b21dc214d93@googlemail.com>
In-Reply-To: <xmqqva4jv2kc.fsf@gitster-ct.c.googlers.com>


Am 27.11.18 um 00:31 schrieb Junio C Hamano:
> 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.

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