[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unbalanced change hooks (part 2)
From: |
Phillip Lord |
Subject: |
Re: Unbalanced change hooks (part 2) |
Date: |
Fri, 19 Aug 2016 15:51:15 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Eli Zaretskii <address@hidden> 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
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], (continued)
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Eli Zaretskii, 2016/08/19
- Re: Unbalanced change hooks (part 2) [Documentation fix still remaining], Stefan Monnier, 2016/08/19
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/02
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/02
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/07
- Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/08
- Re: Unbalanced change hooks (part 2), Stefan Monnier, 2016/08/08
- Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/08
Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/09
Re: Unbalanced change hooks (part 2),
Phillip Lord <=
Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/30