Re: Unbalanced change hooks (part 2)

[phillip.lord@russet.org.uk (Phillip Lord)]

Eli Zaretskii <eliz@gnu.org> writes:
> My interpretation of these two variables is that they are two hooks
> provided for different kinds of features, because hooking into both
> should not generally be required.  It should suffice for an
> application that wants to react to a change in a buffer to hook into
> after-change-functions only.


My apologies for jumping into the discussion so late, but I have been
travelling.

I make use of both b-c-f and a-c-f in my package called lentic. This
percolates changes in one buffer into another which is related but may
not be indentical to the first.

To enable this, I have to be able to convert between cognate positions
in the two buffers; that is the positions which are equivalent in the
two buffers. But I have to do this BEFORE the changes occur, because at
this point the two buffers are in a consistent state. This is not true
after the change has happened in one buffer and before it has been
percolated to the next.

Having b-c-f and a-c-f paired is not essential for this, but is (or
would be) greately helpful. It would also be good if the values passed
to b-c-f and a-c-f were consistent. Unfortunately this is not true
either (subst-char-in-region at least is guilty here, passing different
"end" positions in b-c-f and a-c-f).

I use the following logic to detect when b-c-f and a-c-f are "skewed" --
that is inconsistent with each other. "start" and "stop" are the
parameters of a-c-f and "length-before" is the value of the length
parameter of b-c-f called immediately before a-c-f.

 (or
                ;; previously this was not skewed if no region, but actually,
                ;; if there is no region we need to copy everything, we can
                ;; also do by declaring skew -- this is important for the
                ;; multi-lentic situation
                (not (or start stop length-before))
                ;; skews only occur in insertions which result in a positive
                ;; length-before. This also picks up no-insertion changes
                (and (< 0 length-before)
                     ;; = start stop means we have a deletion because
                     ;; there is no range after. Deletions seem to be
                     ;; safe.
                     (not (= start stop))))

This seems to work for me, but it's guess work. I do not understand
quite why it works, and there are (undoubtly) some cases where it does
not.

I realise that there may be practical difficulties in making the two
hooks consistent, although I think that this would be a laudable aim.
But failing this, it would be at least nice to know when the hooks are
not consistent; either in documentation, or better as a parameter, so I
could stop guessing.

The implications for lentic are significant; even though I can generally
avoid issues with the code above, the assumption that the whole buffer
is dirty generates a large amount of undo information. Fortuantely, it
happens only rarely, or this would simply prevent my approach from
working.

Which leads me to two conclusions:

1) being able to know when b-c-f and a-c-f are not paired or consistent
would be useful

2) decreasing the number of times these occurs would be useful, even if
it cannot be removed entirely.

Phil