GNU bug report logs -
#77197
31.0.50; forward-word fails after yanking into summary line of *vc-log*
Previous Next
Reported by: Paul Nelson <ultrono <at> gmail.com>
Date: Sun, 23 Mar 2025 01:17:05 UTC
Severity: normal
Found in version 31.0.50
Done: Sean Whitton <spwhitton <at> spwhitton.name>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> 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?
This bug report was last modified 59 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.