[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fixing post-self-insert-hook.
From: |
Stefan Monnier |
Subject: |
Re: Fixing post-self-insert-hook. |
Date: |
Sat, 18 Sep 2021 10:15:02 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
>> 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
- Fixing post-self-insert-hook., Alan Mackenzie, 2021/09/17
- Re: Fixing post-self-insert-hook., Stefan Monnier, 2021/09/17
- Re: Fixing post-self-insert-hook.,
Stefan Monnier <=
- Re: Fixing post-self-insert-hook., Alan Mackenzie, 2021/09/18
- Re: Fixing post-self-insert-hook., Stefan Monnier, 2021/09/18
- Message not available
- Re: Fixing post-self-insert-hook., João Távora, 2021/09/18
- Re: Fixing post-self-insert-hook., Alan Mackenzie, 2021/09/19
- Re: Fixing post-self-insert-hook., João Távora, 2021/09/19
- Re: Fixing post-self-insert-hook., Stefan Monnier, 2021/09/19
- Re: Fixing post-self-insert-hook., Alan Mackenzie, 2021/09/19
- Re: Fixing post-self-insert-hook., Stefan Monnier, 2021/09/19
Re: Fixing post-self-insert-hook., João Távora, 2021/09/17