Re: Unbalanced change hooks (part 2)

[Eli Zaretskii]

> Date: Sun, 7 Aug 2016 21:16:27 +0000
> Cc: address@hidden, address@hidden, address@hidden, address@hidden
> From: Alan Mackenzie <address@hidden>
> 
> 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?

Not easily, not without some bookkeeping.

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

Yes.

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

I'm extremely uneasy about using undo for such purposes.  You have
already discovered one reason why.  In general, applications are free
to manipulate the undo records as they see fit, so you cannot expect
that to work reliably.