Re: [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation

[Dmitry Gutov <dgutov@yandex.ru>]

On 12.12.2016 09:28, Dima Kogan wrote:

> Hi. I played around with this, and I now really don't like this idea
> because it would mean that diff-hunk-next no longer always moves to the
> next hunk.

We have other commands that behave this way. beginning-of-defun and 
end-of-defun, for instance. You could say they're named differently, but 
I think the uniformity of behavior is more important.

> At the last hunk, diff-hunk-next would stay on the SAME hunk
> if this was implemented.

It would go beyond the last hunk, wouldn't it?

> Furthermore, I think invoking auto-refinement in diff-mode-hook makes
> sense.

 From a strict and logical point of view, maybe. But not from the user 
convenience point of view. I don't think we should exchange the latter 
for the former.

> And I think that this should happen even if the first hunk is large.
> This would indeed be slow, but this is AUTO refinement.

Again, words are important, but it's up to us as developers to choose 
how to interpret them for maximum user benefit.

> If you want to
> decide when refinement should or should not happen, auto-refinement is
> not what you want.

It's worked quite well before.

> We can add a variable to block auto-refinement for
> hunks larger than some size, which probably would be a good idea anyway.

That sounds finicky. It would be hard to find the value that's good for 
all kinds of diffs, users and differently performing computers.

> I fixed the incorrect behavior where auto-refinement was kicking in even
> when the navigation failed and we signalled an error.

That's something, I guess.

> Not attaching any patches yet. Let's agree on an approach, and then talk
> implementation.

I'm sorry for not proposing a particular course of action. If nobody has 
a good suggestion aside from a revert (which we obviously want to 
avoid), I'll try to dig in sometime later (January at the earliest).