[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: |
Thu, 01 Sep 2016 07:49:46 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
>>> 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).
So, on a-c-f revert the change, do what we are currently doing on b-c-f,
then reapply the change and run what we are currently running on a-c-f.
Yes, that does seem a possibility albeit a fairly hideous one. It's
really not something I'd want to be doing after every command.
I'll test out expanding the region with the code you suggested earlier.
(let ((diff (- (cdr lentic--b-c-pos) (+ start length))))
(cl-incf length diff)
(cl-incf end diff))
and see if this works.
Phil