GNU bug report logs - #79047
Add some multi-character pairs to some major modes.

Previous Next

Package: emacs;

Reported by: Elijah Gabe Pérez <eg642616 <at> gmail.com>

Date: Sat, 19 Jul 2025 02:05:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

To reply to this bug, email your comments to 79047 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 02:05:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Elijah Gabe Pérez <eg642616 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 19 Jul 2025 02:05:02 GMT) Full text and rfc822 format available.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Add some multi-character pairs to some major modes.
Date: Fri, 18 Jul 2025 20:04:12 -0600
Since `electric-pair-mode` now supports multi-character pairs, it would
be better if some major modes add some of these pairs.

Before making the patch for this (and to avoid doing another regression
like bug#77823), here is a list of the modes and their possible pairs:

 - c-like modes
     "/*" "*/"
 - lua-ts-mode
     "--[" "--]"
 - texinfo-mode (idk which others one) (based in a Stefan Monnier idea)
     "``" "''"
 - lisp-mode (common-lisp-mode)
    "#|" "|#"

What do you think?

-- 
- E.G via GNU Emacs and Org.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 06:44:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 Alan Mackenzie <acm <at> muc.de>, John Muhl <jm <at> pub.pink>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79047 <at> debbugs.gnu.org
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 19 Jul 2025 09:42:52 +0300
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Date: Fri, 18 Jul 2025 20:04:12 -0600
> 
> Since `electric-pair-mode` now supports multi-character pairs, it would
> be better if some major modes add some of these pairs.
> 
> Before making the patch for this (and to avoid doing another regression
> like bug#77823), here is a list of the modes and their possible pairs:
> 
>  - c-like modes
>      "/*" "*/"
>  - lua-ts-mode
>      "--[" "--]"
>  - texinfo-mode (idk which others one) (based in a Stefan Monnier idea)
>      "``" "''"
>  - lisp-mode (common-lisp-mode)
>     "#|" "|#"
> 
> What do you think?

When discussing in a bug report issues related to some specific
packages, it is usually a good idea to CC the authors/developers of
those packages, because we cannot be sure they track the bug-gnu-emacs
list all the time.

I've now added people who I think are relevant to your proposal.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 11:01:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, John Muhl <jm <at> pub.pink>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 19 Jul 2025 11:00:21 +0000
Hello, Eli.

Thanks for the heads up!

On Sat, Jul 19, 2025 at 09:42:52 +0300, Eli Zaretskii wrote:
> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 20:04:12 -0600

> > Since `electric-pair-mode` now supports multi-character pairs, it would
> > be better if some major modes add some of these pairs.

> > Before making the patch for this (and to avoid doing another regression
> > like bug#77823), here is a list of the modes and their possible pairs:

> >  - c-like modes
> >      "/*" "*/"

Elijah, I'm speaking here from the point of view of CC Mode.

What exactly do you mean by "adding" these multi-character pairs?  What
would the user see that she doesn't already see?

Or are you talking about doing something we already do, but in a
different way?

> >  - lua-ts-mode
> >      "--[" "--]"
> >  - texinfo-mode (idk which others one) (based in a Stefan Monnier idea)
> >      "``" "''"
> >  - lisp-mode (common-lisp-mode)
> >     "#|" "|#"

> > What do you think?

> When discussing in a bug report issues related to some specific
> packages, it is usually a good idea to CC the authors/developers of
> those packages, because we cannot be sure they track the bug-gnu-emacs
> list all the time.

> I've now added people who I think are relevant to your proposal.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 16:40:01 GMT) Full text and rfc822 format available.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 19 Jul 2025 10:39:03 -0600
Alan Mackenzie <acm <at> muc.de> writes:

>> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> > Date: Fri, 18 Jul 2025 20:04:12 -0600
>
>> > Since `electric-pair-mode` now supports multi-character pairs, it would
>> > be better if some major modes add some of these pairs.
>
>> > Before making the patch for this (and to avoid doing another regression
>> > like bug#77823), here is a list of the modes and their possible pairs:
>
>> >  - c-like modes
>> >      "/*" "*/"
>
> Elijah, I'm speaking here from the point of view of CC Mode.
>
> What exactly do you mean by "adding" these multi-character pairs?  What
> would the user see that she doesn't already see?

These pairs are meant to be used in for auto-close block comments, after
the user types "/*", the corresponding "*/" will be inserted, packages
such as smartparens provide this behavior to most C-like modes.

> Or are you talking about doing something we already do, but in a
> different way?

I don't know if CC Mode have something similar.

-- 
- E.G via GNU Emacs and Org.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 16:53:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>,
 John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 19 Jul 2025 16:52:45 +0000
Hello, Elijah.

On Sat, Jul 19, 2025 at 10:39:03 -0600, Elijah Gabe Pérez wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> >> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> >> > Date: Fri, 18 Jul 2025 20:04:12 -0600

> >> > Since `electric-pair-mode` now supports multi-character pairs, it would
> >> > be better if some major modes add some of these pairs.

> >> > Before making the patch for this (and to avoid doing another regression
> >> > like bug#77823), here is a list of the modes and their possible pairs:

> >> >  - c-like modes
> >> >      "/*" "*/"

> > Elijah, I'm speaking here from the point of view of CC Mode.

> > What exactly do you mean by "adding" these multi-character pairs?  What
> > would the user see that she doesn't already see?

> These pairs are meant to be used in for auto-close block comments, after
> the user types "/*", the corresponding "*/" will be inserted, packages
> such as smartparens provide this behavior to most C-like modes.

OK, thanks.

But who's going to want to do this when there's M-; `comment-dwim' which
inserts both the comment opener and comment closer in a single key
stroke?  Surely anybody typing /* explicitly will being doing so on a
rare occasion when she _doesn't_ want the closing */ also inserted.

> > Or are you talking about doing something we already do, but in a
> > different way?

> I don't know if CC Mode have something similar.

M-; is common to most (?all) programming and text modes.

> -- 
> - E.G via GNU Emacs and Org.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 18:28:02 GMT) Full text and rfc822 format available.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 19 Jul 2025 12:26:59 -0600
Alan Mackenzie <acm <at> muc.de> writes:

>> > Elijah, I'm speaking here from the point of view of CC Mode.
>
>> > What exactly do you mean by "adding" these multi-character pairs?  What
>> > would the user see that she doesn't already see?
>
>> These pairs are meant to be used in for auto-close block comments, after
>> the user types "/*", the corresponding "*/" will be inserted, packages
>> such as smartparens provide this behavior to most C-like modes.
>
> OK, thanks.
>
> But who's going to want to do this when there's M-; `comment-dwim' which
> inserts both the comment opener and comment closer in a single key
> stroke?

comment-dwim sometimes doesn't insert the comments where i want, it
mostly insert the comments at the end of the line, or indent them
according to `comment-column` (which ofc can be configured, but in most
the cases, it will not work as expected).

> Surely anybody typing /* explicitly will being doing so on a
> rare occasion when she _doesn't_ want the closing */ also inserted.

The feature can be optional, enabled via an user option or command,
similar to `c-toggle-auto-newline`.

>> > Or are you talking about doing something we already do, but in a
>> > different way?
>
>> I don't know if CC Mode have something similar.
>
> M-; is common to most (?all) programming and text modes.

Right, but calling comment-dwim in some modes doesn't insert a block
comment, even if those modes supports block comments, (e.g. js-mode)

-- 
- E.G via GNU Emacs and Org.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 19 Jul 2025 18:53:01 GMT) Full text and rfc822 format available.

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

From: john muhl <jm <at> pub.pink>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, Alan Mackenzie <acm <at> muc.de>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 19 Jul 2025 13:51:39 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Date: Fri, 18 Jul 2025 20:04:12 -0600
>> 
>> Since `electric-pair-mode` now supports multi-character pairs, it would
>> be better if some major modes add some of these pairs.
>> 
>> Before making the patch for this (and to avoid doing another regression
>> like bug#77823), here is a list of the modes and their possible pairs:
>> 
>>  - c-like modes
>>      "/*" "*/"
>>  - lua-ts-mode
>>      "--[" "--]"
>>  - texinfo-mode (idk which others one) (based in a Stefan Monnier idea)
>>      "``" "''"
>>  - lisp-mode (common-lisp-mode)
>>     "#|" "|#"
>> 
>> What do you think?
>
> When discussing in a bug report issues related to some specific
> packages, it is usually a good idea to CC the authors/developers of
> those packages, because we cannot be sure they track the bug-gnu-emacs
> list all the time.
>
> I've now added people who I think are relevant to your proposal.
>
> Thanks.

I’m not sure what the question is here but in general if someone finds
something useful to add to lua-ts-mode I’m fine with it; especially if
it comes with tests for the change.

Just reading the above I’d point out that Lua multi-line comments aren’t
symmetrical:

  --[[
  Here is a very
  long comment.
  ]]

and electric-pair-mode already works in that case.

Some people like to add a second pair of dashes before the closing
brackets but they are stylistic, not a requirement.

Elijah, if I missed the point then maybe you could show the proposed
patch to lua-ts-mode.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sun, 20 Jul 2025 11:31:01 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>,
 John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sun, 20 Jul 2025 11:30:04 +0000
Hello, Elijah.

One important point.

On Sat, Jul 19, 2025 at 09:42:52 +0300, Eli Zaretskii wrote:
> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > Date: Fri, 18 Jul 2025 20:04:12 -0600

> > Since `electric-pair-mode` now supports multi-character pairs, it would
> > be better if some major modes add some of these pairs.

Are you sure about this?  In NEWS, there is the rather sloppily worded
entry:

    ** Electric Pair mode can now pair multiple delimiters at once.
    You can now insert or wrap text with multiple sets of parentheses and
    other matching delimiters at once with Electric Pair mode, by providing
    a prefix argument when inserting one of the delimiters.

It uses the sloppy American English ambiguity where "multiple" can mean
either "several", or "composed of several parts".  In correct British
English "multiple" has only the latter meaning.

I think in this NEWS entry the meaning "several" was intended, and you
may have misread it.  I don't think electric-pair-mode has any facilities
for pairing a multiple delimiter; only for pairing several of the same
delimiter at once, e.g. (((....))).

Please check if I am correct or mistaken on this point.  If I'm correct,
then the prerequisites for implementing this change are absent, and there
is nothing more to discuss.

> > Before making the patch for this (and to avoid doing another regression
> > like bug#77823), here is a list of the modes and their possible pairs:

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Tue, 22 Jul 2025 23:04:02 GMT) Full text and rfc822 format available.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Tue, 22 Jul 2025 17:03:34 -0600
Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Elijah.
>
> One important point.
>
> Are you sure about this?  In NEWS, there is the rather sloppily worded
> entry:
>
>     ** Electric Pair mode can now pair multiple delimiters at once.
>     You can now insert or wrap text with multiple sets of parentheses and
>     other matching delimiters at once with Electric Pair mode, by providing
>     a prefix argument when inserting one of the delimiters.
>
> It uses the sloppy American English ambiguity where "multiple" can mean
> either "several", or "composed of several parts".  In correct British
> English "multiple" has only the latter meaning.
>
> I think in this NEWS entry the meaning "several" was intended, and you
> may have misread it.  I don't think electric-pair-mode has any facilities
> for pairing a multiple delimiter; only for pairing several of the same
> delimiter at once, e.g. (((....))).

That is the wrong NEWS entry of the feature.
The real one is this:

  *** Electric Pair mode now supports multi-character paired delimiters.
  'electric-pair-pairs' and 'electric-pair-text-pairs' now allow using
  strings for multi-character paired delimiters.

  To use this, add a list to both electric pair user options: '("/*" . "*/")'.

  You can also specify to insert an extra space after the first string
  pair: '("/*" " */" t)'.

> Please check if I am correct or mistaken on this point.  If I'm correct,
> then the prerequisites for implementing this change are absent, and there
> is nothing more to discuss.

I've tested the feature, it's possible to achieve it:

  (setq electric-pair-pairs `((,(regexp-quote "/*") " */" t)))

  /* | */
       ^^ After inserting the * character.
          (the extra whitespace is optionally included)

-- 
- E.G via GNU Emacs and Org.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 24 Jul 2025 13:40:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 24 Jul 2025 13:39:16 +0000
Hello Elijah.

On Tue, Jul 22, 2025 at 17:03:34 -0600, Elijah Gabe Pérez wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

[ .... ]

> > Are you sure about this?  ....

[ .... ]

> That is the wrong NEWS entry of the feature.
> The real one is this:

>   *** Electric Pair mode now supports multi-character paired delimiters.
>   'electric-pair-pairs' and 'electric-pair-text-pairs' now allow using
>   strings for multi-character paired delimiters.

Apologies.  I missed this one, somehow.  This NEWS entry is part of 

commit 60fbeda771639ded68ffd0666df340c7a06cafcf
Author: Elías Gabriel Pérez <eg642616 <at> gmail.com>
Date:   Thu Apr 24 17:34:58 2025 -0600

    Support strings for electric pairs (bug#78053)

..  This commit appears to me to be incomplete.  In particular:

(i) The doc string of electric-pair-syntax-info hasn't been modified to
  reflect the result component SYNTAX possibly being the symbol `str'.

(ii) The insertion of string pairs at ~L692 in
  electric-pair-post-self-insert-function neglects to check
  electric-pair-inhibit-predicate.  It's unclear why this isn't done, but
  if there's a good reason it should be documented somewhere (if it isn't
  already; I haven't actually checked).  e-p-inhibit-predicate gets used,
  and not handling it makes the insertion of string pairs inconsistent
  with the rest of electric-pair mode and less useful.

(iii) I don't think you've documented anywhere that the first string in
  an entry in electric-pair-pairs is actually a regular expression.
  (Again, I haven't rigorously searched for such documentation.)

>   To use this, add a list to both electric pair user options: '("/*" . "*/")'.

>   You can also specify to insert an extra space after the first string
>   pair: '("/*" " */" t)'.

[ .... ]

> I've tested the feature, it's possible to achieve it:

[ .... ]

Yes, sort of.  But electric pair mode's implementation violates an
(unwritten) Emacs convention about hooks, i.e. that a hook function
doesn't mess with the functionality that invoked it.  For example, a
function in window-scroll-functions may not change the scrolling state of
a window, and an after-change-functions function never changes the text
of a buffer.

By contrast, electric-pair-post-self-insert-function does mess with the
invoking functionality, namely self-insert-command; it inserts further
characters.  From the point of view of a Lisp program, this makes
self-insert-function an undefined function - what it does varies from
time to time and from buffer to buffer.

CC Mode has had to implement a workaround for this, namely binding
post-self-insert-function to nil (to get defined functionality for
self-insert-command), then later calling
electric-pair-post-self-insert-function by hand, to get the electric pair
functionality.  It's ugly and anything but robust.

So, yes, it is possible to get the functionality in CC Mode with ("/\\*"
" */" t), but it is not entirely trivial.

> -- 
> - E.G via GNU Emacs and Org.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 24 Jul 2025 14:55:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 24 Jul 2025 17:53:55 +0300
> Date: Thu, 24 Jul 2025 13:39:16 +0000
> Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
>   John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Alan Mackenzie <acm <at> muc.de>
> 
> Yes, sort of.  But electric pair mode's implementation violates an
> (unwritten) Emacs convention about hooks, i.e. that a hook function
> doesn't mess with the functionality that invoked it.  For example, a
> function in window-scroll-functions may not change the scrolling state of
> a window, and an after-change-functions function never changes the text
> of a buffer.
> 
> By contrast, electric-pair-post-self-insert-function does mess with the
> invoking functionality, namely self-insert-command; it inserts further
> characters.  From the point of view of a Lisp program, this makes
> self-insert-function an undefined function - what it does varies from
> time to time and from buffer to buffer.

?? post-self-insert-hook is specifically mean for features that insert
additional characters, or even replace characters by others.
Otherwise, what would that hook be good for?

The ELisp manual says about this: "You could use this to automatically
reindent text as it is typed, for example."  And what is reindentation
if not removal of some characters and insertion of others?

So I don't understand the nature of your dislike in this case.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 24 Jul 2025 15:55:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 24 Jul 2025 15:54:14 +0000
Hello, Eli.

On Thu, Jul 24, 2025 at 17:53:55 +0300, Eli Zaretskii wrote:
> > Date: Thu, 24 Jul 2025 13:39:16 +0000
> > Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
> >   John Muhl <jm <at> pub.pink>, Stefan Monnier <monnier <at> iro.umontreal.ca>
> > From: Alan Mackenzie <acm <at> muc.de>

> > Yes, sort of.  But electric pair mode's implementation violates an
> > (unwritten) Emacs convention about hooks, i.e. that a hook function
> > doesn't mess with the functionality that invoked it.  For example, a
> > function in window-scroll-functions may not change the scrolling state of
> > a window, and an after-change-functions function never changes the text
> > of a buffer.

> > By contrast, electric-pair-post-self-insert-function does mess with the
> > invoking functionality, namely self-insert-command; it inserts further
> > characters.  From the point of view of a Lisp program, this makes
> > self-insert-function an undefined function - what it does varies from
> > time to time and from buffer to buffer.

> ?? post-self-insert-hook is specifically mean for features that insert
> additional characters, or even replace characters by others.
> Otherwise, what would that hook be good for?

Nothing, as far as I can see.  I see no legitimate need for that hook.

> The ELisp manual says about this: "You could use this to automatically
> reindent text as it is typed, for example."  And what is reindentation
> if not removal of some characters and insertion of others?



> So I don't understand the nature of your dislike in this case.

I'll start off with the abstract:

It breaks the abstraction mentioned in my first paragraph above that
hook functions do things ancillary to the main function, and do not
constitute part of it.  So that, for example, in an
after-change-functions function, you know that no deletion by a previous
a-c-f will have made the START, END, and OLD-LEN arguments invalid.

This principle holds for all hook uses I'm aware of except for
post-self-insert-function.  It enables Lisp coding to be done sensibly
without having to program around all the "what if"s which would arise by
people programming buffer changes into a-c-f's, or amending the
scrolling inside a window-scroll-functions function for example.

Now the concrete:

c-electric-paren, for example, does EOL cleanups after inserting the ?\(
the user typed using self-insert-command - this involves detecting that
the newly inserted ?\( is at EOL (modulo whitespace).  This breaks when
electric-pair-post-self-insert-function (or anything else on that hook)
inserts further characters after the one the user has typed.

As a workaround, I bind post-self-insert-hook to nil around the call to
self-insert-command, this being the only way I know to get predictable
functionality from self-insert-command.  Later I have to call
electric-pair-post-self-insert-function explicitly from
c-electric-paren.  This is neither robust nor future proof.

The error here is that post-self-insert-hook is invoked from the middle
of the command using self-insert-function, rather than after its end.
One way of fixing this would be to put
electric-pair-post-self-insert-function on post-command-hook instead.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 24 Jul 2025 17:03:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, jm <at> pub.pink,
 eg642616 <at> gmail.com
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 24 Jul 2025 13:02:13 -0400
> As a workaround, I bind post-self-insert-hook to nil around the call to
> self-insert-command, this being the only way I know to get predictable
> functionality from self-insert-command.

"predictable functionality" and `self-insert-command` don't get along
very well, I'm afraid (e.g. because of `auto-fill-chars` and abbrev
expansion).

Part of the problem is fundamental, I think: when several forms of
electricity want to affect the same key, there is inevitably some
delicate issues that require them to cooperate to some extent.
It's hard to make them work together peacefully *and* modularily at the
same time.

> The error here is that post-self-insert-hook is invoked from the middle
> of the command using self-insert-function, rather than after its end.
> One way of fixing this would be to put
> electric-pair-post-self-insert-function on post-command-hook instead.

That tends to move the problem: it would be your code which risks
breaking the others, rather than other way around.

I don't have a solution which I would call "good", but the best we have
so far is to get rid of the `c-electric-paren` command and turn it into
a hook added to `post-self-insert-hook` instead.  This will let you use
the DEPTH argument of `add-hook` to control when it is run w.r.t to the
other hooks.

That's what the other `electric-FOO-mode` do to cohabit.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 24 Jul 2025 18:48:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, Eli Zaretskii <eliz <at> gnu.org>,
 jm <at> pub.pink, eg642616 <at> gmail.com
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 24 Jul 2025 18:47:24 +0000
Hello, Stefan.

Thanks for your reply.

Sadly you snipped the key section of my last post.  Here it is again:

> > But electric pair mode's implementation violates an (unwritten) Emacs
> > convention about hooks, i.e. that a hook function doesn't mess with
> > the functionality that invoked it.  For example, a function in
> > window-scroll-functions may not change the scrolling state of a
> > window, and an after-change-functions function never changes the text
> > of a buffer.

> > By contrast, electric-pair-post-self-insert-function does mess with
> > the invoking functionality, namely self-insert-command; it inserts
> > further characters.  From the point of view of a Lisp program, this
> > makes self-insert-function an undefined function - what it does
> > varies from time to time and from buffer to buffer.

As you're aware, when faced with a problem, I tend to analyse the cause
at the appropriately abstract level, and then fix that cause, rather than
just paper over the problem with some unsatisfactory workaround.

The fundamental cause of this problem with electric pair mode is, I
believe, in my two quoted paragraphs above.  I ask you to answer the
points made in these two paragraphs.

Thanks!

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 24 Jul 2025 20:46:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, jm <at> pub.pink,
 eg642616 <at> gmail.com
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 24 Jul 2025 16:45:27 -0400
> The fundamental cause of this problem with electric pair mode is, I
> believe, in my two quoted paragraphs above.  I ask you to answer the
> points made in these two paragraphs.

I understand it to mean that the problem is philosophical.
That's fine, but I don't see how it helps us address the concrete issue.
For that reason I did not have anything to say about those two paragraphs.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 06:54:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 09:53:03 +0300
> Date: Thu, 24 Jul 2025 18:47:24 +0000
> Cc: Eli Zaretskii <eliz <at> gnu.org>, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
>   jm <at> pub.pink, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > But electric pair mode's implementation violates an (unwritten) Emacs
> > > convention about hooks, i.e. that a hook function doesn't mess with
> > > the functionality that invoked it.  For example, a function in
> > > window-scroll-functions may not change the scrolling state of a
> > > window, and an after-change-functions function never changes the text
> > > of a buffer.
> 
> > > By contrast, electric-pair-post-self-insert-function does mess with
> > > the invoking functionality, namely self-insert-command; it inserts
> > > further characters.  From the point of view of a Lisp program, this
> > > makes self-insert-function an undefined function - what it does
> > > varies from time to time and from buffer to buffer.
> 
> As you're aware, when faced with a problem, I tend to analyse the cause
> at the appropriately abstract level, and then fix that cause, rather than
> just paper over the problem with some unsatisfactory workaround.
> 
> The fundamental cause of this problem with electric pair mode is, I
> believe, in my two quoted paragraphs above.  I ask you to answer the
> points made in these two paragraphs.

And as I already mention, you perceive a convention where there is
none.  Thus electric-pair-mode doesn't violate any conventions.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 10:33:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 10:32:15 +0000
Hello, Eli.

On Fri, Jul 25, 2025 at 09:53:03 +0300, Eli Zaretskii wrote:
> > Date: Thu, 24 Jul 2025 18:47:24 +0000
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
> >   jm <at> pub.pink, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > > But electric pair mode's implementation violates an (unwritten) Emacs
> > > > convention about hooks, i.e. that a hook function doesn't mess with
> > > > the functionality that invoked it.  For example, a function in
> > > > window-scroll-functions may not change the scrolling state of a
> > > > window, and an after-change-functions function never changes the text
> > > > of a buffer.

> > > > By contrast, electric-pair-post-self-insert-function does mess with
> > > > the invoking functionality, namely self-insert-command; it inserts
> > > > further characters.  From the point of view of a Lisp program, this
> > > > makes self-insert-function an undefined function - what it does
> > > > varies from time to time and from buffer to buffer.

> > As you're aware, when faced with a problem, I tend to analyse the cause
> > at the appropriately abstract level, and then fix that cause, rather than
> > just paper over the problem with some unsatisfactory workaround.

> > The fundamental cause of this problem with electric pair mode is, I
> > believe, in my two quoted paragraphs above.  I ask you to answer the
> > points made in these two paragraphs.

> And as I already mention, you perceive a convention where there is
> none.

OK, then, Emacs hackers have abided by this non-convention nevertheless,
out of instinctive good sense and good taste.  Up until
post-self-insert-hook.

> Thus electric-pair-mode doesn't violate any conventions.

self-insert-command, called from Lisp, is broken.  There is no usable
definition of its functionality.  So far, there is no competing analysis
to mine as to how it's broken.  Stefan's "solution" is not to use
self-insert-command.  This is impractical for c-electric-paren and
friends.  Incidentally there are around 122 uses of self-insert-command
in Emacs.

So it's looking like the ugly workarounds in c-electric-paren to use
self-insert-command will have to remain.  I'm disappointed about this.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 11:09:03 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 14:08:43 +0300
> Date: Fri, 25 Jul 2025 10:32:15 +0000
> Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
>   jm <at> pub.pink, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > And as I already mention, you perceive a convention where there is
> > none.
> 
> OK, then, Emacs hackers have abided by this non-convention nevertheless,
> out of instinctive good sense and good taste.  Up until
> post-self-insert-hook.

Which might mean there was no non-convention to begin with.

> > Thus electric-pair-mode doesn't violate any conventions.
> 
> self-insert-command, called from Lisp, is broken.  There is no usable
> definition of its functionality.

What's wrong with its doc string as that definition?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 11:43:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 11:42:37 +0000
Hello, Eli.

On Fri, Jul 25, 2025 at 14:08:43 +0300, Eli Zaretskii wrote:
> > Date: Fri, 25 Jul 2025 10:32:15 +0000
> > Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
> >   jm <at> pub.pink, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > And as I already mention, you perceive a convention where there is
> > > none.

> > OK, then, Emacs hackers have abided by this non-convention nevertheless,
> > out of instinctive good sense and good taste.  Up until
> > post-self-insert-hook.

> Which might mean there was no non-convention to begin with.

> > > Thus electric-pair-mode doesn't violate any conventions.

> > self-insert-command, called from Lisp, is broken.  There is no usable
> > definition of its functionality.

> What's wrong with its doc string as that definition?

It's inaccurate and misleading.

We have:

    Insert the character you type.
    Whichever character C you type to run this command is inserted.
    [Plus all the bits about the numeric prefix, abbreviations, etc.]

More accurate would be:

    Maybe insert the character you type (depending on
    post-self-insert-hook).
    Insert or delete further characters as specified by
    post-self-insert-hook.
    Leave point at the position determined by post-self-insert-hook or
    after the inserted character.

..  This makes it unusable in a Lisp program.  For example, in
c-electric-paren, which handles the user entering "(" or ")", the code
needs to determine whether the "(" was entered at the end of a line.
The current self-insert-command, which inserts arbitrary further
characters, makes this difficult.

With the current self-insert-command, there is no satisfactory way of
coding c-electric-paren - only workarounds with varying degrees of
ugliness.

I am suggesting that self-insert-command should be made usable from Lisp
again, as it once was, and have suggested a means for achieving this.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 12:03:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 15:02:12 +0300
> Date: Fri, 25 Jul 2025 11:42:37 +0000
> Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
>   jm <at> pub.pink, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > > self-insert-command, called from Lisp, is broken.  There is no usable
> > > definition of its functionality.
> 
> > What's wrong with its doc string as that definition?
> 
> It's inaccurate and misleading.
> 
> We have:
> 
>     Insert the character you type.
>     Whichever character C you type to run this command is inserted.
>     [Plus all the bits about the numeric prefix, abbreviations, etc.]
> 
> More accurate would be:
> 
>     Maybe insert the character you type (depending on
>     post-self-insert-hook).
>     Insert or delete further characters as specified by
>     post-self-insert-hook.
>     Leave point at the position determined by post-self-insert-hook or
>     after the inserted character.

Of course, if you truncate the doc string at some arbitrary point, you
can claim anything about its low quality.  The full doc string is
this:

  Insert the character you type.
  Whichever character C you type to run this command is inserted.
  The numeric prefix argument N says how many times to repeat the insertion.
  Before insertion, ‘expand-abbrev’ is executed if the inserted character does
  not have word syntax and the previous character in the buffer does.
  After insertion, ‘internal-auto-fill’ is called if
  ‘auto-fill-function’ is non-nil and if the ‘auto-fill-chars’ table has
  a non-nil value for the inserted character.  At the end, it runs
  ‘post-self-insert-hook’.

Which does mention post-self-insert-hook.  (And the ELisp manual
expands on the possible uses of that hook.)

What kind of argument is it when you elide arbitrary parts of the
documentation, just to make your point?  In what book does that
qualify as a serious discussion?

> ..  This makes it unusable in a Lisp program.

That's debatable, and is not the issue when the doc string and the
definition of functionality are being discussed.

> For example, in
> c-electric-paren, which handles the user entering "(" or ")", the code
> needs to determine whether the "(" was entered at the end of a line.
> The current self-insert-command, which inserts arbitrary further
> characters, makes this difficult.

So we have two electric behaviors that could conflict.  That's not
anything new, and we have ways of handling these situations, as Stefan
pointed out, and as you can see in the source code.  What does this
have to do with the issue at hand?

> I am suggesting that self-insert-command should be made usable from Lisp
> again, as it once was, and have suggested a means for achieving this.

Your request is noted.  I find it hard to believe that we will take
that direction, since post-self-insert-hook is used in so many useful
features nowadays.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 13:29:02 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, jm <at> pub.pink,
 eg642616 <at> gmail.com
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 09:28:15 -0400
>> Thus electric-pair-mode doesn't violate any conventions.
> self-insert-command, called from Lisp, is broken.  There is no usable
> definition of its functionality.  So far, there is no competing analysis
> to mine as to how it's broken.  Stefan's "solution" is not to use
> self-insert-command.

Your code doesn't want to use `self-insert-command`, instead it wants to
do mimic `self-insert-command` but with some changes.
That's exactly what `post-self-insert-hook` is for.

> So it's looking like the ugly workarounds in c-electric-paren to use
> self-insert-command will have to remain.  I'm disappointed about this.

Not for lack of an alternative, tho.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 13:40:02 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 13:39:07 +0000
Hello, Eli.

On Fri, Jul 25, 2025 at 15:02:12 +0300, Eli Zaretskii wrote:
> > Date: Fri, 25 Jul 2025 11:42:37 +0000
> > Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
> >   jm <at> pub.pink, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

> > > > self-insert-command, called from Lisp, is broken.  There is no usable
> > > > definition of its functionality.

> > > What's wrong with its doc string as that definition?

> > It's inaccurate and misleading.

> > We have:

> >     Insert the character you type.
> >     Whichever character C you type to run this command is inserted.
> >     [Plus all the bits about the numeric prefix, abbreviations, etc.]

> > More accurate would be:

> >     Maybe insert the character you type (depending on
> >     post-self-insert-hook).
> >     Insert or delete further characters as specified by
> >     post-self-insert-hook.
> >     Leave point at the position determined by post-self-insert-hook or
> >     after the inserted character.

> Of course, if you truncate the doc string at some arbitrary point, you
> can claim anything about its low quality.

I abstracted the relevant bit.  I'm complaining not about the doc string,
which can't be made adequate, rather about the function, whose
functionality has become indeterminate due to the violation of the
non-convention which you deny doesn't exist.

> The full doc string is this:

>   Insert the character you type.
>   Whichever character C you type to run this command is inserted.
>   The numeric prefix argument N says how many times to repeat the insertion.
>   Before insertion, ‘expand-abbrev’ is executed if the inserted character does
>   not have word syntax and the previous character in the buffer does.
>   After insertion, ‘internal-auto-fill’ is called if
>   ‘auto-fill-function’ is non-nil and if the ‘auto-fill-chars’ table has
>   a non-nil value for the inserted character.  At the end, it runs
>   ‘post-self-insert-hook’.

> Which does mention post-self-insert-hook.  (And the ELisp manual
> expands on the possible uses of that hook.)

Yes.  But that doesn't make the function usable.  Before this mechanism
came into existence, one could depend on self-insert-command inserting
exactly one character and point being after the point of insertion.  Now
an arbitrary collection of characters is inserted and deleted, and point
ends up in an arbitrary position.  This makes self-insert-command
virtually unusable from Lisp.

> What kind of argument is it when you elide arbitrary parts of the
> documentation, just to make your point?  In what book does that
> qualify as a serious discussion?

As I said in my last paragraph, the bit I left out didn't really seem
relevant.  self-insert-command is just as unusable if one considers that
part of the doc string too.

> > ..  This makes it unusable in a Lisp program.

> That's debatable, ....

Then debate it with me, please.

> .... and is not the issue when the doc string and the definition of
> functionality are being discussed.

On the contrary, being able to use a function is the entire point of
documenting it.

> > For example, in c-electric-paren, which handles the user entering "("
> > or ")", the code needs to determine whether the "(" was entered at
> > the end of a line.  The current self-insert-command, which inserts
> > arbitrary further characters, makes this difficult.

> So we have two electric behaviors that could conflict.

That's a most superficial way of regarding the problem, and if one looks
no further, one will end up with a superficial workaround which fails to
solve the underlying problem.

> That's not anything new, and we have ways of handling these situations,
> as Stefan pointed out, and as you can see in the source code.

What Stefan suggested was no longer using self-insert-command.  That is
hardly practical in CC Mode.

> What does this have to do with the issue at hand?

I'm not sure what you see as the issue.  I see the issue as the
unusability of self-insert-command, and I've analysed the cause of this.

Forgive me for pointing out that this was another instance of a big
feature being introduced into Emacs without prior discussion
on emacs-devel, what I was complaining about last November.  I spotted
its flaw instantly on becoming aware of the new feature, but that was too
late actually to get anything done about it.

> > I am suggesting that self-insert-command should be made usable from Lisp
> > again, as it once was, and have suggested a means for achieving this.

> Your request is noted.  I find it hard to believe that we will take
> that direction, since post-self-insert-hook is used in so many useful
> features nowadays.

I can't say I'm all that surprised, sadly.

Note that my changes wouldn't remove any functionality.  They would
merely make self-insert-command work again predictably.

I've tried putting electric-pair-post-self-insert-function and its friend
onto post-command-hook instead of post-self-insert-hook.  It works, sort
of, but would naturaly need some debugging and testing.

Or we just leave the ugly workarounds in c-electric-paren and friends and
fix them whenever they break.  Or replace them with other ugly
workarounds of some nature, perhaps.

I'm not happy about the state of c-electric-paren.

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 14:23:01 GMT) Full text and rfc822 format available.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, jm <at> pub.pink,
 eg642616 <at> gmail.com
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 10:21:58 -0400
>> That's not anything new, and we have ways of handling these situations,
>> as Stefan pointed out, and as you can see in the source code.
> What Stefan suggested was no longer using self-insert-command.

I look at it as using `self-insert-command` *more*.

> That is hardly practical in CC Mode.

I don't see why not.  My best guess is that you find it inconvenient to
make the code work for Emacsen both with and without
`post-self-insert-hook`, but that seems easy enough to fix with
a (boundp 'post-self-insert-hook) or a version test.
[ Or even simpler by dropping support for Emacs<24, which recently
  turned 15, BTW. 🙂 ]

> I'm not happy about the state of c-electric-paren.

It should die and be replaced by the existing `electric-*-mode`s.


        Stefan





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 14:43:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 17:41:54 +0300
> Date: Fri, 25 Jul 2025 13:39:07 +0000
> Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
>   jm <at> pub.pink, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> > What does this have to do with the issue at hand?
> 
> I'm not sure what you see as the issue.

This is a bug report whose purpose is stated in the Subject and in the
original message posted to the discussion.  Could we please return to
that issue, and leave your gripes about post-self-insert-hook to
another discussion?

> I see the issue as the
> unusability of self-insert-command, and I've analysed the cause of this.

That's not the issue at hand.  The issue at hand is the question asked
in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79047#5

I'd like to hear your opinion about that suggestion wrt CC Mode.  If
you are against that, please just say so, and then we will not make
the suggested changes in CC Mode.  If you don't mind, or want to see
the proposed patch, or have some other response to that question,
specifically, please voice your opinions, and let's move on.

> Forgive me for pointing out that this was another instance of a big
> feature being introduced into Emacs without prior discussion
> on emacs-devel, what I was complaining about last November.  I spotted
> its flaw instantly on becoming aware of the new feature, but that was too
> late actually to get anything done about it.

Sorry, that's not relevant to this bug report.

> I'm not happy about the state of c-electric-paren.

I understand, but that is not what is being discussed here.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 16:12:03 GMT) Full text and rfc822 format available.

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

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 16:11:03 +0000
Hello, Eli.

On Fri, Jul 25, 2025 at 17:41:54 +0300, Eli Zaretskii wrote:
> > Date: Fri, 25 Jul 2025 13:39:07 +0000
> > Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
> >   jm <at> pub.pink, acm <at> muc.de
> > From: Alan Mackenzie <acm <at> muc.de>

[ .... ]

> The issue at hand is the question asked in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79047#5

OK.  I've already voiced some doubts about this proposed change.

Does Emacs really need Yet One More Way of entering a comment?  It will
need at least one more user option distinct from electric-pair-mode, for
example.  Elijah has responded to this point, stating he believes it
would be useful.

I said (yesterday) that I thought the commit

    commit 60fbeda771639ded68ffd0666df340c7a06cafcf
    Author: Elías Gabriel Pérez <eg642616 <at> gmail.com>
    Date:   Thu Apr 24 17:34:58 2025 -0600

        Support strings for electric pairs (bug#78053)

was unfinished and should be finished before implementing the proposed
change.

> I'd like to hear your opinion about that suggestion wrt CC Mode.  If
> you are against that, please just say so, and then we will not make
> the suggested changes in CC Mode.  If you don't mind, or want to see
> the proposed patch, or have some other response to that question,
> specifically, please voice your opinions, and let's move on.

I'm not really against the bug's proposal being in CC Mode.  Just it
will cause an extension of all the nastiness in CC Mode we were
discussing earlier on today.  I can live with that.

So if the feature as a whole gets implemented, I would certainly
introduce it into CC Mode, too.

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 25 Jul 2025 18:06:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, eg642616 <at> gmail.com, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Fri, 25 Jul 2025 21:04:53 +0300
> Date: Fri, 25 Jul 2025 16:11:03 +0000
> Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
>   jm <at> pub.pink, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
> 
> On Fri, Jul 25, 2025 at 17:41:54 +0300, Eli Zaretskii wrote:
> > > Date: Fri, 25 Jul 2025 13:39:07 +0000
> > > Cc: monnier <at> iro.umontreal.ca, eg642616 <at> gmail.com, 79047 <at> debbugs.gnu.org,
> > >   jm <at> pub.pink, acm <at> muc.de
> > > From: Alan Mackenzie <acm <at> muc.de>
> 
> [ .... ]
> 
> > The issue at hand is the question asked in
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79047#5
> 
> OK.  I've already voiced some doubts about this proposed change.

We are asking for your opinion, not for doubts.  If you object for
such a change in CC Mode, then we will not make such changes there.

> Does Emacs really need Yet One More Way of entering a comment?

I don't know.  Asking you and other mode maintainers was meant to
provide feedback to make the decision.

> > I'd like to hear your opinion about that suggestion wrt CC Mode.  If
> > you are against that, please just say so, and then we will not make
> > the suggested changes in CC Mode.  If you don't mind, or want to see
> > the proposed patch, or have some other response to that question,
> > specifically, please voice your opinions, and let's move on.
> 
> I'm not really against the bug's proposal being in CC Mode.  Just it
> will cause an extension of all the nastiness in CC Mode we were
> discussing earlier on today.  I can live with that.
> 
> So if the feature as a whole gets implemented, I would certainly
> introduce it into CC Mode, too.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Sat, 02 Aug 2025 14:00:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, jm <at> pub.pink, monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 02 Aug 2025 16:59:23 +0300
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 79047 <at> debbugs.gnu.org,  Eli Zaretskii <eliz <at> gnu.org>,  John Muhl
>  <jm <at> pub.pink>,  Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 22 Jul 2025 17:03:34 -0600
> 
> Alan Mackenzie <acm <at> muc.de> writes:
> 
> > Hello, Elijah.
> >
> > One important point.
> >
> > Are you sure about this?  In NEWS, there is the rather sloppily worded
> > entry:
> >
> >     ** Electric Pair mode can now pair multiple delimiters at once.
> >     You can now insert or wrap text with multiple sets of parentheses and
> >     other matching delimiters at once with Electric Pair mode, by providing
> >     a prefix argument when inserting one of the delimiters.
> >
> > It uses the sloppy American English ambiguity where "multiple" can mean
> > either "several", or "composed of several parts".  In correct British
> > English "multiple" has only the latter meaning.
> >
> > I think in this NEWS entry the meaning "several" was intended, and you
> > may have misread it.  I don't think electric-pair-mode has any facilities
> > for pairing a multiple delimiter; only for pairing several of the same
> > delimiter at once, e.g. (((....))).
> 
> That is the wrong NEWS entry of the feature.
> The real one is this:
> 
>   *** Electric Pair mode now supports multi-character paired delimiters.
>   'electric-pair-pairs' and 'electric-pair-text-pairs' now allow using
>   strings for multi-character paired delimiters.
> 
>   To use this, add a list to both electric pair user options: '("/*" . "*/")'.
> 
>   You can also specify to insert an extra space after the first string
>   pair: '("/*" " */" t)'.
> 
> > Please check if I am correct or mistaken on this point.  If I'm correct,
> > then the prerequisites for implementing this change are absent, and there
> > is nothing more to discuss.
> 
> I've tested the feature, it's possible to achieve it:
> 
>   (setq electric-pair-pairs `((,(regexp-quote "/*") " */" t)))
> 
>   /* | */
>        ^^ After inserting the * character.
>           (the extra whitespace is optionally included)

Can we please have a patch to install, which incorporates all the
discussions we had here?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Mon, 04 Aug 2025 20:05:01 GMT) Full text and rfc822 format available.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, jm <at> pub.pink, monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Mon, 04 Aug 2025 14:03:58 -0600
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

> Can we please have a patch to install, which incorporates all the
> discussions we had here?

Sorry for the delay.

Here is the patch:

[0001-Add-multi-character-pairs-to-lua-ts-mode-and-texinfo.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
-- 
- E.G via Gnus and Org.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Thu, 07 Aug 2025 13:18:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, jm <at> pub.pink, monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 07 Aug 2025 16:17:32 +0300
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 79047 <at> debbugs.gnu.org,  acm <at> muc.de,  jm <at> pub.pink,  monnier <at> iro.umontreal.ca
> Date: Mon, 04 Aug 2025 14:03:58 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Can we please have a patch to install, which incorporates all the
> > discussions we had here?
> 
> Sorry for the delay.
> 
> Here is the patch:

Thanks.  It LGTM, but why isn't the change in Texinfo called out in
NEWS, like you did with lua-ts-mode?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79047; Package emacs. (Fri, 08 Aug 2025 05:38:01 GMT) Full text and rfc822 format available.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79047 <at> debbugs.gnu.org, acm <at> muc.de, jm <at> pub.pink, monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Thu, 07 Aug 2025 23:37:35 -0600
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: 79047 <at> debbugs.gnu.org,  acm <at> muc.de,  jm <at> pub.pink,  monnier <at> iro.umontreal.ca
>> Date: Mon, 04 Aug 2025 14:03:58 -0600
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Can we please have a patch to install, which incorporates all the
>> > discussions we had here?
>> 
>> Sorry for the delay.
>> 
>> Here is the patch:
>
> Thanks.  It LGTM, but why isn't the change in Texinfo called out in
> NEWS, like you did with lua-ts-mode?

I'm not sure it needs to be in NEWS, it's a very small change.  In
lua-ts-mode I announced it because it uses a new option to enable the
feature.

However if it needs to be in NEWS, here is a patch which includes it:
[0001-Add-multi-character-pairs-to-lua-ts-mode-and-texinfo.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
-- 
- E.G via Gnus and Org.

Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 09 Aug 2025 10:46:02 GMT) Full text and rfc822 format available.

Notification sent to Elijah Gabe Pérez <eg642616 <at> gmail.com>:
bug acknowledged by developer. (Sat, 09 Aug 2025 10:46:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 79047-done <at> debbugs.gnu.org, acm <at> muc.de, jm <at> pub.pink,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#79047: Add some multi-character pairs to some major modes.
Date: Sat, 09 Aug 2025 13:44:56 +0300
> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 79047 <at> debbugs.gnu.org,  acm <at> muc.de,  jm <at> pub.pink,  monnier <at> iro.umontreal.ca
> Date: Thu, 07 Aug 2025 23:37:35 -0600
> 
> >> Here is the patch:
> >
> > Thanks.  It LGTM, but why isn't the change in Texinfo called out in
> > NEWS, like you did with lua-ts-mode?
> 
> I'm not sure it needs to be in NEWS, it's a very small change.  In
> lua-ts-mode I announced it because it uses a new option to enable the
> feature.
> 
> However if it needs to be in NEWS, here is a patch which includes it:

Thanks, installed on the master branch and closing the bug.  (Please
in the future make sure to mention the bug number in the commit log
messages.)




This bug report was last modified today.

Previous Next


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