Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change c7a6601 1/5: undo-size can count number of boundaries.

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>>> But I get the impression that you didn't pay attention to another part
>>> of the logic that we need: the part that pushes a boundary at the end of
>>> a command.  Currently this is done in the C code and is applied only to
>>> the current buffer, but we should change this so it is applied to all
>>> buffers that were modified during the last command.
>> Hmmm, indeed, no I have not done that.  I can add this.
>
> To me, this is the most important part that relates to your original problem.
>
>> Does this not obviate the need for the timer.
>
> Not more than the current "push boundary when modifying another buffer".
>
>> A long running process buffer in an otherwise idle Emacs would be
>> a counter example, perhaps?
>
> That's right.
>
>> But it's easy to make the change. My thought was simply to leave the
>> undo-list as untouched as much as possible.
>
> Since it would only apply to changes made outside of commands,
> i.e. changes from process filters and timers, I don't think "leave the
> undo-list as untouched as much as possible" is desirable.  The fact that
> we currently never push a boundary (except when some other buffer
> happens to be modified) is just an accident.
>
>>> and would remove the need for undo-buffer-undoably-changed.
>> Unfortunately not!
>
> I meant in the C code.  The C code would only need to trigger the Elisp
> code when a change is made in a buffer which was previously "at an undo
> boundary".  Of course, the Elisp code will then want to remember those
> buffers "in need of a boundary" somehow (probably via a list like
> undo-undoably-change-buffers).


Okay this is, I believe, done now. It's a good deal simpler than it was,
which has to be a positive thing. I am still not entirely convinced -- I
think that the "default" undo-boundary behaviour should be to do as
little as possible, but the logic is implemented in lisp now, so it can
be over-ridden more straight-forwardly if needed. It would also be
possible to add a buffer-local variable `undo-no-auto-boundary' to
switch this behaviour off, as opposed to changing global state, but
adding that seems like overkill at the moment.

I've put some ad-hoc logging in; the code runs post-command and on a
timer and mostly silently, so it's hard to test it in actual use in any
other way. Obviously, I plan to remove that afterwards.

Comments welcome.

Phil