Re: Fixing post-self-insert-hook.

[Alan Mackenzie]

Hello, Stefan.

On Sat, Sep 18, 2021 at 10:15:02 -0400, Stefan Monnier wrote:
> >> The question here is why those effects are undesirable while the other
> >> effects (like auto-fill or abbrev expansion) aren't.
> > It's because it's like making a buffer change in an after-change function
> > (that is an insertion or a deletion, not just a text-property change).

> I still don't see how the changes performed by auto-fill and abbrev
> expansions are different in this respect (both of them are internal to
> `self-insert-command` rather than being on `post-self-insert-hook`, for
> historical reasons).  They aren't just making text-property changes.

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

> > There's no way for the calling function to keep track of what's done.

> That's usually the point: the calling function doesn't want to insert
> a given char, but instead it wants to faithfully reproduce all the magic
> things that happen when you hit the corresponding key.

> 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.

> > That may be so, but the point is, an indeterminate part of these 111
> > calls is currently undefined.

> And I'm pretty sure that among those a significant fraction is already
> similarly broken/undefined even when `post-self-insert-hook` is nil
> because it would also break in the face of some auto-fill or
> abbrev expansions.

Maybe.

> > 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.

> > However, if the call to post-self-insert-hook were to be postponed to the
> > end of the function, all the 111 Lisp calls would be defined again, and
> > they would do the same as they did before post-s-i-h came along.

> [ I assume by "end of the function" you meant "after the command" such as
>   via `post-command-hook`.  ]

Sorry, yes, that's exactly what I meant.

> It would introduce its own lot of regressions, of course.

It might, I'm not convinced either way.

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.

> > I actually disagree with this (or I'm lacking some knowledge).  With M-:
> > post-self-insert-function<CR> you can see what's in the hook, and with a
> > little bit of delq, and so on, can change it for testing purposes.  I
> > don't think you can do any of that with an add-function type structure.
> > Please tell me if I'm wrong, here.  Thanks!

> Not wrong, no.  `M-:` indeed currently gives you the raw unreadable
> bytecode, but if you do `C-h o foo-function` or if you use
> `foo-function` in `M-x ielm`, you'll get something like:

>     ELISP> (defvar foo-function #'ignore)
>     foo-function
>     ELISP> (add-function :around foo-function #'fun1)
>     #f(advice-wrapper :around ignore fun1)
    
>     ELISP> foo-function
>     #f(advice-wrapper :around ignore fun1)
    
>     ELISP> 

> It's more verbose than the values we have on hooks, admittedly, but it's
> somewhat readable.  This "passably readable" form is displayed whenever
> the value is printed by `cl-print`.

Thanks.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).