From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org, "João Távora" <joaotavora@gmail.com>
Subject: Re: Fixing post-self-insert-hook.
Date: Sat, 18 Sep 2021 10:15:02 -0400 [thread overview]
Message-ID: <jwvzgsa7zsc.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <YUUAVqxOgXq0+MwA@ACM> (Alan Mackenzie's message of "Fri, 17 Sep 2021 20:53:42 +0000")
>> 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
next prev parent reply other threads:[~2021-09-18 14:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-17 19:37 Fixing post-self-insert-hook Alan Mackenzie
2021-09-17 20:04 ` Stefan Monnier
2021-09-17 20:53 ` Alan Mackenzie
2021-09-17 21:45 ` João Távora
2021-09-18 6:08 ` tomas
2021-09-18 8:44 ` João Távora
2021-09-18 14:15 ` Stefan Monnier [this message]
2021-09-18 15:56 ` Alan Mackenzie
2021-09-18 18:03 ` Stefan Monnier
[not found] ` <CALDnm52z_8HyqdC92nrMgzOMOOq48h2MQ4pjbROBOsdm5N_cJg@mail.gmail.com>
2021-09-18 22:55 ` João Távora
2021-09-19 12:14 ` Alan Mackenzie
2021-09-19 12:36 ` João Távora
2021-09-19 12:59 ` Stefan Monnier
2021-09-19 14:57 ` Alan Mackenzie
2021-09-19 20:20 ` Stefan Monnier
2021-09-17 20:15 ` João Távora
2021-09-17 20:35 ` Alan Mackenzie
2021-09-17 20:48 ` João Távora
2021-09-18 5:59 ` Eli Zaretskii
2021-09-18 9:41 ` Alan Mackenzie
2021-09-18 5:50 ` Eli Zaretskii
2021-09-18 9:57 ` Alan Mackenzie
2021-09-18 11:04 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvzgsa7zsc.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).