[Top][All Lists]

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]