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

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Aug 2016 12:01:22 -0400
> 
> > 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.
> 
> Actually, we do have some idea beforehand, as evidenced by the fact that
> we call b-c-f with valid data.  It's just that after the fact we have
> a more precise knowledge of what has actually been changed, so a-c-f can
> give more precise bounds.

I was under the impression that Phillip wanted the data be accurate,
not just valid.  Because if validity is the only requirement, we could
always call the before-change hook with the limits of the entire
buffer, and be done.  Clearly, that would not be very useful, to say
the least.

> We could also change the C code to perform this "extension" of the
> region passed to a-c-f so that the b-c-f region and the a-c-f region
> match, but that would make the region passed to a-c-f less precise, so
> those users of a-c-f which don't care about the pairing (the majority of
> the users) would be penalized (tho they'd still work correctly: just
> suboptimally) since there's no way for them to recover the
> tighter region.

Right.