Re: Unbalanced change hooks (part 2) [Documentation fix still remaining]

[Eli Zaretskii]

> From: address@hidden (Phillip Lord)
> Date: Tue, 30 Aug 2016 14:30:13 +0100
> Cc: Alan Mackenzie <address@hidden>, Stefan Monnier <address@hidden>,
>       address@hidden
> 
> I think to really avoid the complexity for mode authors, b-c-f and a-c-f
> need to not only balance, but also to be consistent. At the moment, they
> are not that either -- they can signal different locations for a given
> change.

You are setting the bar impossibly high by expecting that.
Implementing what you want would need significant changes in how the
insdel functions are implemented and used.  In particular, some
complex changes will probably have to do things twice: once just to
figure out which changes are needed, the other time to actually do
that while calling the hooks in the way you want.  That's because in
some situations we discover the required changes as we go, and have no
idea in advance what we will find.

Read the code where these functions are called, and you will see what
I mean.

insert-file-contents as called by revert-buffer is a case in point: we
don't know which parts of the old text will need to be deleted until
we do the job by comparing the buffer with the file on disk; we delete
each portion as we discover it.

To keep this issue in its proper perspective, we have other hooks that
are similarly "inconsistent".  For example, window-scroll-functions
can be called by the display engine any number of times during a
single redisplay cycle, because the display engine many times plays
"catch and loose", trying something, then falling back to some backup
plan if plan A failed; but by the time it understands it needs to give
up on plane A, it already have called the hooks.

So I submit that this "inconsistency" is actually an inherent trait of
the Emacs hooks, at least some of them, and at this point the only way
to avoid that is completely rewrite the corresponding part(s) of the
internals.