GNU bug report logs - #61396
diff mode could distinguish changed from deleted lines

Previous Next

Full log

Message #140 received at 61396 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 61396 <at> debbugs.gnu.org,
 Samuel Wales <samologist <at> gmail.com>
Subject: Re: bug#61396: diff mode could distinguish changed from deleted lines
Date: Sun, 01 Oct 2023 21:53:02 +0300

>>> I have been bitten several times in the past when going through largish
>>> diffs where I overlooked important things in the added/removed parts
>>> because they were colored the same was as the unchanged parts of
>>> changed lines and so I just glossed over them.
>>
>> I realized now the same problem exists even without color highlighting
>> at all.
>
> No, the problem I describe is specific to the "refined" diff
> highlighting: I rely on this highlighting to tell me what has "really"
> been changed, yet it's not applied to lines that are "just added" or
> "just removed" so I end up skipping over them unwittingly because they
> are highlighted identically to the *unchanged* parts of those lines
> which are otherwise changed.

AFAICS, GitHub tries to address this problem by using less refining:
only changes inside a single line are refined.  I don't like this,
but maybe such an option could help at least by not promising that
all added/removed text is using the refined diff highlighting.

On the other extreme, your option `diff-refine-nonmodified`
could consistently highlight all added/removed text,
but such highlighting is too "heavy".

So a new option could be like font-lock levels,
and we need to find a balance for the default value.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.