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

[Stefan Monnier]

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

More precise (i.e. tighter bounds) is better, but valid is indispensable
(I used "valid" to mean that every change is covered by the bounds, even
though those bounds may be too lose.  I consider "invalid" to be a plain
bug, as in insert-file-contents, for example).

In Phillip's case he'd prefer to have suboptimal data than mispaired
data since in the mispaired case he just falls back to "redo
everything", which is equivalent to calling b/a-c-f with
point-min/point-max.  So the message you quoted just pointed out that as
long as b/a-c-f are paired (actually, you just need the guarantee that
to each b-c-f corresponds at most one a-c-f), you can manually make
those pairs "proper" (i.e. with identical bounds) inside your own a-c-f.

So I'm pretty sure he's more concerned about "proper pairing" than about
"utmost tightness of the bounds".

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

Indeed.  But in the case of subst-chars-in-region, what we pass to b-c-f
is suboptimal but better than point-min/max, so there's a useful middle
point between the difficult "tightest bound" and the degenerate "just
pass point-min/max".


        Stefan