Re: Unbalanced change hooks (part 2)

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>>> But it can admittedly be cumbersome since the old-text is now in a string
>>> rather than being inside the buffer.
>> Because, I am not using the before and after positions just to recognise
>> the string that has changed.
>
> I was not suggesting to use those position to recognize the string:
> I was suggesting to use the suggested code to get the old-string so that
> you can then do what you need on the "before change" state.
>
>> I am have to calculate the equivalent positions in the other "lentic"
>> buffer; and this can only be done before the change, since the two
>> buffers are them in a consistent state.

Oh dear, my English seems to be terrible in this paragraph.

>
> The idea is that my suggested code gives you the needed info.
> More specifically, the other buffer is (well, should be) in a state
> consistent with "the current buffer where start..end is replaced (back)
> with `old-text'".

I think it does not, I am afraid, because the "end" position of b-c-f is
not reliably correct.

Consider this buffer:

One
Two

which is converted into this buffer

;; One
;; Two

To calulate that the "T" are cognate locations, I count the number of
lines, and then count backward from the end of the line. This works, so
long as the buffers are also cognate.

Now, say we have a deletion in buffer one starting at pos 3 ("e") to
pos 5 ("T"). Pos 3 is fine -- it's equivalent to pos 6 in the commented
buffer. But pos 5 is difficult. I have to calculate it's cognate
position before the deletion, since the number of lines change.

Which is what I do. All of this breaks if the end location on b-c-f is
wrong wrt to a-c-f. Counting the number of lines does not work on a-c-f
because the uncommented buffer has already changed.


> So that should give you the info needed to update things without doing
> a "complete flush".  As mentioned, it may be inconvenient to use it
> (depending on details of how the rest of the code is implemented) since
> the old-text is now in a string rather than being right there in
> the buffer.
>
>>> Note that in the subst-char-in-region you could "make it pairup"
>>> yourself by hand: if you have (< (+ start length) (cdr lentic--b-c-pos)),
>>> then you can just
>>> 
>>>     (let ((diff (- (cdr lentic--b-c-pos) (+ start length))))
>>>     (cl-incf length diff)
>>>     (cl-incf end diff))
>>> 
>>> such that (eq (+ start length) (cdr lentic--b-c-pos)).
>> So, this works because subst-char-in-region is guaranteed not to change
>> the size of the region right?
>
> No.  It works because a-c-f's arguments say "nothing was changed before
> START and after END", so it's always safe (conservative) to move START
> towards BOB or move END towards EOB (of course, when updating END you
> also need to update LENGTH correspondingly).


Ah, yes. But, unfortunately, I cannot calculate the location of the END
position in the cognate buffer. If subst-char-in-region did just what
you are suggesting I do (i.e. signally the maximal extent on a-c-f, as
it does on b-c-f), then there would be no problem.

I would love to change subst-char-in-region to achieve this. Making
a-c-f signal the maximal extent is the trivial change; the alternative
of having b-c-f know the real extent of the change is harder, but also
could be done.

Phil