Re: Fixing post-self-insert-hook.

[Stefan Monnier]

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

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

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

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

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

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

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


        Stefan