bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#25105: 26.0.50; diff navigation is broken


From: Dima Kogan
Subject: bug#25105: 26.0.50; diff navigation is broken
Date: Sat, 07 Jan 2017 01:51:57 -0800
User-agent: mu4e 0.9.17; emacs 26.0.50.1

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 06.01.2017 11:03, Tino Calancha wrote:
>
> I've honestly thought that Dima's patch's main purpose was to fix that
> bug. And everything else we now complain about are just implementation's
> side-effects.

The goals are described in the git commit message.

The way these goals were met was to make everything consistent, with my
interpretation of what that means.

Taking the new behavior for M-k, C-c C-a and keeping the old behavior
for M-n/M-p is weird. Example:

Let's look at the commands required to apply hunks 1 and 2 in a buffer
versus just hunk 2. Assuming we're at bob, and assuming we're using the
new code.

  Applying hunks 1 and 2:  C-c C-a   C-c C-a; i.e. apply 1, apply 2
  Applying hunk 2 only:    M-n       C-c C-a; i.e. skip 1,  apply 2

If M-n works the way it did before, then you need to invoke M-n twice to
apply hunk 2 only. I claim this is weird, since it should require only
one command to "skip 1". This is what is meant by a "consistent"
behavior.

To reinterate, my desired outcome is to have the current code in place,
and to hook auto-refinement in a diff-mode-hook to make that work in a
way that makes sense. I'm fine with a switch that lets you pick what you
want. As stated above, I don't think a hybrid approach makes sense,
since it takes one weird thing and converts it to another thing that's
weird in a different way.

Furthermore, I'd like to get some feedback from more than just the few
people active on this thread. If there's a lopsided preference to the
old approach, we can simply revert and move on.

dima





reply via email to

[Prev in Thread] Current Thread [Next in Thread]