From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: Fixing post-self-insert-hook.
Date: Sat, 18 Sep 2021 14:03:27 -0400 [thread overview]
Message-ID: <jwvfsu16bhp.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <YUYMKsynUT7mJyP+@ACM> (Alan Mackenzie's message of "Sat, 18 Sep 2021 15:56:26 +0000")
> 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
next prev parent reply other threads:[~2021-09-18 18:03 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
2021-09-18 15:56 ` Alan Mackenzie
2021-09-18 18:03 ` Stefan Monnier [this message]
[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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvfsu16bhp.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.