GNU bug report logs - #78221
31.0.50; Improving *-change-functions notifications

Previous Next

Full log

Message #8 received at 78221 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>,
 João Távora <joaotavora <at> gmail.com>,
 Ihor Radchenko <yantar92 <at> posteo.net>, acm <at> muc.de
Cc: 78221 <at> debbugs.gnu.org
Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications
Date: Sat, 03 May 2025 09:54:33 +0300

> Cc: monnier <at> iro.umontreal.ca, Alan Mackenzie <acm <at> muc.de>
> Date: Fri, 02 May 2025 17:48:11 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> - Allow *-change-functions notifications to be nested.
>   E.g. allow a C function to call
> 
>       BEFORE 10 100
>         BEFORE 20 30
>         AFTER 20 25 10
>       AFTER 10 90 90
>       AFTER 10 60 80
> 
>   or something like that.  This would require some way for the C code to
>   indicate which BEGIN corresponds to which AFTER.  This could happen
>   for example by adding a "change-ID" to every notification, so we'd
>   get:
>   
>       BEFORE nnn 10 100
>         BEFORE mmm 20 30
>         AFTER mmm 20 25 10
>       AFTER nnn 10 90 90
>       AFTER nnn 10 60 80
> 
>   I don't know how we could do that in a backward compatible way, and
>   I can't think of any `*-change-functions` which would benefit from
>   this nesting (all the ones I can think of would either ignore the
>   extra info or use the change-ID to distinguish inner notifications
>   from outer ones and then ignore the inner ones).
> 
> - Maybe the last point can be turned into an internal change with no
>   ELisp-side changes: use an approach like the one above but filter out
>   the inner changes directly in the C code.  This would provide
>   to ELisp the same behavior that was brought by the fix to bug#78042,
>   but without resorting to the "hammer" of `inhibit-modification-hooks`
>   which risks silencing legitimate notifications.

On the "nested notifications" part of this, I'd like to hear specific
problems with them.  (I've added to the discussion people who might
have real-life examples of the problems.)  Specifically, I'm not sure
I have a good understanding of why they are a problem in the first
place.  Is it only because of the difficulty to pair BEFORE and AFTER
notifications? or is there something else?

Due to the Emacs's highly-recursive workings and the various hooks we
have, which are ever-expanding, there's a virtually infinite number of
situations where some code, called while a buffer-change operation is
under way, itself calls a buffer-changing primitive, thus generating
nested notifications.  Finding and fixing all of theses situations one
by one will take us infinite time, so I would like to consider more
practical alternatives.  And for that, IMO we need a very good
understanding of the problems they cause.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.