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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Am 27.11.18 um 00:31 schrieb Junio C Hamano:
Johannes Sixt <j6t@xxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux