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

From: Alan Mackenzie <[email-masked]>
Date: Fri, 9 May 2025 16:15:12 +0000

Hello, Eli.

On Sat, May 03, 2025 at 14:46:45 +0000, Alan Mackenzie wrote:

[ .... ]

> > 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.

> As I proposed in my reply to Stefan M., I don't think finding most/all of
> these situations need be too difficult.  insdel.c could be temporarily
> instrumented to signal an error on detecting an illegitimate buffer
> change.  The difficulty here might be false positives, when a program
> intends to make buffer changes from inside a change hook function.  I
> don't think these are common, though.

I no longer think we've got a systematic way of detecting all these
errors.  But...

I instrumented insdel.c in this way on a slightly outdated code base.
(In particular, signal_before_change and signal_after_change were
modified to detect nested calls to *-change-functions.)  I put Stefan's
recent amendment to editfns-tests.el into the mix, too.  Then I ran the
test suite.

The instrumentation detected _only_ the error highlighted by that change
to editfns-tests.el, no others.  It seems that nested calls of
*-change-functions are rare indeed.  Again, I think that the
complications of handling the nested calls would not be justified by the
small number, possibly zero, of such bugs still in the code.

-- 
Alan Mackenzie (Nuremberg, Germany).