GNU bug report logs - #25105
26.0.50; diff navigation is broken

Previous Next

Package: emacs;

Reported by: Mark Oteiza <mvoteiza <at> udel.edu>

Date: Sun, 4 Dec 2016 15:14:02 UTC

Severity: normal

Tags: patch

Merged with 25400

Found in version 26.0.50

Done: Tino Calancha <tino.calancha <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Tino Calancha <tino.calancha <at> gmail.com>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: npostavs <at> users.sourceforge.net, Tino Calancha <tino.calancha <at> gmail.com>, Mark Oteiza <mvoteiza <at> udel.edu>, eliz <at> gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>, schwab <at> linux-m68k.org, 25105 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: bug#25105: 26.0.50; diff navigation is broken
Date: Fri, 6 Jan 2017 13:22:49 +0900 (JST)

Hi Dima,

thanks for your prompt replay.

i am sorry, i didn't follow the discussion in Bug#17544, so i just
realized its effects once the patch was pushed; those effects
affect my everyday use of Emacs.
(Added as CC the people who joined Bug#17544).

On Thu, 5 Jan 2017, Dima Kogan wrote:
> This isn't a misbehavior, it's the whole point of the patch. We can
> argue about whether it's an improvement or not
My point is that Bug#17544 is not a bug, it's a feature.  Your fix
just breaks the feature.
> if this is a "bug", then the solution is a full revert.
It might be the right thing to do.  I was actually very happy with how
Emacs-25 deal with this issue.
Another posibility is the patch that Mark just sent to this thread.
> The behavior I want is to always have a consistent idea of which hunk we
> are currently on.
IMO, this is not a good idea.  Things depend of the perspective.  If you
are in one hunk or another it depends of what you want to do.  That is
part of the feature.

>Navigation and use of diff buffers had several annoying corner cases that this
>patch fixes. These corner cases were largely due to inconsistent treatment of
>file headers. Say you have a diff such as this:
I disagree, ideed i found it very consistent (see below).
> --- aaa
> +++ bbb
> @@ -52,7 +52,7 @@
> hunk1
> @@ -74,7 +74,7 @@
> hunk2
> --- ccc
> +++ ddd
> @@ -608,6 +608,6 @@
> hunk3
> @@ -654,7 +654,7 @@
> hunk4
>
>The file headers here are the '---' and '+++' lines. With the point on such a
>line, hunk operations would sometimes refer to the next hunk and sometimes to
>the previous hunk. Most of the time it would be the previous hunk, which is not
>what the user would expect.
It seems some users expect it :-)
>This patch consistently treats such headers as the
>next hunk. So with this patch, if the point is on the '--- ccc' line, the point
>is seen as referring to hunk3.

it's totally consistent to not consider
the file header the same if you are not doing the same operation.  If i am at
--- ccc
then, i want `diff-hunk-next' bring me to the line:
@@ -608,6 +608,6 @@
and `diff-hunk-prev' bring me to the line:
@@ -74,7 +74,7 @@

To this happen, in the first case the point must be considered at hunk2,
but in the second case, the point must be considered in hunk3.
To me, this is pretty consistent with the intended (and useful) behaviour.

Regards,
Tino




This bug report was last modified 8 years and 123 days ago.

Previous Next


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