Re: Unbalanced change hooks (part 2)

[Stefan Monnier]

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

The `end' position of b-c-f is correct (barring bugs), but is indeed
different from the `end' position of a-c-f (the difference is provided
by `length').

All I'm saying is that with the code I provided you could do (in a-c-f)
what Alan considered doing:

    (goto-char start)
    (let ((new-text (delete-and-extract-region start end)))
      (insert old-text)
      (let ((old-end (+ start (length old-text))))
        (run-my-b-c-f-code start old-end)
        (goto-char start)
        (delete-region start old-end)
        (insert new-text)))

Doing it this way would be really annoying, so it's better if your code
is able to work directly with `old-text' without having to insert it
into the buffer, but at least all the needed info is available.

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

The code I provided does just that (except it does it inside a-c-f but
the result is *exactly* the same as if subst-char-in-region were to do it
for you).


        Stefan