unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Samuel Wales <samologist@gmail.com>
To: 61396@debbugs.gnu.org
Subject: bug#61396: diff mode could distinguish changed from deleted lines
Date: Wed, 8 Mar 2023 14:14:50 -0700	[thread overview]
Message-ID: <CAJcAo8sUdOE+Se-qP3Q0fNDbDyGf_nqQLWic0MJ3dn-Gz4ZnQw@mail.gmail.com> (raw)
In-Reply-To: <CAJcAo8tT8T4m4cXJcz9cv3h=1EPGarTr8CxzgygTaCyL0W8GAA@mail.gmail.com>

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





  parent reply	other threads:[~2023-03-08 21:14 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  3:25 bug#61396: diff mode could distinguish changed from deleted lines Samuel Wales
2023-02-10  7:17 ` Juri Linkov
2023-02-10 23:49   ` Samuel Wales
2023-02-10 23:50     ` Samuel Wales
2023-02-10 13:58 ` Dmitry Gutov
2023-02-11  4:25 ` Richard Stallman
2023-02-11  5:07   ` Samuel Wales
2023-02-11 17:54     ` Juri Linkov
2023-02-12  0:52       ` Samuel Wales
2023-02-12  1:04         ` Dmitry Gutov
2023-02-12  1:07           ` Samuel Wales
2023-02-12  1:52             ` Dmitry Gutov
2023-02-12  2:12               ` Samuel Wales
2023-02-12  2:17                 ` Dmitry Gutov
2023-02-12  2:54                   ` Samuel Wales
2023-02-12  8:31         ` Juri Linkov
2023-02-12  9:03           ` Samuel Wales
2023-02-12 17:20             ` Juri Linkov
2023-02-12 22:16               ` Samuel Wales
2023-02-12 22:48                 ` Samuel Wales
2023-07-23  6:04                   ` Samuel Wales
2023-07-24 10:21                     ` Robert Pluim
2023-07-24 23:38                       ` Samuel Wales
2023-07-24 23:39                         ` Samuel Wales
2023-07-25  8:11                           ` Robert Pluim
2023-07-25 21:29                             ` Samuel Wales
2023-08-10 23:56                     ` Samuel Wales
2023-08-11  0:41                       ` Dmitry Gutov
2023-09-03 17:29                     ` Juri Linkov
2023-03-08 21:14 ` Samuel Wales [this message]
2023-09-04 21:06 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-04 22:38   ` Samuel Wales
2023-09-07  2:34     ` Samuel Wales
2023-09-12 22:11   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-12 22:31     ` Dmitry Gutov
2023-09-13 14:51       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-14  6:05         ` Samuel Wales
2023-09-14 22:42         ` Dmitry Gutov
2023-09-15  1:34           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-15  1:58             ` Samuel Wales
2023-09-15 10:20             ` Dmitry Gutov
2023-09-30 17:38         ` Juri Linkov
2023-09-30 18:18           ` Eli Zaretskii
2023-10-01  6:32             ` Juri Linkov
2023-10-01 15:54           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-01 18:53             ` Juri Linkov
2023-10-01 22:16               ` Samuel Wales
2023-10-02  6:48                 ` Juri Linkov
2023-10-02 16:56   ` Juri Linkov

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: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=CAJcAo8sUdOE+Se-qP3Q0fNDbDyGf_nqQLWic0MJ3dn-Gz4ZnQw@mail.gmail.com \
    --to=samologist@gmail.com \
    --cc=61396@debbugs.gnu.org \
    /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://git.savannah.gnu.org/cgit/emacs.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).