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

Previous Next

Full log

View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 78221 <at> debbugs.gnu.org, yantar92 <at> posteo.net, acm <at> muc.de, monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com
Subject: bug#78221: 31.0.50; Improving *-change-functions notifications
Date: Sat, 3 May 2025 17:03:49 +0000

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.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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