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

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Samuel Wales <samologist <at> gmail.com>
Cc: 61396 <at> debbugs.gnu.org
Subject: Re: bug#61396: diff mode could distinguish changed from deleted lines
Date: Mon, 04 Sep 2023 17:06:06 -0400

> in diff mode, with diff -u, if a line in A was added to
> in B, you can't tell by looking at the A version whether it was
> =deleted= in B or =changed= from A to B.  you have to
> manually find it in B and then compare.  here is an example:

It took me a bit of re-reading and thinking to form an opinion, but
IIUC there are 2 distinct issues at play:

- First, `diff -u` (contrary to `diff -c`) does not distinguish between
  `removed/added` and `modified` lines.   And `diff-mode` currently inherits
  this weakness.  I think there's a good case to be made for
  highlighting the "truly added" and "truly removed" lines differently
  from those that are modified.
  I'd argue that a "logical" choice would be to highlight them the same
  way as those parts highlighted by `diff-refine-hunk`
  (i.e. `diff-refine-removed` and `diff-refine-added`) since that's how
  refinement would highlight them if we were to ask it to.

- Second, `diff-refine-hunk` highlights the text actually added and the
  text actually removed within modified lines, but not the place where
  text is added/removed in the other version.
  [ As pointed out by Juri (thanks for Cc'ing me, BTW) this is linked to
    a comment I left in `smerge--refine-highlight-change`, tho that
    comment was thinking of a slightly different feature (namely the
    ability to jump from one version to the other, or the addition of
    a "phantom" cursor highlighting the corresponding place in the other
    version).  ]
  Here the problem is mostly that we don't have a standard way to
  highlight a "place" (which is something that occupies 0 pixels on
  screen).  But we could follow the (not unanimously appreciated) lead
  of `rectangle-mode` and insert a thin (highlighted) visual space to
  mark those places.  That should be not too hard to do, but it would
  have to be optional I think because it'd tend to break alignment, so
  some people may not find the upside significant enough to justify
  the downsides.


-- Stefan

Previous Next

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