bug#61396: diff mode could distinguish changed from deleted lines

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

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:

  -now is the time
  +now is the time FOR ALL GOOD MEN

the - line is in del face.  there is no indication on that
line that the line is not deleted.

if the lines are separated sufficiently, it is not obvious
to the user whether it is a line that was deleted, or, as
above, added to.  the del face is therefore ambiguous and can be
potentially misleading to the user.

===

the only thing that tells you non-confusingly that A was
changed, or where, is if you look at B.

this is not practical when there are many lines.

a fix is to have a different face for changed lines.  i
suggest a muted bg face.  another fix is to stick a colored
marker INDICATOR in A where changes in B exist.

  -now is the time^
  +now is the time FOR ALL GOOD MEN

where ^ is a colored marker -- actually just a changed bg
for the newline in this case would work, but i don't think
emacs supports that.

thank you.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

> a fix is to have a different face for changed lines.  i
> suggest a muted bg face.  another fix is to stick a colored
> marker INDICATOR in A where changes in B exist.
>
>   -now is the time^
>   +now is the time FOR ALL GOOD MEN
>
> where ^ is a colored marker -- actually just a changed bg
> for the newline in this case would work, but i don't think
> emacs supports that.

We have a dedicated face to indicate the changed lines.
Its name is 'diff-changed' and it can be used for context diffs
that have a special indicator '!' at the beginning of changed lines.
Is it possible to output the same indicator for unified diffs?

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

it is an interesting idea to change the gutter from - to !, but i'm
not sure this is ok for diff -u, i think it could maybe break things?,
and it would not distinguish - from +.

On 2/10/23, Juri Linkov <juri@linkov.net> wrote:
>> a fix is to have a different face for changed lines.  i
>> suggest a muted bg face.  another fix is to stick a colored
>> marker INDICATOR in A where changes in B exist.
>>
>>   -now is the time^
>>   +now is the time FOR ALL GOOD MEN
>>
>> where ^ is a colored marker -- actually just a changed bg
>> for the newline in this case would work, but i don't think
>> emacs supports that.
>
> We have a dedicated face to indicate the changed lines.
> Its name is 'diff-changed' and it can be used for context diffs
> that have a special indicator '!' at the beginning of changed lines.
> Is it possible to output the same indicator for unified diffs?
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

highlighting for all good men in + is the current case.

i am proposing that this is insufficient.  - has no indication or
highlighting other than del face and it is not a deleted line.

On 2/10/23, Samuel Wales <samologist@gmail.com> wrote:
> it is an interesting idea to change the gutter from - to !, but i'm
> not sure this is ok for diff -u, i think it could maybe break things?,
> and it would not distinguish - from +.
>
> On 2/10/23, Juri Linkov <juri@linkov.net> wrote:
>>> a fix is to have a different face for changed lines.  i
>>> suggest a muted bg face.  another fix is to stick a colored
>>> marker INDICATOR in A where changes in B exist.
>>>
>>>   -now is the time^
>>>   +now is the time FOR ALL GOOD MEN
>>>
>>> where ^ is a colored marker -- actually just a changed bg
>>> for the newline in this case would work, but i don't think
>>> emacs supports that.
>>
>> We have a dedicated face to indicate the changed lines.
>> Its name is 'diff-changed' and it can be used for context diffs
>> that have a special indicator '!' at the beginning of changed lines.
>> Is it possible to output the same indicator for unified diffs?
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 10/02/2023 05:25, Samuel Wales wrote:
> a fix is to have a different face for changed lines.  i
> suggest a muted bg face.  another fix is to stick a colored
> marker INDICATOR in A where changes in B exist.
> 
>    -now is the time^
>    +now is the time FOR ALL GOOD MEN
> 
> where ^ is a colored marker -- actually just a changed bg
> for the newline in this case would work, but i don't think
> emacs supports that.

Doesn't the "refinements" feature serve the same purpose?

In my testing, "FOR ALL GOOD MEN" is additionally highlighted with the 
diff-refine-added face. Which adds an emphasized background.

bug#61396: diff mode could distinguish changed from deleted lines

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Is this bug in Emacs, or is it in diff?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

i think it is in diff-mode in emacs, at least when it is displaying diff -u.

in particular, the idea is whether it can be solved using emacs
features such as faces.

it is true that diff and friends can often do colors, but to my
knowledge, diff-mode uses raw text as its input.


On 2/10/23, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Is this bug in Emacs, or is it in diff?
>
> --
> Dr Richard Stallman (https://stallman.org)
> Chief GNUisance of the GNU Project (https://gnu.org)
> Founder, Free Software Foundation (https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

> i think it is in diff-mode in emacs, at least when it is displaying diff -u.
>
> in particular, the idea is whether it can be solved using emacs
> features such as faces.
>
> it is true that diff and friends can often do colors, but to my
> knowledge, diff-mode uses raw text as its input.

But diff has no color for changed lines, only for added/removed lines:

'--palette=PALETTE'
     Specify what color palette to use when colored output is enabled.
     It defaults to 'rs=0:hd=1:ad=32:de=31:ln=36' for red deleted lines,
     green added lines, cyan line numbers, bold header.

     Supported capabilities are as follows.

     'ad=32'
          SGR substring for added lines.  The default is green foreground.

     'de=31'
          SGR substring for deleted lines.  The default is red foreground.

     'hd=1'
          SGR substring for chunk header.  The default is bold foreground.

     'ln=36'
          SGR substring for line numbers.  The default is cyan foreground.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

this is a bug against emacs diff-mode.

diff is not responsible for diff-mode colors.  diff-mode is.


On 2/11/23, Juri Linkov <juri@linkov.net> wrote:
>> i think it is in diff-mode in emacs, at least when it is displaying diff
>> -u.
>>
>> in particular, the idea is whether it can be solved using emacs
>> features such as faces.
>>
>> it is true that diff and friends can often do colors, but to my
>> knowledge, diff-mode uses raw text as its input.
>
> But diff has no color for changed lines, only for added/removed lines:
>
> '--palette=PALETTE'
>      Specify what color palette to use when colored output is enabled.
>      It defaults to 'rs=0:hd=1:ad=32:de=31:ln=36' for red deleted lines,
>      green added lines, cyan line numbers, bold header.
>
>      Supported capabilities are as follows.
>
>      'ad=32'
>           SGR substring for added lines.  The default is green foreground.
>
>      'de=31'
>           SGR substring for deleted lines.  The default is red foreground.
>
>      'hd=1'
>           SGR substring for chunk header.  The default is bold foreground.
>
>      'ln=36'
>           SGR substring for line numbers.  The default is cyan foreground.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 12/02/2023 02:52, Samuel Wales wrote:
> this is a bug against emacs diff-mode.
> 
> diff is not responsible for diff-mode colors.  diff-mode is.

See the user option 'diff-refine'.

Coloring several lines using a "change" face, OTOH, can lose (or at 
least conceal) information: which lines were actually deleted, and which 
were added.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

i do not understand your response.  where is this option?  what does
it do for diff-mode?  thanks.

i feel this thread is going all over the place without addressing the
op.  is the op difficult to understand?  i tried my best.


On 2/11/23, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 12/02/2023 02:52, Samuel Wales wrote:
>> this is a bug against emacs diff-mode.
>>
>> diff is not responsible for diff-mode colors.  diff-mode is.
>
> See the user option 'diff-refine'.
>
> Coloring several lines using a "change" face, OTOH, can lose (or at
> least conceal) information: which lines were actually deleted, and which
> were added.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 12/02/2023 03:07, Samuel Wales wrote:
> i do not understand your response.  where is this option?  what does
> it do for diff-mode?  thanks.

It's in diff-mode.el. You can always find the exact place of definition 
from the Customize interface.

> i feel this thread is going all over the place without addressing the
> op.  is the op difficult to understand?  i tried my best.

This is the feature which colors "FOR ALL GOOD MEN" from your example 
with a different background. It's enabled by default.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

> This is the feature which colors "FOR ALL GOOD MEN" from your example with a different background. It's enabled by default.

you are referring to coloring B.  this bug report is referring to
coloring or indicating A.  it is not referring to coloring B.  those
are orthogonal.


On 2/11/23, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 12/02/2023 03:07, Samuel Wales wrote:
>> i do not understand your response.  where is this option?  what does
>> it do for diff-mode?  thanks.
>
> It's in diff-mode.el. You can always find the exact place of definition
> from the Customize interface.
>
>> i feel this thread is going all over the place without addressing the
>> op.  is the op difficult to understand?  i tried my best.
>
> This is the feature which colors "FOR ALL GOOD MEN" from your example
> with a different background. It's enabled by default.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 12/02/2023 04:12, Samuel Wales wrote:
>> This is the feature which colors "FOR ALL GOOD MEN" from your example with a different background. It's enabled by default.
> you are referring to coloring B.  this bug report is referring to
> coloring or indicating A.  it is not referring to coloring B.  those
> are orthogonal.

There is nothing to color in A in this example.

But if the change deleted some text, there would be indication in A. 
Same if the change both deleted and added text (making it a full-blown 
"change").

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

now we are closer to being on the same page.

> There is nothing to color in A in this example.

that is the problem.  [approximately that is; see op for references to
indicators and faces.]


On 2/11/23, Dmitry Gutov <dgutov@yandex.ru> wrote:
> On 12/02/2023 04:12, Samuel Wales wrote:
>>> This is the feature which colors "FOR ALL GOOD MEN" from your example
>>> with a different background. It's enabled by default.
>> you are referring to coloring B.  this bug report is referring to
>> coloring or indicating A.  it is not referring to coloring B.  those
>> are orthogonal.
>
> There is nothing to color in A in this example.
>
> But if the change deleted some text, there would be indication in A.
> Same if the change both deleted and added text (making it a full-blown
> "change").
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

> this is a bug against emacs diff-mode.
>
> diff is not responsible for diff-mode colors.  diff-mode is.

You can use such a heuristics that when the region with deleted lines
borders the region with added lines this means that both regions show
the changed lines.  So adjacent regions in the hunk = changed lines,
disconnected regions of added or deleted lines = separate additions/deletions.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

i'm not sure that will work with alternate presentatin f difflll.
what woul dbe good is for the internal diffing to notate not merely
additions and deleteions but also absence of addionts.  a marker that
something will be deleted. no matter where.


On 2/12/23, Juri Linkov <juri@linkov.net> wrote:
>> this is a bug against emacs diff-mode.
>>
>> diff is not responsible for diff-mode colors.  diff-mode is.
>
> You can use such a heuristics that when the region with deleted lines
> borders the region with added lines this means that both regions show
> the changed lines.  So adjacent regions in the hunk = changed lines,
> disconnected regions of added or deleted lines = separate
> additions/deletions.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

>> You can use such a heuristics that when the region with deleted lines
>> borders the region with added lines this means that both regions show
>> the changed lines.  So adjacent regions in the hunk = changed lines,
>> disconnected regions of added or deleted lines = separate
>> additions/deletions.
>
> i'm not sure that will work with alternate presentatin f difflll.
> what woul dbe good is for the internal diffing to notate not merely
> additions and deleteions but also absence of addionts.  a marker that
> something will be deleted. no matter where.

This depends on the definition of changed lines.  And what is their
granularity.  To me and to the diff command, the changed lines form
a block, and when there are some changes (additions or deletions) on lines
inside that block, then the whole block of lines is declared as changed.

But it seems that you want to check words on every line in the block
for changes, and to categorize every line to three groups:

1. if on the line marked with the '-' indicator, all words are marked
   by refinement as deleted (ignoring whitespace), or there are no
   refinements on the standalone nonadjacent '-' line, declare
   the whole line as deleted;
2. if on the line marked with the '+' indicator, all words are marked by
   refinement as added (ignoring whitespace), or there are no refinements
   on the standalone nonadjacent '+' line, declare the whole line as added;
3. Otherwise, it's changed.

Still it's impossible to classify lines even with such elaborate definition.
For example,

@@ -1,2 +3,4 @@
   '(function-1
     function-2
-    function-3)
+    function-3
+    function-4)

You might want to consider the line with "function-4" added, but its closing paren
comes from the line with "function-3", so it's a changed line, not added.

Probably we can't do anything better than what the current word refinement does.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

below.

On 2/12/23, Juri Linkov <juri@linkov.net> wrote:
> But it seems that you want to check words on every line in the block
> for changes, and to categorize every line to three groups:

i do not want what you described.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

for purposes of showing what i mean, suppose you have approximately like:

--- ...
+++ ...
@@ ... @@
-1 hmm
-2 hi
-3
+1 really?
+2 there
+3 for all good men

[btw this is all merely an arbitrary quote from history from a diff tutorial.]

now what does diff-mode do with this?  it usually does a pretty good
job.  sometimes there are glitches.

diff-mode leaves 1 2 3 characters alone.  it uses diff-removed and
diff-added for them.

--- ...
+++ ...
@@ -104,3 +104,3 @@
-1 HMM
-2 HI
-3
+1 REALLY?
+2 THERE
+3 FOR ALL GOOD MEN

this output is correct.  hmm and really are different and hi and there
are different.

line 3 is special.  the - and + moieties are different.  but they are
different specially.  that is because in - there is an /absence/ of
for all good men.  diff-mode does not show absence.  there is no
marker saying "soiemthing is absent".

in - for line 3 it is also special for the user interpretation.  it
could indicate that the line is entirely unique to A according to
diff-mode.  OR it could indicate that it is in both A and B but
different in B like 1 and 2.

this is ambiguous.  an indicator reovs ambiguity.  the idea is merely
one thing: indicating absence.

the same idea is true of a hypothetical opposite case where 3 in +,
not -, lacks an indicator.

can it be done?  naturally, all of this is heuristic-ish to begin
with, insofar as human interpretation is concerned.  that's why we
have difftastic and histogram and all that stuff.  the solution --
indicators for absence -- will also be.  that is ok.

adjacency and blocks are not likely to be the solution.  if it is
elaborate or special-cased, then it is likely impractical.


On 2/12/23, Samuel Wales <samologist@gmail.com> wrote:
> below.
>
> On 2/12/23, Juri Linkov <juri@linkov.net> wrote:
>> But it seems that you want to check words on every line in the block
>> for changes, and to categorize every line to three groups:
>
> i do not want what you described.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

so basically,

  -this is a line that ^looks deleted, but it is changed
...
  +this is a line that REALLY looks deleted, but it is changed

what is not indicated for the user is at the ^.  i woul dlike it if
diff mode if possible showed that text was deleted there.

this allows you to look at only the - line and know that it is not a
deleted line, possibly even mistakenly, but rather is part of a cange
set, namely it and the + version of hte same line.  this would reduce
user confusion considerably.

On 2/12/23, Samuel Wales <samologist@gmail.com> wrote:
> for purposes of showing what i mean, suppose you have approximately like:
>
> --- ...
> +++ ...
> @@ ... @@
> -1 hmm
> -2 hi
> -3
> +1 really?
> +2 there
> +3 for all good men
>
> [btw this is all merely an arbitrary quote from history from a diff
> tutorial.]
>
> now what does diff-mode do with this?  it usually does a pretty good
> job.  sometimes there are glitches.
>
> diff-mode leaves 1 2 3 characters alone.  it uses diff-removed and
> diff-added for them.
>
> --- ...
> +++ ...
> @@ -104,3 +104,3 @@
> -1 HMM
> -2 HI
> -3
> +1 REALLY?
> +2 THERE
> +3 FOR ALL GOOD MEN
>
> this output is correct.  hmm and really are different and hi and there
> are different.
>
> line 3 is special.  the - and + moieties are different.  but they are
> different specially.  that is because in - there is an /absence/ of
> for all good men.  diff-mode does not show absence.  there is no
> marker saying "soiemthing is absent".
>
> in - for line 3 it is also special for the user interpretation.  it
> could indicate that the line is entirely unique to A according to
> diff-mode.  OR it could indicate that it is in both A and B but
> different in B like 1 and 2.
>
> this is ambiguous.  an indicator reovs ambiguity.  the idea is merely
> one thing: indicating absence.
>
> the same idea is true of a hypothetical opposite case where 3 in +,
> not -, lacks an indicator.
>
> can it be done?  naturally, all of this is heuristic-ish to begin
> with, insofar as human interpretation is concerned.  that's why we
> have difftastic and histogram and all that stuff.  the solution --
> indicators for absence -- will also be.  that is ok.
>
> adjacency and blocks are not likely to be the solution.  if it is
> elaborate or special-cased, then it is likely impractical.
>
>
> On 2/12/23, Samuel Wales <samologist@gmail.com> wrote:
>> below.
>>
>> On 2/12/23, Juri Linkov <juri@linkov.net> wrote:
>>> But it seems that you want to check words on every line in the block
>>> for changes, and to categorize every line to three groups:
>>
>> i do not want what you described.
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Robert Pluim]

>>>>> On Sat, 22 Jul 2023 23:04:10 -0700, Samuel Wales <samologist@gmail.com> said:

    Samuel> so basically,
    Samuel>   -this is a line that ^looks deleted, but it is changed
    Samuel> ...
    Samuel>   +this is a line that REALLY looks deleted, but it is changed

    Samuel> what is not indicated for the user is at the ^.  i woul dlike it if
    Samuel> diff mode if possible showed that text was deleted there.

Thatʼs what diff-mode does, if `diff-refine' is non-nil (which is the
default nowadays), by applying the `diff-refine-removed' face.

Robert
-- 

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

in 27.1 i am not getting this.

i am getting this:

file aaa: now is the time
file bbb: now is the time for all good men

now you diff this
with result:

line 1: -now is the time
line 2: +now is the time /for all good men/

line 1 does not indicate that anything was deleted.  i request that
diff-mode do so, if possible.  line 2 is correct.

what i need is an indication that something is lacking in line 1.  i
do not need the text that is lacking.


On 7/24/23, Robert Pluim <rpluim@gmail.com> wrote:
>>>>>> On Sat, 22 Jul 2023 23:04:10 -0700, Samuel Wales
>>>>>> <samologist@gmail.com> said:
>
>     Samuel> so basically,
>     Samuel>   -this is a line that ^looks deleted, but it is changed
>     Samuel> ...
>     Samuel>   +this is a line that REALLY looks deleted, but it is changed
>
>     Samuel> what is not indicated for the user is at the ^.  i woul dlike it
> if
>     Samuel> diff mode if possible showed that text was deleted there.
>
> Thatʼs what diff-mode does, if `diff-refine' is non-nil (which is the
> default nowadays), by applying the `diff-refine-removed' face.
>
> Robert
> --
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

applying a face to line 1 does not make sense in this context.  there
is no text to apply a face to because it was deleted.

On 7/24/23, Samuel Wales <samologist@gmail.com> wrote:
> in 27.1 i am not getting this.
>
> i am getting this:
>
> file aaa: now is the time
> file bbb: now is the time for all good men
>
> now you diff this
> with result:
>
> line 1: -now is the time
> line 2: +now is the time /for all good men/
>
> line 1 does not indicate that anything was deleted.  i request that
> diff-mode do so, if possible.  line 2 is correct.
>
> what i need is an indication that something is lacking in line 1.  i
> do not need the text that is lacking.
>
>
> On 7/24/23, Robert Pluim <rpluim@gmail.com> wrote:
>>>>>>> On Sat, 22 Jul 2023 23:04:10 -0700, Samuel Wales
>>>>>>> <samologist@gmail.com> said:
>>
>>     Samuel> so basically,
>>     Samuel>   -this is a line that ^looks deleted, but it is changed
>>     Samuel> ...
>>     Samuel>   +this is a line that REALLY looks deleted, but it is
>> changed
>>
>>     Samuel> what is not indicated for the user is at the ^.  i woul dlike
>> it
>> if
>>     Samuel> diff mode if possible showed that text was deleted there.
>>
>> Thatʼs what diff-mode does, if `diff-refine' is non-nil (which is the
>> default nowadays), by applying the `diff-refine-removed' face.
>>
>> Robert
>> --
>>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Robert Pluim]

>>>>> On Mon, 24 Jul 2023 16:39:04 -0700, Samuel Wales <samologist@gmail.com> said:

    Samuel> applying a face to line 1 does not make sense in this context.  there
    Samuel> is no text to apply a face to because it was deleted.

Ah, I got the lines the wrong way round. I donʼt think diff mode
supports this (but there is an indication on line 2 of which bit was
added)

Robert
-- 

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

yesk diff mode does not support this.

can it?

On 7/25/23, Robert Pluim <rpluim@gmail.com> wrote:
>>>>>> On Mon, 24 Jul 2023 16:39:04 -0700, Samuel Wales
>>>>>> <samologist@gmail.com> said:
>
>     Samuel> applying a face to line 1 does not make sense in this context.
> there
>     Samuel> is no text to apply a face to because it was deleted.
>
> Ah, I got the lines the wrong way round. I donʼt think diff mode
> supports this (but there is an indication on line 2 of which bit was
> added)
>
> Robert
> --
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

can anybody think of a straightforward workaround for this as
described below that the user can do if diff-mode does not do it
[which it does not]?

i am pretty unsure what would do this.

thank you.

On 7/22/23, Samuel Wales <samologist@gmail.com> wrote:
> so basically,
>
>   -this is a line that ^looks deleted, but it is changed
> ...
>   +this is a line that REALLY looks deleted, but it is changed

i.e. a mechanism to put a missing-text indicator where ^ is?

>
> what is not indicated for the user is at the ^.  i woul dlike it if
> diff mode if possible showed that text was deleted there.
>
> this allows you to look at only the - line and know that it is not a
> deleted line, possibly even mistakenly, but rather is part of a cange
> set, namely it and the + version of hte same line.  this would reduce
> user confusion considerably.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 11/08/2023 02:56, Samuel Wales wrote:
> can anybody think of a straightforward workaround for this as
> described below that the user can do if diff-mode does not do it
> [which it does not]?

If the diff-refine mechanism produces the kind of information you want, 
but does not show it the way you want, it should be possible to hack it 
to add some other highlights, etc, that are missing.

I don't have a patch for you, or an existing variable, though.

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

>   -this is a line that ^looks deleted, but it is changed
> ...
>   +this is a line that REALLY looks deleted, but it is changed
>
> what is not indicated for the user is at the ^.  i would like it if
> diff mode if possible showed that text was deleted there.

Thanks for the feature request, this would be a very useful feature.
There is already a TODO item for implementing it:

  (defun smerge--refine-highlight-change (beg match-num1 match-num2 props)
    ;; TODO: Add a property pointing to the corresponding text in the
    ;; other region.

Maybe Stefan could suggest a hint on how better to proceed.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

this problem is highly noticeable for me.

i am thinking just a thin vertical bar for removed text would be
possible and work well.

there is something i do that makes the problem even more noticeable.
imagine you want to improve the diff for human consumption as follows.
you keep the top --- +++ and first @@ lines.  then you group by
polarity.  what i mean by group by polarity is, you sort by - or + but
not by anything else.  that is, you put all - lines before + lines,
but you do not change the sequence of lines within - or +.  this might
sound strange but it makes for much better understandability in many
cases.

glitches that show up in normal diff-mode are often removed.  it is a
highly useful diff viewing experience, but of course is useless for
patches and so on.

doing this takes all the diff hunks and smushes them together.
deliberately.  you can look at - and know whether you have deleted
anything.  but because of this bug, you don't know whether it is a
true deletion, or whether you added something to the line in + unless
you also look at +.  this is in principle fixable.

however, you do not need to do this to notice the problem.  a big hunk
will have this problem also in many cases.

On 2/9/23, Samuel Wales <samologist@gmail.com> wrote:
> 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:
>
>   -now is the time
>   +now is the time FOR ALL GOOD MEN
>
> the - line is in del face.  there is no indication on that
> line that the line is not deleted.
>
> if the lines are separated sufficiently, it is not obvious
> to the user whether it is a line that was deleted, or, as
> above, added to.  the del face is therefore ambiguous and can be
> potentially misleading to the user.
>
> ===
>
> the only thing that tells you non-confusingly that A was
> changed, or where, is if you look at B.
>
> this is not practical when there are many lines.
>
> a fix is to have a different face for changed lines.  i
> suggest a muted bg face.  another fix is to stick a colored
> marker INDICATOR in A where changes in B exist.
>
>   -now is the time^
>   +now is the time FOR ALL GOOD MEN
>
> where ^ is a colored marker -- actually just a changed bg
> for the newline in this case would work, but i don't think
> emacs supports that.
>
> thank you.
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

the ability to jump would also be useful.

-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

thank you for everybody's answers, and for stephan's reply which makes sense.

On 9/4/23, Samuel Wales <samologist@gmail.com> wrote:
> the ability to jump would also be useful.
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> - 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.

The patch below does that for the case of unified diffs.
I kind of like the result.
It's not quite ready for prime time, but I'd be interested to hear what
other people think about it.


        Stefan


diff --git a/lisp/vc/diff-mode.el b/lisp/vc/diff-mode.el
index e8f22622935..d503652a9cf 100644
--- a/lisp/vc/diff-mode.el
+++ b/lisp/vc/diff-mode.el
@@ -2314,6 +2308,17 @@ diff-refine-hunk
             (end (progn (diff-end-of-hunk) (point))))
         (diff--refine-hunk beg end)))))
 
+(defun diff--refine-propertize (beg end face)
+  (let ((ol (make-overlay beg end)))
+    (overlay-put ol 'diff-mode 'fine)
+    (overlay-put ol 'evaporate t)
+    (overlay-put ol 'face face)))
+
+(defcustom diff-refine-nonmodified t
+  "If non-nil also highlight the added/removed lines.
+This is currently only implemented for `unified' diffs."
+  :type 'boolean)
+
 (defun diff--refine-hunk (start end)
   (require 'smerge-mode)
   (goto-char start)
@@ -2328,18 +2333,26 @@ diff--refine-hunk
     (goto-char beg)
     (pcase style
       ('unified
-       (while (re-search-forward "^-" end t)
+       (while (re-search-forward "^[-+]" end t)
          (let ((beg-del (progn (beginning-of-line) (point)))
                beg-add end-add)
-           (when (and (diff--forward-while-leading-char ?- end)
-                      ;; Allow for "\ No newline at end of file".
-                      (progn (diff--forward-while-leading-char ?\\ end)
-                             (setq beg-add (point)))
-                      (diff--forward-while-leading-char ?+ end)
-                      (progn (diff--forward-while-leading-char ?\\ end)
-                             (setq end-add (point))))
+           (cond
+            ((eq (char-after) ?+)
+             (diff--forward-while-leading-char ?+ end)
+             (diff--refine-propertize beg-del (point) 'diff-refine-added))
+            ((and (diff--forward-while-leading-char ?- end)
+                  ;; Allow for "\ No newline at end of file".
+                  (progn (diff--forward-while-leading-char ?\\ end)
+                         (setq beg-add (point)))
+                  (diff--forward-while-leading-char ?+ end)
+                  (progn (diff--forward-while-leading-char ?\\ end)
+                         (setq end-add (point))))
              (smerge-refine-regions beg-del beg-add beg-add end-add
-                                    nil #'diff-refine-preproc props-r props-a)))))
+                                    nil #'diff-refine-preproc props-r props-a))
+            (t ;; If we're here, it's because
+             ;; (diff--forward-while-leading-char ?+ end) failed.
+             (diff--refine-propertize beg-del (point) 'diff-refine-removed)
+             )))))
       ('context
        (let* ((middle (save-excursion (re-search-forward "^---" end t)))
               (other middle))

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 13/09/2023 01:11, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>> - 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.
> The patch below does that for the case of unified diffs.
> I kind of like the result.
> It's not quite ready for prime time, but I'd be interested to hear what
> other people think about it.

Not quite ready indeed: the new option is unused (implied to be t, I guess).

Just a single piece of feedback: I get where the idea is coming from 
(and it's good in theory), but I'm not loving the added bright spots of 
color where there previously were just toned down lighter backgrounds.

If it were indicated differently somehow (though I'm not sure how), 
perhaps I'd like it more. As it is, though, the added value (quite minor 
since it's easy to see which hunk is "pure addition" already) doesn't 
seem to balance out the inconvenience.

bug#61396: diff mode could distinguish changed from deleted lines

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> Not quite ready indeed: the new option is unused (implied to be t, I guess).

Oops :-)
This said, it's not its only problem: the name of that var sucks as well.

> Just a single piece of feedback: I get where the idea is coming from (and
> it's good in theory), but I'm not loving the added bright spots of color
> where there previously were just toned down lighter backgrounds.

Yeah, I'm unsure about that.  I'm also somewhat annoyed by the extra
attention it brings to those "boring" additions and removals, but I'm
wondering if it's really because I want them to look more dull or if
it's just because of habit.

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.

> If it were indicated differently somehow (though I'm not sure how), perhaps
> I'd like it more. As it is, though, the added value (quite minor since it's
> easy to see which hunk is "pure addition" already) doesn't seem to balance
> out the inconvenience.

Yeah, maybe I'd prefer colors that are halfway between
`diff-added/removed` and `diff-refine-added/removed`?
[ Wish we had dynamically-computed face colors for that.  ]


        Stefan

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

apologies for getting your name wrong earlier.  of course i knew it is stefan.

instead of whole line, a truly deleted/added line could maybe have an
inverse video gutter character indicator [i.e. -+] face?

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 3321 bytes --]

On 13/09/2023 17:51, Stefan Monnier wrote:
>> Not quite ready indeed: the new option is unused (implied to be t, I guess).
> 
> Oops :-)
> This said, it's not its only problem: the name of that var sucks as well.
> 
>> Just a single piece of feedback: I get where the idea is coming from (and
>> it's good in theory), but I'm not loving the added bright spots of color
>> where there previously were just toned down lighter backgrounds.
> 
> Yeah, I'm unsure about that.  I'm also somewhat annoyed by the extra
> attention it brings to those "boring" additions and removals, but I'm
> wondering if it's really because I want them to look more dull or if
> it's just because of habit.

My view on this, is it's good to have decent contrast of foreground to 
background, more-or-less constant across the program's UI. The bright 
spots are kind of annoying because of the color calling for attention, 
but it also lowers the said contrast.

When the syntactic fontification of hunks was added (bug#33567) we went 
through a couple of rounds of toning down the existing backgrounds, so 
that they are less in-your-face, while still easy to discern. Simply 
dropping the -refine- faces on top of those would not just counter-act 
that change, but go in reverse.

> 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 don't remember being bit by this myself, but it does sound like a problem.

>> If it were indicated differently somehow (though I'm not sure how), perhaps
>> I'd like it more. As it is, though, the added value (quite minor since it's
>> easy to see which hunk is "pure addition" already) doesn't seem to balance
>> out the inconvenience.
> 
> Yeah, maybe I'd prefer colors that are halfway between
> `diff-added/removed` and `diff-refine-added/removed`?
> [ Wish we had dynamically-computed face colors for that.  ]

Toning the -refine- faces down could be an option. It'll be a balance 
between making them less in-your-face and harder to notice overall 
(example: diff-refine-added-ddffdd.png).

Some other possibilities:

- In this refinement mode, toning down the "base" backgrounds instead, 
while using the current colors for -refine- faces. This is probably a 
dead end, though: the distance until white is too small, not enough to 
find a good contrast (example: diff-added-f9fff9.png). Might as well use 
white or diff-context grey, I guess.

- Like Samuel mentioned, attenuate the indicators' column. Except 
instead of inverse video just apply the refine faces? See 
diff-refine-indicators.png. Looks good to me color-wise, though the 
change in the indication method is somewhat an inconsistency.

- Use some added border around the hunk in green/red (using the color of 
diff-indicator-*). Possibly combined with the previous item. The 
drawback is the same, and in addition this might not work on the 
terminal (?). See diff-define-borders.png; these line were done using 
overline/underline so there was no way to make it thicker, but there 
must be other methods, e.g. like we do the separator line when writing 
the commit message (although that one will create a vertical offset).

[-- Attachment #2: diff-refine-added-ddffdd.png --]
[-- Type: image/png, Size: 189465 bytes --]

[-- Attachment #3: diff-added-f9fff9.png --]
[-- Type: image/png, Size: 186309 bytes --]

[-- Attachment #4: diff-refine-indicators.png --]
[-- Type: image/png, Size: 192024 bytes --]

[-- Attachment #5: diff-refine-borders.png --]
[-- Type: image/png, Size: 194002 bytes --]

bug#61396: diff mode could distinguish changed from deleted lines

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> - Like Samuel mentioned, attenuate the indicators' column. Except instead of
>   inverse video just apply the refine faces? See
>   diff-refine-indicators.png. Looks good to me color-wise, though the change
>  in the indication method is somewhat an inconsistency.

I think I like that.  But I'm not sure how to adapt this to my case
where I "prettify" the indicators into the fringe.

Maybe a related idea would be to use the diff-refine-added/removed face
on the line-end: the reduced contrast is not a problem there since
there's no text.  But it's not always visible (for long enough lines).

I suspect we'll have to provide various alternatives and see which
ones stick.


        Stefan

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

might need to distinguish from refilled paragraph.

On 9/14/23, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> - Like Samuel mentioned, attenuate the indicators' column. Except instead
>> of
>>   inverse video just apply the refine faces? See
>>   diff-refine-indicators.png. Looks good to me color-wise, though the
>> change
>>  in the indication method is somewhat an inconsistency.
>
> I think I like that.  But I'm not sure how to adapt this to my case
> where I "prettify" the indicators into the fringe.
>
> Maybe a related idea would be to use the diff-refine-added/removed face
> on the line-end: the reduced contrast is not a problem there since
> there's no text.  But it's not always visible (for long enough lines).
>
> I suspect we'll have to provide various alternatives and see which
> ones stick.
>
>
>         Stefan
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Dmitry Gutov]

On 15/09/2023 04:34, Stefan Monnier wrote:
>> - Like Samuel mentioned, attenuate the indicators' column. Except instead of
>>    inverse video just apply the refine faces? See
>>    diff-refine-indicators.png. Looks good to me color-wise, though the change
>>   in the indication method is somewhat an inconsistency.
> I think I like that.  But I'm not sure how to adapt this to my case
> where I "prettify" the indicators into the fringe.

Fringes can use faces; those faces' backgrounds are also used for the 
background of the fringe. So in theory I don't see any problem, although 
how to write it in Lisp to keep both possibilities (fringe and 
non-fringe), might require some effort.

> Maybe a related idea would be to use the diff-refine-added/removed face
> on the line-end: the reduced contrast is not a problem there since
> there's no text.  But it's not always visible (for long enough lines).
> 
> I suspect we'll have to provide various alternatives and see which
> ones stick.

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

> 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.
This is because of a poor choice of indicators in the diff utility.

When hunk boundaries are off-screen, there is no way to distinguish
whether a unified format hunk contains added or changed lines:

  @@
  + added line 1
  + added line 2

vs

  ---
  + changed line 1
  + changed line 2

The context format is slightly better, but still the indicator !
is ambiguous and can't distinguish between old and new changed lines:

  ! old changed line 1
  ! old changed line 2
  ---
  ! new changed line 1
  ! new changed line 2

Only the normal format can do this unambiguously with < and >.

So the perfect format would be like unified but using < and >
for the changed lines:

  @@
  + added line 1
  + added line 2
  @@
  < old changed line 1
  < old changed line 2
  ---
  > new changed line 1
  > new changed line 2
  @@
  - removed line 1
  - removed line 2

bug#61396: diff mode could distinguish changed from deleted lines

[Eli Zaretskii]

> Cc: Dmitry Gutov <dmitry@gutov.dev>, 61396@debbugs.gnu.org,
>  Samuel Wales <samologist@gmail.com>
> From: Juri Linkov <juri@linkov.net>
> Date: Sat, 30 Sep 2023 20:38:22 +0300
> 
> I realized now the same problem exists even without color highlighting at all.
> This is because of a poor choice of indicators in the diff utility.

Which I guess is why many (all?) of the other systems that show
changes use the side-by-side display, where these problems largely
don't exist.  So maybe we should migrate to using "diff -y" or sdiff?

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

>> I realized now the same problem exists even without color highlighting at all.
>> This is because of a poor choice of indicators in the diff utility.
>
> Which I guess is why many (all?) of the other systems that show
> changes use the side-by-side display, where these problems largely
> don't exist.  So maybe we should migrate to using "diff -y" or sdiff?

Many other systems like GitHub and GitLab show the unified format by default
with exactly the same color highlighting and diff indicators as in Emacs,
and they don't see a problem with this.

Such systems also provide an option to switch to the side-by-side format as well.
But such format looks more like what Ediff does by displaying two buffers
side-by-side with (setq ediff-split-window-function 'split-window-horizontally)
and optionally enabled display-line-numbers-mode in them.

bug#61396: diff mode could distinguish changed from deleted lines

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> 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.


        Stefan

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

>>> 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.

bug#61396: diff mode could distinguish changed from deleted lines

[Samuel Wales]

some lines are truly added or deleted.  the problem is they look
exactly like lines that are changed in the other polarity.  so you
can't tell which they are.
i don't think it's too heavy to indicate such lines by e.g. inverse
video on the polarity character -+ or so.  others might.


On 10/1/23, Juri Linkov <juri@linkov.net> wrote:
>>>> 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.
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

> some lines are truly added or deleted.  the problem is they look
> exactly like lines that are changed in the other polarity.  so you
> can't tell which they are.
> i don't think it's too heavy to indicate such lines by e.g. inverse
> video on the polarity character -+ or so.  others might.

Maybe adding the refined face only on indicators of the
added/removed hunks could help (if such highlighting won't mislead
into interpreting this as changes only in newlines).

bug#61396: diff mode could distinguish changed from deleted lines

[Juri Linkov]

> - 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.

Ediff highlights the first character of the context.  Logically
this is not correct, but probably Ediff predates the ability of
using a thin space like in `rectangle-mode`.  Or maybe because
it doesn't work on ttys.