Fixing post-self-insert-hook.

[Alan Mackenzie]

Hello, Emacs.

For some while, there's been a problem with post-self-insert-hook.  Not
the hook itself, but what is sometimes done with it.

What is sometimes done with it is to effect buffer changes additional to
the prime change caused by self-insert-function.  This is the case, for
example, with electric-pair-post-self-insert-function.  Usually, when
self-insert-function is called from a key binding, this is harmless.  The
key gets inserted, then the auxiliary buffer changes take place.  Fine.

What isn't fine is when self-insert-function is called from Lisp, as it
is 293 times from our sources, including from cc-cmds.el.  The calling
Lisp function expects (usually) exactly one copy of the pressed key to be
inserted into the buffer.  With the pertinent post-self-insert-hook
functions in place, this certainty is lost.  There could be none, one,
two, or even many characters inserted.  This can wreck the functionality
of the Lisp function.

This is precisely what happened in quite a few c-electric-* functions,
and the uneasy workaround was to bind post-self-insert-hook to nil around
calls to self-insert-function, giving certainty back to the processing,
and try to compensate for this elsewhere.

This is clearly unsatisfactory.

#########################################################################

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.

-- 
Alan Mackenzie (Nuremberg, Germany).