From: Johannes Sixt <j6t@kdbg.org>
Date: Tue, 27 Nov 2018 18:15:31 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: <3e24a770-47fc-50e4-d757-1e4a28dcd019@kdbg.org>
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:
>> ... 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.

I wouldn't want that to happen for all output (context lines, - lines, + 
lines): I really am not interested to see all the CRs in my CRLF files.

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

But we already have it, as Brian pointed out:

    git diff --ws-error-highlight=old,new

or by setting diff.wsErrorHighlight accordingly.

-- Hannes