emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing post-self-insert-hook.


From: Alan Mackenzie
Subject: Re: Fixing post-self-insert-hook.
Date: Sat, 18 Sep 2021 09:57:19 +0000

Hello, Eli.

On Sat, Sep 18, 2021 at 08:50:26 +0300, Eli Zaretskii wrote:
> > Date: Fri, 17 Sep 2021 19:37:27 +0000
> > From: Alan Mackenzie <acm@muc.de>
> > Cc: João Távora <joaotavora@gmail.com>

> > Given that it is now (at least politically) impossible to ban buffer
> > changing post-self-insert-hook functions, I propose to change the time at
> > which the hook gets called.

> > Instead of getting called straight after the self-insert-command, it
> > should be called at the end of the command which called
> > self-insert-command.  Just before post-command-hook, perhaps.  Yes there
> > are details to be worked out.

> > This will make no difference to the usual self-insert-command call.  It
> > will, however, restore the certainty of processing to Lisp code such as
> > c-electric-brace without having to resort to ugly workarounds.

> If CC Mode has problem with these hooks, it could bind them to nil
> around the call to self-insert-command, couldn't it?

That has indeed been done since early 2019.  It's not nice.  It involves
c-electric-brace knowing that one of the entries in post-self-insert-hook
is electric-pair-post-self-insert-function, and calling it explicitly.
It couples the electric-... minor modes with CC Mode, and blocks out any
other functionality on the hook from CC Mode.

> That'd be much better than making any globally-visible change in
> behavior, for which we cannot possibly know the unintended
> consequences.

The mechanism is currently broken.  Do we stick with this known breakage
for fear of an unknown, not particularly likely one, or do we fix it?

> In any case, please let's not make this change before the emacs-28
> branch is cut, as it can potentially disrupt many places.

Yes.  But surely we have enough time before Emacs 29 for any problems it
might cause to come to light.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]