Re: track-changes and undo

[Joost Kremers <joostkremers@fastmail.fm>]

On Mon, Apr 22 2024, Stefan Monnier wrote:
> In the general case it's tricky to postpone the buffer change to a safer
> time, indeed.  In practice, tho, you should be able to distinguish "undo
> commands" from all other commands (basically depending on whether they
> do all their modifications with `undo-in-progress` or not) and then
> ignore only the changes of undo commands: the result should be
> good enough.
>
> IOW something like:
[code snipped]

Thanks, I'll see if I can make it work.

>>> One other thing that you might have trouble to reproduce with
>>> `track-changes` is the following test:
>>>
>>>     (and (= beg (point-min)) (= end (point-max)))
>>>
>>> that you have in `cm-before-change`.  I'm not completely sure what this
>>> is for, tho.  Is it for `revert-buffer`?
>>
>> I honestly don't remember... Based on the comment, it looks like
>> `switch-to-buffer` triggers `before-change-functions`, but a) that doesn't make
>> much sense; and b) the code seems to work just fine without that line. (I even
>> fired up a Vagrant box with an old Ubuntu release with Emacs 24, which would be
>> the most recent version when I wrote that code).
>
> Have you tried `M-x revert-buffer RET` (assuming the file and the
> buffer aren't equal)?

I did, but that appears to resets `before-change-functions` (and presumably
`after-change-functions`). After `revert-buffer`, the function that
cm-follow-mode adds to `before-change-functions` is gone, and `cm-mode` itself
is disabled. So I doubt that was the reason for adding that line. (Also, I don't
think I would have written "buffer switches" in the comment if I actually meant
"reverting a buffer". But then again, one's past self can be quite
unpredictable...)

-- 
Joost Kremers
Life has its moments