From: Dmitry Gutov <dgutov@yandex.ru>
To: Dima Kogan <dima@secretsauce.net>
Cc: emacs-devel@gnu.org, Tino Calancha <tino.calancha@gmail.com>
Subject: Re: [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation
Date: Fri, 16 Dec 2016 03:05:28 +0200 [thread overview]
Message-ID: <450ce252-418d-ccdc-7310-092146a13c90@yandex.ru> (raw)
In-Reply-To: <87fultr4he.fsf@secretsauce.net>
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).
next prev parent reply other threads:[~2016-12-16 1:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 12:07 [Emacs-diffs] master 2c8a7e5: Improve diff-mode navigation/manipulation Tino Calancha
2016-11-30 0:03 ` Noam Postavsky
2016-11-30 14:22 ` Dmitry Gutov
2016-11-30 14:31 ` Stefan Monnier
2016-11-30 14:34 ` Dmitry Gutov
2016-11-30 15:07 ` Stefan Monnier
2016-12-10 1:27 ` Dima Kogan
2016-12-10 10:14 ` Dmitry Gutov
2016-12-10 17:27 ` Dima Kogan
2016-12-11 11:07 ` Dmitry Gutov
2016-12-12 7:28 ` Dima Kogan
2016-12-16 1:05 ` Dmitry Gutov [this message]
2016-12-20 2:22 ` Tino Calancha
2016-12-20 7:31 ` Dima Kogan
2016-12-25 6:52 ` Dima Kogan
2016-12-25 9:48 ` Tino Calancha
2016-12-25 9:58 ` Tino Calancha
2016-12-25 14:10 ` Dmitry Gutov
2016-12-06 2:03 ` Mark Oteiza
2016-12-07 7:29 ` Dima Kogan
2017-01-06 2:58 ` Mark Oteiza
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=450ce252-418d-ccdc-7310-092146a13c90@yandex.ru \
--to=dgutov@yandex.ru \
--cc=dima@secretsauce.net \
--cc=emacs-devel@gnu.org \
--cc=tino.calancha@gmail.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).