all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tino Calancha <tino.calancha@gmail.com>
To: Dima Kogan <dima@secretsauce.net>
Cc: larsi@gnus.org, Tino Calancha <tino.calancha@gmail.com>,
	npostavs@users.sourceforge.net, Mark Oteiza <mvoteiza@udel.edu>,
	schwab@linux-m68k.org, Dmitry Gutov <dgutov@yandex.ru>,
	25105@debbugs.gnu.org
Subject: bug#25105: 26.0.50; diff navigation is broken
Date: Fri, 6 Jan 2017 13:22:49 +0900 (JST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1701061321580.31115@calancha-pc> (raw)
In-Reply-To: <87tw9dc7bk.fsf@secretsauce.net>



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





      parent reply	other threads:[~2017-01-06  4:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-04 15:13 bug#25105: 26.0.50; diff navigation is broken Mark Oteiza
2016-12-04 15:27 ` npostavs
2016-12-05 15:38   ` Dima Kogan
2016-12-05 15:53     ` Dmitry Gutov
2016-12-05 16:33       ` Dima Kogan
2016-12-05 16:55         ` Mark Oteiza
2016-12-05 17:49           ` Dima Kogan
2016-12-25  6:57             ` Dima Kogan
2016-12-25 13:54               ` Mark Oteiza
2017-01-06  1:14 ` Tino Calancha
2017-01-06  1:20   ` Dima Kogan
2017-01-06  1:27     ` Dima Kogan
2017-01-06  3:06       ` Mark Oteiza
2017-01-06  3:50         ` Tino Calancha
2017-01-06  4:16         ` Dima Kogan
2017-01-06  4:43           ` Mark Oteiza
2017-01-06  7:55           ` Eli Zaretskii
2017-01-06  8:03             ` Tino Calancha
2017-01-06 14:14               ` Dmitry Gutov
2017-01-07  1:54                 ` Tino Calancha
2017-01-07  2:05                   ` Mark Oteiza
2017-01-07  9:51                 ` Dima Kogan
2017-01-07 11:16                   ` Tino Calancha
2017-01-07 22:16                     ` Dima Kogan
2017-01-07 22:27                       ` Dmitry Gutov
2017-01-06  3:09     ` Mark Oteiza
2017-01-06  4:22     ` Tino Calancha [this message]

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

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

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1701061321580.31115@calancha-pc \
    --to=tino.calancha@gmail.com \
    --cc=25105@debbugs.gnu.org \
    --cc=dgutov@yandex.ru \
    --cc=dima@secretsauce.net \
    --cc=larsi@gnus.org \
    --cc=mvoteiza@udel.edu \
    --cc=npostavs@users.sourceforge.net \
    --cc=schwab@linux-m68k.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.