GNU bug report logs - #73172
[PATCH] Move to start of current header in diff-{file,hunk}-prev

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Tue, 10 Sep 2024 18:41:02 UTC

Severity: normal

Tags: patch

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 73172 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 73172 <at> debbugs.gnu.org
Subject: Re: bug#73172: [PATCH] Move to start of current header in
 diff-{file,hunk}-prev
Date: Thu, 19 Sep 2024 14:41:31 -0400
Dmitry Gutov <dmitry <at> gutov.dev> writes:
> Hi Spencer and Stefan,
>
> On 10/09/2024 21:40, Spencer Baugh via Bug reports for GNU Emacs, the
> Swiss army knife of text editors wrote:
>
>> (The following change is split across two patches; the first one, "move
>> easy-mmode", fixes an unrelated FIXME, which makes the diff in the
>> second patch simpler)
>> If point was after a file or hunk header, the diff-file-prev and
>> diff-hunk-prev commands would move to the start of that header.
>> But if point was *within* the header, they would not move, and
>> would report "No previous file" or "No previous hunk".  This
>> differs from the behavior of most other movement commands,
>> e.g. backward-sexp or backward-sentence.
>> This commit fixes diff-file-prev and diff-hunk-prev, as well as
>> other easy-mmode-define-navigation BASE-prev commands.  Now
>> these commands move to the start of the containing "thing" just
>> like other movement commands.
>> * lisp/emacs-lisp/easy-mmode.el (easy-mmode--prev): Move to
>> start of current match first.
>> Also discussed here:
>> https://lists.gnu.org/archive/html/help-gnu-emacs/2024-08/msg00367.html
>
> Patch#1 seems unequivocally a good thing (easier code iteration)

BTW, if we want to go ahead and install that patch on its own, that
would be fine with me.

> and patch#2 seems good on balance.
>
> It does introduce some backward incompatibility in rare cases where I
> have probably internalized the current behavior already -- for example
> in the vc-print-root-log output pressing 'p' while on the first line
> somewhere between the initial '*' and the end of the date dings with
> "No previous log message", and how will move to bol.
>
> But it might be more consistent anyway, given that the there is no
> ding already if you start out inside the summary text.

Yes.  It's definitely a change in behavior.

But, if someone has internalized:

  diff-file-prev usually acts like "backward-sexp for files" (it moves
  point to the start of the current file), except that if point is in
  the header of the first file in the buffer then diff-file-prev does
  nothing instead.

Then I think they'll be happy to be able to discard that knowledge
in favor of:

  diff-file-prev always acts like "backward-sexp for files" (it moves
  point to the start of the current file).

Especially because "does nothing in one weird corner case" is not useful
or deliberate behavior (it's just a bug).

> There aren't many in-tree callers of easy-mmode-define-navigation
> (diff-mode, log-view, smerge and, uh, cvs-status), and few 3rd party
> callers, so this seems low-impact. diff-hl-mode is not affected either
> because it only uses diff-hunk-next, not diff-hunk-prev.

Yep.  I think it will be a nice improvement for those few other commands
as well.




This bug report was last modified 239 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.