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

[phillip.lord@newcastle.ac.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Initially, because I wasn't sure that the a-c-f gave me all the
>> information that I needed. I thought it might do, but I was confused by
>> the third argument which is "length in bytes of the pre-change text". Is
>> "length in bytes" the same as "char position". I presumed note.
>
> Ha, nicely spotted, that's a bug in the docstring.  It passes (or
> should anyway) the length in characters.


Ah, okay. Can I fix it? This started of as a RFM thread, and this would
give me my first commit to Emacs core, even if it is just documentation.


>
>> The difficulty is that in some cases the conversion function uses the
>> contents of this buffer to work out the equivalent location in that
>> buffer.  When the b-c-f is called the two buffers are in sync, so this
>> conversion works.  But when the a-c-f is called, the two buffers are not
>> in sync because we haven't percolated the change yet.
>
> So, rather than the length of the previous text, you'd need to actually
> know the previous text?  


Potentially, yes.

For example, imagine I have a buffer like this

====
Here is some documentation
====

which maps to another buffer where the documentation is commented out

====
;; Here is some documentation
====

How to map between "equivalent" positions in the two? I do this by
counting backward from the end of the line in both buffers; this works
because the two lines differ only at the beginning.

With this technique, to calculate the equivalent position for the end of
a change, I need to know whether there are any new lines in changed region.

> Of course, you can use b-c-f to stash the "previous text", but indeed
> it won't necessarily always be exactly right, in the sense that the
> previous text stashed in b-c-f may not have the exact same boundaries,
> so you'll need to massage it a bit.
>
> The way I see it, you'll need to do something like
>
>    (defvar-local my-before-change-text nil)
>
>    (defun my-bcf (beg end)
>      (setq my-before-change-text
>            (if (null my-before-change-text)
>                (cons beg (buffer-substring beg end))
>              (let* ((oldbeg (car my-before-change-text))
>                     (oldtext (cdr my-before-change-text))
>                     (oldend (+ oldbeg (length oldtext)))
>                     (newbeg (min beg oldbeg))
>                     (newend (max end oldend)))
>                (cl-assert (equal oldtext (buffer-substring oldbeg oldend)))
>                (if (or (< newbeg oldbeg) (> newend oldend))
>                    (cons newbeg (buffer-substring newbeg newend))
>                  my-before-change-text)))))
>    (add-hook 'before-change-functions #'my-bcf)
>
> And then in after-change-functions, you'll need something like
>
>    (defun my-acf (beg end oldlen)
>      (let ((oldtext (substring (cdr my-before-change-text)
>                                (- beg (car my-before-change-text))
>                                (+ oldlen (- beg (car my-before-change-text))))))
>        (setq my-before-change-text nil)
>        ...))


That's possible, I guess, but it's still messy. The problem is I now
need to analyse both the buffer and the text which has been removed. I
also use the same function (to convert locations in the two buffers)
outside of changes (on the post-command-hook) where there is no changed
text. It adds considerable complexity the function. Still I will give it
a try.

For the moment, though, I have a workable solution (which is only make
incremental changes after white-listing commands); I have this working
with diff-mode now (nice example, incidentally, cause I found another,
unrelated, bug in my code).

Would you accept a commit to subst-char-in-region, though, which signals
the correct values on b-c-f? As I outlined in my previous email, it can
be done with no increase in computational complexity. Then I could
white-list fill-paragraph (at least when emacs 25 comes out!).

Phil