[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unbalanced change hooks (part 2)
From: |
Stefan Monnier |
Subject: |
Re: Unbalanced change hooks (part 2) |
Date: |
Wed, 31 Aug 2016 08:24:58 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
>> 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
- Re: Unbalanced change hooks (part 2), (continued)
Re: Unbalanced change hooks (part 2), Alan Mackenzie, 2016/08/09
Re: Unbalanced change hooks (part 2), Phillip Lord, 2016/08/19
Re: Unbalanced change hooks (part 2), Eli Zaretskii, 2016/08/30