Subject: Re: bug#78221: 31.0.50; Improving *-change-functions notifications

From: Eli Zaretskii <[email-masked]>
Date: Sat, 03 May 2025 22:22:56 +0300

> Date: Sat, 3 May 2025 17:03:49 +0000
> Cc: [email-masked], [email-masked], [email-masked],
>   [email-masked], [email-masked]
> From: Alan Mackenzie <[email-masked]>
> 
> Hello, Eli.
> 
> On Sat, May 03, 2025 at 18:52:11 +0300, Eli Zaretskii wrote:
> > > Date: Sat, 3 May 2025 15:15:24 +0000
> > > Cc: [email-masked], [email-masked], [email-masked],
> > >   [email-masked]
> > > From: Alan Mackenzie <[email-masked]>
> 
> > > > That's not how nested notifications happen in most, if not all, the
> > > > cases.  They happen because a function that calls the before-change at
> > > > the beginning and an after-change at the end calls, as part of its
> > > > processing, some other function, which itself modifies buffer text or
> > > > the text properties, and thus emits its own "nested" notifications.
> 
> > > OK.  Most Lisp code shouldn't be running the hook explicitly,
> > > though.
> 
> > No, but the C code does.  And it's very easy to imagine a situation
> > where one such primitive is invoked in the middle of another.  A case
> > in point is coding.c, where Stefan eliminated such a "nesting" just a
> > few hours ago (by a change that we have yet to see if it's safe).
> > With all the hooks we provide, such situations can emerge very easily.
> 
> The right tool to find these is cflow, combined with grep and awk (or
> python or perl or whatever) to search and filter cflow's output.  I've
> used these before.
> 
> As you say, checking fixes to these bugs are safe is less mechanical.

I'm not sure I even have a good idea regarding what are the safe fixes
for those cases.