Re: Unbalanced change hooks (part 2)

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Tue, Aug 02, 2016 at 10:25:45PM +0300, Eli Zaretskii wrote:
> > Date: Tue, 2 Aug 2016 19:00:24 +0000
> > Cc: rms@gnu.org, ofv@wanadoo.es, rcopley@gmail.com, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > I thought we'd already agreed that no rational design would omit the
> > > > before-change-hooks call from an arbitrary subset of changes.

> > > No, I don't think there was such an agreement.  The set of changes for
> > > which before-change-functions are not called is not arbitrary.

> > Would you please characterize these circumstances in a way useful for
> > people considering the use of before-change-functions.  If you like, I
> > can then modify Elisp's "Change Hooks" with that information.

> Let's leave this for later, and focus on solving the immediate problem
> at hand.

You say the set of changes for which b-c-f isn't called isn't arbitrary.
That means it follows some sort of scheme.  Could a major mode, in an
after-change function use this scheme to determine whether
before-change-functions was called, for some particular change?  (This
won't be needed if my other idea (below) is workable.)

> > > If such an original design existed in the distant past, it was long
> > > ago (as in 20 years or more) replaced with what we basically see
> > > today, where every change always triggers a call to
> > > after-change-functions, but only some (the majority, but not all)
> > > trigger the call to before-change-functions.

> > >From the point of view of design, what is the benefit in not calling
> > b-c-f for that subset of circumstances?

> I'm not yet 100% sure, but I'm getting there.  In any case, the logic
> is very clear, although its rationale I only half-understand for now.

OK.

> > > The ELisp manual doesn't promise that these hooks will be called in
> > > balanced pairs.

> > It does.  before-change-functions is described as:

> >     .... a list of functions to call before any buffer modification.

> > after-change-functions is likewise described as:

> >     .... a list of functions to call after any buffer modification.

> > .  It may not explicitly say they are paired, but it says each hook is
> > called after every modification.  This naturally pairs them up.

> Like I said, sticking to such a strict interpretation would cause our
> code to be unnecessarily much too complex.  The modification hooks are
> supposed to tell you that changes are about to be, or have been, made
> in a region, but that doesn't necessarily mean you will have a single
> call of before- and after- hook for each of the partial changes.

OK, things are as they are.

I currently believe that most changes trigger before-change-functions but
EVERY CHANGE triggers after-change-functions.  Can you confirm that this
is the case?  If it isn't, could we fix Emacs so that it is?

If it is indeed the case, then a solution to the problem would be to
check that before- and after-c-f are called alternately.  Any time
after-c-f is called twice in a row, we could reverse the change just made
(using the undo list), invoke before-c-f, redo the change, then let
after-c-f continue to completion.  If necessary, we can temporarily
enable undo in a pre-command-hook function.  Given how rarely b-c-f isn't
called, this would have a negligible effect on performance and store
usage.

This would be a better solution than reversing and redoing every change.
It will also work for older Emacsen, and will be relatively easy to
implement.  It will be much easier to implement than a solution which
doesn't use before-change-functions at all.

What do you think about this?

-- 
Alan Mackenzie (Nuremberg, Germany).