GNU bug report logs - #77197
31.0.50; forward-word fails after yanking into summary line of *vc-log*

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Paul D. Nelson" <ultrono <at> gmail.com>
Cc: larsi <at> gnus.org, 77197 <at> debbugs.gnu.org, spwhitton <at> spwhitton.name
Subject: Re: bug#77197: 31.0.50;
 forward-word fails after yanking into summary line of *vc-log*
Date: Sun, 23 Mar 2025 15:56:13 +0200

> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 77197 <at> debbugs.gnu.org
> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Date: Sun, 23 Mar 2025 14:12:15 +0100
> 
> The issue starts at 2f3cf7ffe3c9ce986caf6d093b880fed6046b7ec, whose
> purpose (bug#15645) was to have C-a take us to the start of the field
> rather than the the start of the line.  Reverting log-edit.el to any
> prior commit resolves the issue.
> 
> The issue is that after inserting the headers with
> 
> (propertize (concat header ": ")
>             'field 'header
>             'rear-nonsticky t)
> 
> any typed text inherits the (field header) property, but yanked or
> inserted text does not, introducing a field boundary that obstructs
> forward-word.
> 
> Removing these properties like in the patch below addresses the issue,
> but I'll confess that I don't understand why these properties were
> introduced; I hope someone that does can analyze further.

The intent seems clear: to prevent people from inadvertently moving
into the header part and modifying it.  If that was clear, and you
still don't understand why the change was done, please ask specific
questions, or maybe I'm missing something here.

So maybe the problem is that yanked text should be processed specially
so as not to introduce a field boundary.

> Indeed, I
> haven't been able to reproduce bug#15645 after evaluating older versions
> of log-edit.el, so maybe something relevant outside of log-edit.el has
> changed in the mean time, but C-a is bound to
> log-edit-beginning-of-line, which is a light wrapper around
> message-beginning-of-line, which has had the "beginning of header"
> feature since many years before bug#15645, so maybe I missed something.

C-a is just one way of moving the cursor; there are others.  Having a
field there stops many movement commands.  So I think removing the
field property is not the best option here.  Instead, we should add to
the existing code whatever is necessary to prevent the situations such
as the one which started this bug report, without getting rid of the
field property itself.

Thanks.

Previous Next

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