Re: Unbalanced change hooks (part 2)

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

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

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


        Stefan