Re: Fixing post-self-insert-hook.

[Stefan Monnier <monnier@iro.umontreal.ca>]

> They're defined.  The caller of self-insert-function can take account of
> them.  Also only things like SPACE or LFD trigger these functionalities.

abbrev expansion can take place for other keys than SPC and auto-fill
can happen for any char in `auto-fill-char`, so it's not limited to SPC
and LFD: it can happen virtually with any key, depending on the
user's config.

Indeed, in practice it tends to happen only for a few keys like SPC, but
if a code doesn't want `post-self-insert-hook` modifications, and it
presumes that auto-fill or abbrev expansion won't happen, then we're
back at the question about why does it call `self-insert-command` rather
than `insert`.

>> After all, if the code just wanted to insert a given char, it
>> should/would have used `insert`, which is both shorter and
>> more efficient.
> OK.  We're back at the point of speculating what all the
> self-insert-commands are there for.  `insert' isn't actually fewer
> characters to type, because one hast to extract the keypress from
> this-command-keys, but I take the point.

In my experience, there isn't a general solution to this problem (and
yes, I agree it's a problem; what I disagree with is the
characterization that it's specifically linked to
`post-self-insert-hook`).  We need to fix it on a case by case basis,
and I think it's OK to do that lazily by only fixing the problems when
we encounter them.

>> > The effect of self-insert-function called from Lisp is wholly
>> > dependent on what happens to be in post-s-i-h.  You might get no
>> > characters inserted, you might get 1 or 2, you might get many.
>> > You just can't know at programming time.
>
>> Indeed.  If they want/need to know, then why do they call
>> `self-insert-command` instead of `insert`?
>> Until we know that, we can't know what's the better fix.
>
> I suspect it's for commands which do something extra as well as
> self-insert-function.  The c-electric-... commands fall into this
> category.  Maybe the thinking is compatibility with self-i-c.

It's difficult to combine several extra behaviors in
`self-insert-command` in a modular way.  For that reason
`electric-indent-mode`, `electric-pair-mode`, and `electric-layout-mode`
know about each other to some extent (tho I strove to design them such
that they are independent).

For that same reason, `c-electric-*` needs to know about those others as
well :-(, tho it also has the option of just breaking them by using
plain `insert`.

>> It would introduce its own lot of regressions, of course.
> It might, I'm not convinced either way.

I can see a few "obvious" interactions with other post-command-hooks,
and based on the history of the subtle issues we've had with interactions
between `electric-*-mode`s I'm pretty sure it would take a few
iterations before getting something that works as well as what we have.

And of course, the effects that are currently undesired may still
be undesired when postponed to `post-command-hook`.

I think postponing to `post-command-hook` will just make the behavior
yet more complex and yet harder to control (e.g. you won't have the easy
option of let-binding `electric-*-mode` around the call to
`self-insert-command`).

> Right now, commands like c-electric-brace get by by binding
> post-self-insert-hook to nil (thus getting predictability) then
> explicitly calling electric-pair-post-self-insert-function a bit later.
> This isn't good, since e-p-p-s-i-function is really an internal function
> in elec-pair.el, without any guaranteed functionality.  I really need a
> defined external function in elec-pair.el which would do the same thing
> as e-p-p-s-i-function, but in addition return information about what
> it's just done.  I've asked João about such an interface over the last
> few years, now and then, but such has not yet been forthcoming.

Of course, IMO (and I believe João has the same position) the better
path forward is to drop that `c-electric-brace` code altogether and rely
on `electric-pair-mode` instead like all other modes do, so the need for
such extra API is definitely not very high in my list of priorities ;-)


        Stefan