emacs-devel
[Top][All Lists]
Advanced

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

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


From: Dmitry Gutov
Subject: Re: [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation
Date: Fri, 16 Dec 2016 03:05:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:50.0) Gecko/20100101 Thunderbird/50.0

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).



reply via email to

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