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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 77197 in the body.
You can then email your comments to 77197 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Paul Nelson <ultrono <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; forward-word fails after yanking into summary line of
 *vc-log*
Date: Sun, 23 Mar 2025 02:15:58 +0100

If we yank text into the summary line of a *vc-log* buffer, then with
point at beginning of line, forward-word fails.

To reproduce, use vc-next-action (C-x v v) to arrive at a *vc-log*
buffer.  With point after "Summary:", evaluate

(progn
  (insert "text")
  (log-edit-beginning-of-line)
  (forward-word))

This leaves point before "text".  It should instead be after.

There is no issue if we manually type "text".



In GNU Emacs 31.0.50 (build 2, aarch64-apple-darwin24.1.0, NS
 appkit-2575.20 Version 15.1.1 (Build 24B91)) of 2025-02-27 built on
 d51735
Repository revision: f4c8b889c148265cbfb33d2fe4f080639543897f
Repository branch: working
Windowing system distributor 'Apple', version 10.3.2575
System Description:  macOS 15.1.1

Configured using:
 'configure --with-ns --with-native-compilation --with-tree-sitter
 --with-gif --with-png --with-jpeg --with-rsvg --with-tiff
 --with-imagemagick --with-x-toolkit=gtk3 --with-xwidgets'

Configured features:
ACL DBUS GLIB GNUTLS IMAGEMAGICK LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM XWIDGETS ZLIB

Important settings:
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/d

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/au710211/gnu-emacs/lisp/pulse hides /Users/au710211/gnu-emacs/lisp/cedet/pulse
/Users/au710211/gnu-emacs/lisp/mail/hashcash hides /Users/au710211/gnu-emacs/lisp/obsolete/hashcash
/Users/au710211/gnu-emacs/lisp/kermit hides /Users/au710211/gnu-emacs/lisp/obsolete/kermit
/Users/au710211/gnu-emacs/lisp/cdl hides /Users/au710211/gnu-emacs/lisp/obsolete/cdl
/Users/au710211/gnu-emacs/lisp/echistory hides /Users/au710211/gnu-emacs/lisp/obsolete/echistory

Features:
(shadow sort mail-extr warnings icons compile comint ansi-osc ansi-color
emacsbug lisp-mnt misearch multi-isearch smerge-mode diff vc-hg vc-git
diff-mode track-changes files-x vc-bzr vc-src vc-sccs vc-svn vc-cvs
vc-rcs log-view log-edit message sendmail mailcap yank-media puny rfc822
mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date subr-x mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader ring add-log easy-mmode
pcvs-util vc vc-dispatcher comp-run bytecomp byte-compile comp-common rx
dired-aux cl-loaddefs cl-lib dired dired-loaddefs rmc iso-transl tooltip
cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads xwidget-internal dbusbind kqueue cocoa ns lcms2 multi-tty
make-network-process tty-child-frames native-compile emacs)

Memory information:
((conses 16 146906 11082) (symbols 48 19856 0) (strings 32 47334 2700)
 (string-bytes 1 1005449) (vectors 16 15012)
 (vector-slots 8 196289 10107) (floats 8 31 137) (intervals 56 1522 0)
 (buffers 992 21))

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Paul Nelson <ultrono <at> gmail.com>
Cc: 77197 <at> debbugs.gnu.org
Subject: Re: bug#77197: 31.0.50; forward-word fails after yanking into
 summary line of *vc-log*
Date: Sun, 23 Mar 2025 12:31:13 +0800

Hello,

On Sun 23 Mar 2025 at 02:15am +01, Paul Nelson wrote:

> If we yank text into the summary line of a *vc-log* buffer, then with
> point at beginning of line, forward-word fails.
>
> To reproduce, use vc-next-action (C-x v v) to arrive at a *vc-log*
> buffer.  With point after "Summary:", evaluate
>
> (progn
>   (insert "text")
>   (log-edit-beginning-of-line)
>   (forward-word))
>
> This leaves point before "text".  It should instead be after.
>
> There is no issue if we manually type "text".

I've been running into this lately too.  I intend to look into it,
though any further investigation from you would be much appreciated.

-- 
Sean Whitton

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

From: Juri Linkov <juri <at> linkov.net>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 77197 <at> debbugs.gnu.org, Paul Nelson <ultrono <at> gmail.com>
Subject: Re: bug#77197: 31.0.50; forward-word fails after yanking into
 summary line of *vc-log*
Date: Sun, 23 Mar 2025 09:55:44 +0200

>> If we yank text into the summary line of a *vc-log* buffer, then with
>> point at beginning of line, forward-word fails.
>>
>> To reproduce, use vc-next-action (C-x v v) to arrive at a *vc-log*
>> buffer.  With point after "Summary:", evaluate
>>
>> (progn
>>   (insert "text")
>>   (log-edit-beginning-of-line)
>>   (forward-word))
>>
>> This leaves point before "text".  It should instead be after.
>>
>> There is no issue if we manually type "text".
>
> I've been running into this lately too.  I intend to look into it,
> though any further investigation from you would be much appreciated.

I run Emacs with the enabled option 'backtrace-on-redisplay-error',
so I see such backtrace in *vc-log* buffers:

Error: end-of-buffer nil
  font-lock-fontify-keywords-region(1 10 nil)
  font-lock-default-fontify-region(1 10 nil)
  font-lock-fontify-region(1 10)
  #f(compiled-function (fun) #<bytecode ...>)(font-lock-fontify-region)
  run-hook-wrapped(#f(compiled-function (fun) #<bytecode ...>) font-lock-fontify-region)
  jit-lock--run-functions(1 10)
  jit-lock-fontify-now(1 10)
  jit-lock-function(1)
  redisplay_internal\ \(C\ function\)()

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 77197 <at> debbugs.gnu.org
Subject: Re: bug#77197: 31.0.50; forward-word fails after yanking into summary
 line of *vc-log*
Date: Sun, 23 Mar 2025 14:12:15 +0100

[Message part 1 (text/plain, inline)]

> I've been running into this lately too.  I intend to look into it,
> though any further investigation from you would be much appreciated.

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

[Message part 2 (text/x-patch, inline)]

diff --git a/lisp/vc/log-edit.el b/lisp/vc/log-edit.el
index e23e7414a18..e674f56f1e1 100644
--- a/lisp/vc/log-edit.el
+++ b/lisp/vc/log-edit.el
@@ -896,9 +896,7 @@ log-edit-empty-buffer-p
 
 (defun log-edit--make-header-line (header &optional value)
   ;; Make \\`C-a' work like it does in other buffers with header names.
-  (concat (propertize (concat header ": ")
-                      'field 'header
-                      'rear-nonsticky t)
+  (concat (concat header ": ")
           value
           "\n"))
 

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.

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 16:08:20 +0100

The issue seems to concern the function

(defun log-edit--make-header-line (header &optional value)
  ;; Make \\`C-a' work like it does in other buffers with header names.
  (concat (propertize (concat header ": ")
                      'field 'header
                      'rear-nonsticky t)
          value
          "\n"))

The relevant commit 2f3cf7ffe3c9ce986caf6d093b880fed6046b7ec reads:

    * lisp/vc/log-edit.el (log-edit-insert-message-template): Fieldify
    headers so that `C-a' takes us to the start of the string, not the
    line (bug#15645).

I took "start of the string" to mean before "text" in "Summary: text".

It's possible that I have misunderstood and that the intent was actually
to make the full header line "Subject: text" a field, with the field
boundary serving to divide the header of the email from the body, but
this seems contrary to my reading of the commit message.

Assuming that I haven't misunderstood:

If I do C-x v v and type "text", then the field boundary comes after
"text" rather than after "Summary: ".  This seems at odds with the
advertised behavior, which suggested that it should introduce a field
boundary after "Summary :".

In more detail, after C-x v v:

1. With point after "Summary: ", the text properties at point (C-u C-x =)
do not contain the header field.

2. With point after "Summary:", the properties contain the header field.

3. If I type a character after "Summary: " and do backward-char, then
the properties at point contain the header field.

This behavior seem contrary to what is expected with rear-nonsticky:

  Insertion after a character inherits those of its properties that are
  “rear-sticky”.

So as far as I can tell, rear-nonsticky text properties are being
propagated when they shouldn't, resulting in the full header line being
a single field (which then gets broken up when we yank).

Message #23 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>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
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 17:46:36 +0200

> From: "Paul D. Nelson" <ultrono <at> gmail.com>
> Cc: spwhitton <at> spwhitton.name, larsi <at> gnus.org, 77197 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 16:08:20 +0100
> 
> The issue seems to concern the function
> 
> (defun log-edit--make-header-line (header &optional value)
>   ;; Make \\`C-a' work like it does in other buffers with header names.
>   (concat (propertize (concat header ": ")
>                       'field 'header
>                       'rear-nonsticky t)
>           value
>           "\n"))
> 
> The relevant commit 2f3cf7ffe3c9ce986caf6d093b880fed6046b7ec reads:
> 
>     * lisp/vc/log-edit.el (log-edit-insert-message-template): Fieldify
>     headers so that `C-a' takes us to the start of the string, not the
>     line (bug#15645).
> 
> I took "start of the string" to mean before "text" in "Summary: text".
> 
> It's possible that I have misunderstood and that the intent was actually
> to make the full header line "Subject: text" a field, with the field
> boundary serving to divide the header of the email from the body, but
> this seems contrary to my reading of the commit message.
> 
> Assuming that I haven't misunderstood:
> 
> If I do C-x v v and type "text", then the field boundary comes after
> "text" rather than after "Summary: ".  This seems at odds with the
> advertised behavior, which suggested that it should introduce a field
> boundary after "Summary :".
> 
> In more detail, after C-x v v:
> 
> 1. With point after "Summary: ", the text properties at point (C-u C-x =)
> do not contain the header field.
> 
> 2. With point after "Summary:", the properties contain the header field.
> 
> 3. If I type a character after "Summary: " and do backward-char, then
> the properties at point contain the header field.
> 
> This behavior seem contrary to what is expected with rear-nonsticky:
> 
>   Insertion after a character inherits those of its properties that are
>   “rear-sticky”.
> 
> So as far as I can tell, rear-nonsticky text properties are being
> propagated when they shouldn't, resulting in the full header line being
> a single field (which then gets broken up when we yank).

If you look at what "C-u C-x =" reports, you will see that the
rear-nonsticky property is missing.  This is because log-edit-mode
does this:

  (define-derived-mode log-edit-mode text-mode "Log-Edit"
    "Major mode for editing version-control (VC) commit log messages.
  When done editing the log entry, type \\[log-edit-done], which will
  trigger the actual commit of the file(s).
  Several other handy support commands are provided, and the package
  from which this is used might also provide additional commands (under
  the \\[vc-prefix-map] prefix for VC commands, for example).

  \\{log-edit-mode-map}"
    (setq-local font-lock-defaults '(log-edit-font-lock-keywords t))
    (make-local-variable 'font-lock-extra-managed-props)
    (cl-pushnew 'rear-nonsticky font-lock-extra-managed-props) <<<<<<<<<<<<<<<<
    (cl-pushnew 'display-line-numbers-disable font-lock-extra-managed-props)

The change Lars made, where he added the 'field' and 'rear-nonsticky'
properties, was _after_ the addition by Stefan of 'rear-nonsticky' to
font-lock-extra-managed-props, so perhaps Lars was unaware that
font-lock will remove the property right away?

Stefan, any suggestions for how to fix this?

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

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

> The change Lars made, where he added the 'field' and 'rear-nonsticky'
> properties, was _after_ the addition by Stefan of 'rear-nonsticky' to
> font-lock-extra-managed-props, so perhaps Lars was unaware that
> font-lock will remove the property right away?
>
> Stefan, any suggestions for how to fix this?

The use of `font-lock-extra-managed-props` is a crude hack to try and
make sure the property doesn't remain when the separator line becomes
something else.  This is somewhat important for
`display-line-numbers-disable` but much less so for `rear-nonsticky`.

The simplest solution is probably to just remove that `cl-pushnew`
altogether: the risk of the `rear-nonsticky` text-property causing
problems because it lingered where it shouldn't have is vanishingly
small, especially compared to the very concrete problem at hand.

If we want to be super extra careful, then one solution is to add extra
code that looks for the `display-line-numbers-disable` property and
removes the `rear-nonsticky` property on the character(s) that have it.


        Stefan

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

From: "Paul D. Nelson" <ultrono <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eliz <at> gnu.org, 77197 <at> debbugs.gnu.org, larsi <at> gnus.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 19:47:23 +0100

Thanks, Eli and Stefan.  Just writing to confirm that removing the line

(cl-pushnew 'rear-nonsticky font-lock-extra-managed-props)

addresses the issue on my end (if suboptimally in the rare cases Stefan
alludes to).

Paul

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>,
 "Paul D. Nelson" <ultrono <at> gmail.com>,  larsi <at> gnus.org,
 77197-done <at> debbugs.gnu.org
Subject: Re: bug#77197: 31.0.50; forward-word fails after yanking into
 summary line of *vc-log*
Date: Mon, 24 Mar 2025 10:32:50 +0800

Hello,

Stefan, thanks for the fix, and Paul, thank you for testing it.

I agree with Stefan's assessment and so I've installed the line removal.

If this causes other bugs, we might want to fix them completely
differently, anyway.

-- 
Sean Whitton

Previous Next

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