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

["Frank Schäfer" <fschaefer.oss@googlemail.com>]

Am 27.11.18 um 19:15 schrieb Johannes Sixt:
> 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.
... but that also turns on displaying normal space/tab errors in removed
lines.
So to make both of us happy, we would need separate switches.

Any chance this can be done easily enough ?

Regards,
Frank