git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: Junio C Hamano <gitster@pobox.com>, Johannes Sixt <j6t@kdbg.org>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>, git@vger.kernel.org
Subject: Re: BUG: CR marker ^M doesn't show up in '-' lines of diffs when the ending of the removed line is CR+LF
Date: Tue, 27 Nov 2018 21:06:55 +0100	[thread overview]
Message-ID: <b69f9626-7a6f-521a-1b4e-8b21dc214d93@googlemail.com> (raw)
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




  parent reply	other threads:[~2018-11-27 20:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-23 18:19 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
2018-11-23 21:47 ` Johannes Sixt
2018-11-24 14:51   ` Frank Schäfer
2018-11-24 15:25     ` Torsten Bögershausen
2018-11-24 22:07     ` Johannes Sixt
2018-11-25 14:03       ` Frank Schäfer
2018-11-25 21:39         ` Johannes Sixt
2018-11-26  4:02           ` Junio C Hamano
     [not found]           ` <xmqqzhtwzghr.fsf@gitster-ct.c.googlers.com>
2018-11-26 19:49             ` Johannes Sixt
2018-11-26 23:31               ` Junio C Hamano
2018-11-27 18:15                 ` Johannes Sixt
2018-11-27 20:09                   ` Frank Schäfer
2018-11-29  2:11                   ` Junio C Hamano
2018-12-02 19:31                     ` Frank Schäfer
2018-12-02 21:22                       ` Johannes Sixt
2018-12-05 19:29                         ` Frank Schäfer
2018-12-05 21:31                           ` Johannes Sixt
2018-12-03  1:15                       ` Junio C Hamano
2018-12-05 19:43                         ` Frank Schäfer
2018-12-06  0:58                           ` Junio C Hamano
2018-12-06 18:42                             ` Frank Schäfer
2018-11-27 20:06                 ` Frank Schäfer [this message]
2018-11-25 23:50         ` brian m. carlson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b69f9626-7a6f-521a-1b4e-8b21dc214d93@googlemail.com \
    --to=fschaefer.oss@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).