Johannes Sixt <[email protected]> writes:
> But incorrect whitespace is never highlighted in removed lines, why
> should CR be an exception?
> ...
> Same here for other cases, for example
>
> -something<SP>
> +something
>
> will not have on obvious indicator that whitespace was corrected.
All correct, but misses one point in Frank's original report, which
observed
-something
+something_new^M
with ^M highlighted for whitespace error. The highlighting is
correct. But notice lack of caret-em on the preimage line?
It turns out that we show something like this
<RED>-something<RESET> CR LF
for the preimage line, while showing something like this
<GREEN>+something_new<RESET><BG-RED> CR <RESET> LF
for the postimage line.
Because CR on the postimage line, thanks to highlighting, appears
alone separate from the LF, it is shown as two-letter caret-em
sequence to the user.
On the other hand, because CR and LF appear next to each other on
the preimage line, the pager and/or the terminal behaves as if CR is
not even there and that is where Frank's complaint comes from, I think.
The code is doing the right thing by showing CR, but it is hidden by
the pager and/or the terminal.
