Re: [Request for Mentor] subst-char-in-region

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> ooo
>> bbb
>
>> Changing ooo to xxx reports the following from Emacs
>
>> before(1,8)
>> after(1,4,3)
>
> That looks correct to me.

Why? The doc says "the positions of the beginning and end of the old
text to be changed" for before-change-function. But the text from 4 to 8
is not changed. As indeed the after-change-functions value says.

If the doc means "the position of the beginning and end of the old text
which is potentially open for change but may not actually change", then
that would have been a different issue.

Given that the change in this case is a substution why is it not:

before(1,4)
after (1,4,3)

This could be calculated, of course, by subst-char-in-region, although
it would potentially require scanning the region twice (once to find
start and stop, once to actually make changes).


>> origin/fix/subst-char-in-region
>> (hopefully adding a new branch is okay for this, obviously it can be
>> deleted later). After adding this fix I get...
>
> Please use "scratch/<foo>" rather than "fix/<foo>".

Will do.

>
>> before(1,8)
>> after(1,8,8)
>
> This wouldn't be wrong, but would be less precise.

Yep, I agree.

>
>> Assuming others agree with me that this behaviour is wrong, I would like
>> to fix the problem, but would welcome some help and code review.
>
> Assuming a close&direct correct correspondence between
> before-change-functions and after-change-functions is just a bad idea.
> Does you code *really* need that?

At the moment, yes, it does. I am keeping two buffers in sync by
transfering changes between them. It does this by removing the text in
"that buffer" between the before change values and replacing it with the
text in "this buffer" (it's slightly more complex than this, but that's
the basic idea).

In general, I have found that this works. For instance, replacing
subst-char-in-region with a more traditional search and replace
operation would work fine.

Whether it could be done in another way, not assuming that this
correspondence, I just do not know. At the moment, I do not see an
obvious way. Even if I did see an obvious way, I might be wrong. I've
already found quite a few edge cases which I didn't think about when I
started.

Phil