GNU bug report logs - #78042
31.0.50; Improper sequence of `before/after-change-functions` calls

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78042 <at> debbugs.gnu.org
Subject: bug#78042: 31.0.50; Improper sequence of `before/after-change-functions` calls
Date: Sat, 26 Apr 2025 21:41:04 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 78042 <at> debbugs.gnu.org
> Date: Sat, 26 Apr 2025 12:35:43 -0400
> 
> >> My request for comments/objection was not about whether it is worth
> >> fixing this bug (there is no doubt about that on my side: it affects at
> >> least Eglot and CC-mode), but whether the approach I used is acceptable
> >> or if you have a better alternative to propose.
> > The only alternative I can think of is to be able to handle nested
> > notifications, such as what happens in this case, as correct.  What
> > are the problems due to which we must have paired notifications
> > without nesting?
> 
> The problem is that it would change the semantics of
> `after/before-change-functions`.  E.g. code that needs to match the
> before with the after (e.g. CC-mode, Eglot, ...) would now need to be
> adjusted to keep a stack of "pending befores" and the C code would need
> to be reviewed to try and catch the few places where we currently run
> `after-change-functions` several times after running
> `before-change-functions` once.
> 
> IOW, we'd trade one set of corner-case breakage for another.

Except that making us prepared to handle nested notifications will
solve the problem for good.  IOW, fixing _that_ breakage has hope to
fix the problem completely, whereas fixing each case we find as we go
is just an endless rear-guard battle, and those can never be won.

Previous Next

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