GNU bug report logs -
#78221
31.0.50; Improving *-change-functions notifications
Previous Next
Full log
Message #41 received at 78221 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 3 May 2025 17:03:49 +0000
> Cc: monnier <at> iro.umontreal.ca, 78221 <at> debbugs.gnu.org, joaotavora <at> gmail.com,
> yantar92 <at> posteo.net, acm <at> muc.de
> From: Alan Mackenzie <acm <at> muc.de>
>
> 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: monnier <at> iro.umontreal.ca, 78221 <at> debbugs.gnu.org, joaotavora <at> gmail.com,
> > > yantar92 <at> posteo.net
> > > From: Alan Mackenzie <acm <at> muc.de>
>
> > > > 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.
This bug report was last modified 32 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.