GNU bug report logs -
#79692
30.1.90; Documentation bug about font-lock-keywords-only and insert-{char,byte}
Previous Next
To reply to this bug, email your comments to 79692 AT debbugs.gnu.org.
There is no need to reopen the bug first.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Fri, 24 Oct 2025 18:05:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Aaron Zeng <azeng <at> janestreet.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 24 Oct 2025 18:05:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hello,
I was reading the Elisp manual page on Syntactic Font Lock and got a bit
confused by this part talking about font-lock-keywoords-only:
To use only syntactic fontification, this variable should be
non-‘nil’, while ‘font-lock-keywords’ should be set to ‘nil’ (*note
Font Lock Basics::).
If I'm understanding correctly, shouldn't this say that
font-lock-keywords-only and font-lock-keywords should both be nil to use
syntactic fontification? That is to say, setting
font-lock-keywords-only to non-nil will disable syntactic fontification.
Separately (sorry to combine these in one email), I think there is a
small bug in the documentation for insert-char and insert-byte. These
functions' docstrings say they "relocate point and before-insertion
markers" as `insert' does. I believe this should say "point and
after-insertion markers" instead, which is what `insert' and
`insert-and-inherit' say in their docstrings.
Best,
Aaron
In GNU Emacs 30.1.90 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-10-08 built on
igm-qws-u22796a
Repository revision: 31a5f279ffffae16a565bb3a4b88afcd615ff8ac
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --with-x-toolkit=lucid --without-gpm --without-gconf
--without-selinux --without-imagemagick --with-modules --with-gif=no
--with-cairo --with-rsvg --without-compress-install --with-tree-sitter
--with-native-compilation=aot
--prefix=/usr/local/home/garnish/raw-emacs/30-20251008_155103'
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB
Important settings:
value of $EMACSLOADPATH: /usr/local/home/azeng/workspaces/24833141-bffb-3c99-a9d6-c366d37c4f5e/+share+/app/emacs/elisp:/usr/local/home/azeng/workspaces/24833141-bffb-3c99-a9d6-c366d37c4f5e/+share+/app/emacs/site-lisp:
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
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:
None found.
Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib term/xterm xterm byte-opt gv bytecomp byte-compile
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image 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 regexp-opt 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 dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process native-compile emacs)
Memory information:
((conses 16 71180 12103) (symbols 48 6109 2) (strings 32 22687 2237)
(string-bytes 1 616305) (vectors 16 7173)
(vector-slots 8 83239 10316) (floats 8 26 1) (intervals 56 241 0)
(buffers 992 10))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Sat, 25 Oct 2025 07:54:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> Date: Fri, 24 Oct 2025 14:04:36 -0400
> From: Aaron Zeng via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>
> I was reading the Elisp manual page on Syntactic Font Lock and got a bit
> confused by this part talking about font-lock-keywoords-only:
>
> To use only syntactic fontification, this variable should be
> non-‘nil’, while ‘font-lock-keywords’ should be set to ‘nil’ (*note
> Font Lock Basics::).
>
> If I'm understanding correctly, shouldn't this say that
> font-lock-keywords-only and font-lock-keywords should both be nil to use
> syntactic fontification? That is to say, setting
> font-lock-keywords-only to non-nil will disable syntactic fontification.
I believe you are right.
I also think we have an unfortunate difference between the doc string
of the variable, which says "Non-nil means Font Lock should not
fontify comments or strings", and the description in the ELisp manual,
which says something much more generals. We should make them more
similar.
Stefan, any suggestions or comments?
> Separately (sorry to combine these in one email), I think there is a
> small bug in the documentation for insert-char and insert-byte. These
> functions' docstrings say they "relocate point and before-insertion
> markers" as `insert' does. I believe this should say "point and
> after-insertion markers" instead, which is what `insert' and
> `insert-and-inherit' say in their docstrings.
Why do you think the text should refer to after-insertion markers?
The effect of insertion on those is clear and obvious, whereas the
effect of insertion on before-insertion markers is not necessarily so.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Sat, 25 Oct 2025 13:33:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> I also think we have an unfortunate difference between the doc string
> of the variable, which says "Non-nil means Font Lock should not
> fontify comments or strings", and the description in the ELisp manual,
> which says something much more generals. We should make them more
> similar.
>
> Stefan, any suggestions or comments?
Non-nil tells font-lock not to use the syntactic-fontification.
In practice this usually fontifies strings and comments, but that
depends on the specifics of the mode. E.g. `syntax-propertize` and
`font-lock-syntactic-face-function` can be used together to cause
syntactic-fontification to fontify other elements, while other modes
use `font-lock-keywords` to fontify comments and/or strings, in which
case "Font Lock" will still fontify strings and comments even if
`font-lock-keywords-only` is t.
Note I put Font Lock in quotes above because it's not clear what it
means: does it refer to the mechanism used by `font-lock-keywords`,
or does it refer to the user-visible result controlled by
`font-lock-mode`?
Stefan
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 25 Oct 2025 14:00:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Aaron Zeng <azeng <at> janestreet.com>:
bug acknowledged by developer.
(Sat, 25 Oct 2025 14:00:03 GMT)
Full text and
rfc822 format available.
Message #16 received at 79692-done <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Aaron Zeng <azeng <at> janestreet.com>, 79692 <at> debbugs.gnu.org
> Date: Sat, 25 Oct 2025 09:32:02 -0400
>
> > I also think we have an unfortunate difference between the doc string
> > of the variable, which says "Non-nil means Font Lock should not
> > fontify comments or strings", and the description in the ELisp manual,
> > which says something much more generals. We should make them more
> > similar.
> >
> > Stefan, any suggestions or comments?
>
> Non-nil tells font-lock not to use the syntactic-fontification.
> In practice this usually fontifies strings and comments, but that
> depends on the specifics of the mode. E.g. `syntax-propertize` and
> `font-lock-syntactic-face-function` can be used together to cause
> syntactic-fontification to fontify other elements, while other modes
> use `font-lock-keywords` to fontify comments and/or strings, in which
> case "Font Lock" will still fontify strings and comments even if
> `font-lock-keywords-only` is t.
>
> Note I put Font Lock in quotes above because it's not clear what it
> means: does it refer to the mechanism used by `font-lock-keywords`,
> or does it refer to the user-visible result controlled by
> `font-lock-mode`?
OK, thanks. I've corrected/updated the documentation, and I'm
therefore closing this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 16:12:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 79692 <at> debbugs.gnu.org (full text, mbox):
On Sat, Oct 25, 2025 at 3:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> Why do you think the text should refer to after-insertion markers?
> The effect of insertion on those is clear and obvious, whereas the
> effect of insertion on before-insertion markers is not necessarily so.
Because insert-char and insert-byte do not relocate the before-insertion
markers as they say they do:
(with-temp-buffer
(let ((before-insertion-marker (copy-marker (point)))
(after-insertion-marker (copy-marker (point) t)))
(insert-char ?a)
(message "%d %d"
(marker-position before-insertion-marker)
(marker-position after-insertion-marker))))
The above code prints "1 2" on my box. It also prints "1 2" if I
change the insert-char
call to (insert "a").
So, it is correct that insert-char behaves like insert does, with respect
to relocating markers. But, contradicting its documentation, it
does not relocate before-insertion markers at all.
Please let me know if I've misunderstood your question!
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 16:28:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Zeng <azeng <at> janestreet.com>
> Date: Mon, 27 Oct 2025 12:10:54 -0400
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 79692 <at> debbugs.gnu.org
>
> On Sat, Oct 25, 2025 at 3:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > Why do you think the text should refer to after-insertion markers?
> > The effect of insertion on those is clear and obvious, whereas the
> > effect of insertion on before-insertion markers is not necessarily so.
>
> Because insert-char and insert-byte do not relocate the before-insertion
> markers as they say they do:
>
> (with-temp-buffer
> (let ((before-insertion-marker (copy-marker (point)))
> (after-insertion-marker (copy-marker (point) t)))
> (insert-char ?a)
> (message "%d %d"
> (marker-position before-insertion-marker)
> (marker-position after-insertion-marker))))
>
> The above code prints "1 2" on my box. It also prints "1 2" if I
> change the insert-char
> call to (insert "a").
>
> So, it is correct that insert-char behaves like insert does, with respect
> to relocating markers. But, contradicting its documentation, it
> does not relocate before-insertion markers at all.
>
> Please let me know if I've misunderstood your question!
You did. Markers have the insertion-type property (see "Marker
Insertion Types" in the ELisp manual), and copy-marker has an optional
2nd argument to control that. What happens if you do the above with
markers whose insertion-type is non-nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 16:36:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 79692 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 27, 2025 at 12:27 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Aaron Zeng <azeng <at> janestreet.com>
> > Date: Mon, 27 Oct 2025 12:10:54 -0400
> > Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 79692 <at> debbugs.gnu.org
> >
> > On Sat, Oct 25, 2025 at 3:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > >
> > > Why do you think the text should refer to after-insertion markers?
> > > The effect of insertion on those is clear and obvious, whereas the
> > > effect of insertion on before-insertion markers is not necessarily so.
> >
> > Because insert-char and insert-byte do not relocate the before-insertion
> > markers as they say they do:
> >
> > (with-temp-buffer
> > (let ((before-insertion-marker (copy-marker (point)))
> > (after-insertion-marker (copy-marker (point) t)))
> > (insert-char ?a)
> > (message "%d %d"
> > (marker-position before-insertion-marker)
> > (marker-position after-insertion-marker))))
> >
> > The above code prints "1 2" on my box. It also prints "1 2" if I
> > change the insert-char
> > call to (insert "a").
> >
> > So, it is correct that insert-char behaves like insert does, with respect
> > to relocating markers. But, contradicting its documentation, it
> > does not relocate before-insertion markers at all.
> >
> > Please let me know if I've misunderstood your question!
>
> You did. Markers have the insertion-type property (see "Marker
> Insertion Types" in the ELisp manual), and copy-marker has an optional
> 2nd argument to control that.
Yes, please see the argument passed to copy-marker for the definition
of after-insertion-marker.
> What happens if you do the above with
> markers whose insertion-type is non-nil?
before-insertion-marker's insertion-type is nil
after-insertion-marker's insertion-type is t
Both markers are created at position 1 in an empty buffer, so I
would expect only after-insertion-marker to move when inserting
at that position, which it does.
My claim is that insert-char and insert-byte have the same behavior
as insert, w.r.t. the two insertion-type values that markers can have.
But the documentation implies otherwise, that somehow insert-char
always moves before-insertion markers in addition to point.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 17:42:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Zeng <azeng <at> janestreet.com>
> Date: Mon, 27 Oct 2025 12:34:33 -0400
> Cc: monnier <at> iro.umontreal.ca, 79692 <at> debbugs.gnu.org
>
> My claim is that insert-char and insert-byte have the same behavior
> as insert, w.r.t. the two insertion-type values that markers can have.
> But the documentation implies otherwise, that somehow insert-char
> always moves before-insertion markers in addition to point.
The doc string says:
Inserting the character(s) relocates point and before-insertion
markers in the same ways as the function ‘insert’.
So I don't see how this can be taken as saying that the behavior
_differs_ from that of 'insert'. I guess I'm missing something very
basic here.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 79692 <at> debbugs.gnu.org (full text, mbox):
On Mon, Oct 27, 2025 at 1:41 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Aaron Zeng <azeng <at> janestreet.com>
> > Date: Mon, 27 Oct 2025 12:34:33 -0400
> > Cc: monnier <at> iro.umontreal.ca, 79692 <at> debbugs.gnu.org
> >
> > My claim is that insert-char and insert-byte have the same behavior
> > as insert, w.r.t. the two insertion-type values that markers can have.
> > But the documentation implies otherwise, that somehow insert-char
> > always moves before-insertion markers in addition to point.
>
> The doc string says:
>
> Inserting the character(s) relocates point and before-insertion
> markers in the same ways as the function ‘insert’.
Inserting the character(s) does *not* relocate the before-insertion markers.
They remain at exactly the same position after insert-char finishes.
> So I don't see how this can be taken as saying that the behavior
> _differs_ from that of 'insert'. I guess I'm missing something very
> basic here.
I mean, I guess you could argue that insert-char relocates before-insertion
markers the same way that insert does, *in that it does not move them at all*,
but that is, in my opinion, needlessly confusing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 18:29:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> From: Aaron Zeng <azeng <at> janestreet.com>
> Date: Mon, 27 Oct 2025 14:04:29 -0400
> Cc: monnier <at> iro.umontreal.ca, 79692 <at> debbugs.gnu.org
>
> On Mon, Oct 27, 2025 at 1:41 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> > > From: Aaron Zeng <azeng <at> janestreet.com>
> > > Date: Mon, 27 Oct 2025 12:34:33 -0400
> > > Cc: monnier <at> iro.umontreal.ca, 79692 <at> debbugs.gnu.org
> > >
> > > My claim is that insert-char and insert-byte have the same behavior
> > > as insert, w.r.t. the two insertion-type values that markers can have.
> > > But the documentation implies otherwise, that somehow insert-char
> > > always moves before-insertion markers in addition to point.
> >
> > The doc string says:
> >
> > Inserting the character(s) relocates point and before-insertion
> > markers in the same ways as the function ‘insert’.
>
> Inserting the character(s) does *not* relocate the before-insertion markers.
> They remain at exactly the same position after insert-char finishes.
And why is it a problem to say that explicitly? It is as self-evident
as saying that after-insertion markers move when text is inserted,
isn't it?
> > So I don't see how this can be taken as saying that the behavior
> > _differs_ from that of 'insert'. I guess I'm missing something very
> > basic here.
>
> I mean, I guess you could argue that insert-char relocates before-insertion
> markers the same way that insert does, *in that it does not move them at all*,
> but that is, in my opinion, needlessly confusing.
I think this doc string wants to contrast the behavior with
insert-before-markers and insert-before-markers-and-inherit.
Stefan, WDYT?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Mon, 27 Oct 2025 20:57:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> I think this doc string wants to contrast the behavior with
> insert-before-markers and insert-before-markers-and-inherit.
I do find it confusing because it lists some elements but not all.
E.g. it doesn't say that it moves after-insertion markers the same way
as `insert`. I think the simplest fix is to remove " and
before-insertion".
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Thu, 30 Oct 2025 09:54:01 GMT)
Full text and
rfc822 format available.
Message #40 received at 79692 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Aaron Zeng <azeng <at> janestreet.com>, 79692 <at> debbugs.gnu.org
> Date: Mon, 27 Oct 2025 16:56:28 -0400
>
> > I think this doc string wants to contrast the behavior with
> > insert-before-markers and insert-before-markers-and-inherit.
>
> I do find it confusing because it lists some elements but not all.
> E.g. it doesn't say that it moves after-insertion markers the same way
> as `insert`. I think the simplest fix is to remove " and
> before-insertion".
How about the following changes:
diff --git a/src/editfns.c b/src/editfns.c
index 8c83784..d3a4c22 100644
--- a/src/editfns.c
+++ b/src/editfns.c
@@ -1396,7 +1396,10 @@ DEFUN ("insert-and-inherit", Finsert_and_inherit, Sinsert_and_inherit,
DEFUN ("insert-before-markers", Finsert_before_markers, Sinsert_before_markers, 0, MANY, 0,
doc: /* Insert strings or characters at point, relocating markers after the text.
-Point and markers move forward to end up after the inserted text.
+Point and all markers at or after the insertion point move forward to
+end up after the inserted text. This is unlike with `insert' and other
+insertion functions, where before-insertion markers remain before the
+inserted text.
If the current buffer is multibyte, unibyte strings are converted
to multibyte for insertion (see `unibyte-char-to-multibyte').
@@ -1419,7 +1422,10 @@ DEFUN ("insert-before-markers", Finsert_before_markers, Sinsert_before_markers,
DEFUN ("insert-before-markers-and-inherit", Finsert_and_inherit_before_markers,
Sinsert_and_inherit_before_markers, 0, MANY, 0,
doc: /* Insert text at point, relocating markers and inheriting properties.
-Point and markers move forward to end up after the inserted text.
+Point and all markers at or after the insertion point move forward to
+end up after the inserted text. This is unlike with `insert' and other
+insertion functions, where before-insertion markers remain before the
+inserted text.
If the current buffer is multibyte, unibyte strings are converted
to multibyte for insertion (see `unibyte-char-to-multibyte').
@@ -1463,8 +1469,8 @@ DEFUN ("insert-char", Finsert_char, Sinsert_char, 1, 3,
When called interactively, COUNT is the prefix argument. If omitted or
nil, it defaults to 1.
-Inserting the character(s) relocates point and before-insertion
-markers in the same ways as the function `insert'.
+Inserting the character(s) relocates point and markers in the same ways
+as the function `insert'.
The optional third argument INHERIT, if non-nil, says to inherit text
properties from adjoining text, if those properties are sticky. When
@@ -1520,7 +1526,8 @@ DEFUN ("insert-byte", Finsert_byte, Sinsert_byte, 2, 3, 0,
If BYTE is 128..255 and the current buffer is multibyte, the
corresponding eight-bit character is inserted.
-Point, and before-insertion markers, are relocated as in the function `insert'.
+Point and markers are relocated as in the function `insert'.
+
The optional third arg INHERIT, if non-nil, says to inherit text properties
from adjoining text, if those properties are sticky. */)
(Lisp_Object byte, Lisp_Object count, Lisp_Object inherit)
@@ -1707,9 +1714,7 @@ DEFUN ("insert-buffer-substring", Finsert_buffer_substring, Sinsert_buffer_subst
Arguments START and END are character positions specifying the substring.
They default to the values of (point-min) and (point-max) in BUFFER.
-Point and before-insertion markers move forward to end up after the
-inserted text.
-Any other markers at the point of insertion remain before the text.
+Point and markers are relocated as in the function `insert'.
If the current buffer is multibyte and BUFFER is unibyte, or vice
versa, strings are converted from unibyte to multibyte or vice versa
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#79692; Package
emacs.
(Thu, 30 Oct 2025 14:59:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 79692 <at> debbugs.gnu.org (full text, mbox):
On Thu, Oct 30, 2025 at 5:53 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> > Cc: Aaron Zeng <azeng <at> janestreet.com>, 79692 <at> debbugs.gnu.org
> > Date: Mon, 27 Oct 2025 16:56:28 -0400
> >
> > > I think this doc string wants to contrast the behavior with
> > > insert-before-markers and insert-before-markers-and-inherit.
> >
> > I do find it confusing because it lists some elements but not all.
> > E.g. it doesn't say that it moves after-insertion markers the same way
> > as `insert`. I think the simplest fix is to remove " and
> > before-insertion".
>
> How about the following changes:
This patch looks good to me. In particular it clears up the
"insert-char is like insert which is
not like insert-before-markers" relationships, so thanks!
This bug report was last modified 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.