unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "João Távora" <joaotavora@gmail.com>, emacs-devel@gnu.org
Subject: Re: Fixing post-self-insert-hook.
Date: Fri, 17 Sep 2021 20:53:42 +0000	[thread overview]
Message-ID: <YUUAVqxOgXq0+MwA@ACM> (raw)
In-Reply-To: <jwvtuijdln2.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Fri, Sep 17, 2021 at 16:04:58 -0400, Stefan Monnier wrote:
> > What is sometimes done with it is to effect buffer changes additional
> > to the prime change caused by self-insert-function.

> FWIW, I think the above "sometimes" really means "always" or "almost
> always" ;-)
> [ That was the primary motivation for the addition of this hook.  ]

> > What isn't fine is when self-insert-function is called from Lisp, as it
> > is 293 times from our sources, including from cc-cmds.el.

Actually, it was just 111, not 293.  Sorry.

> 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).
There's no way for the calling function to keep track of what's done.
This was the cause of bug #33794 in January 2019.

> I suspect that those 293 uses fall into roughly 3 different camps:

> - Those that really do want the full `self-insert-command` effects.
> - Those that call `self-insert-command` mostly because the author didn't
>   know better and they should really call `insert` instead.
> - The rest that wants more than `insert` but less than
>   `self-insert-command`.

> The last group might indeed deserve a new function.

That may be so, but the point is, an indeterminate part of these 111
calls is currently undefined.  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.

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.

>         Stefan


> PS: I do have one regret regarding `post-self-insert-hook`: I should
>     have defined a `self-insert-function` variable instead.  This is
>     because some of the `post-self-insert-hook` functions would be
>     cleaner if they could be turned into (add-function :around
>     self-insert-function ...).
>     Sadly, `add-function` didn't exist back then :-(

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!

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2021-09-17 20:53 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 [this message]
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
     [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=YUUAVqxOgXq0+MwA@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /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).