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

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:
>> 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.

I want it to be as accurate as possible given the constraint of
validity. If it is invalid this breaks my use case (except that I detect
this and have an unoptimized fall back plan). If it is inaccurate (in
the sense of wider than necessary), this makes my code potentially less
efficient.

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

The sad thing is that, certainly for subst-char-in-region, both of these
pieces of information are available to the code that calls a-c-f. But I
can see no clean way of signalling this information: adding the data to
a-c-f would change it's interface, and storing it in global state is
just ugly.


Phil