Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change f59d1be: Move undo amalgamation to lisp.

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> But, after self-insert-command, actually, undo-undoably-changed-buffers
>> tells all the buffers that were modified since the last time we added an
>> auto-boundary. This will only be the same as the buffers which have
>> changed as a result of self-insert-command iff
>> undo-undoably-changed-buffers was nil before the command. It need not be
>> if buffers are undoably-changing as a result of a timer or a process for
>> instance.
>
> Indeed, with process filters and such there's a real probability that
> this isn't the case.  I think we can avoid this problem by making
> self-insert-command explicitly call undo-auto-boundaries at its end.
>
>> My other concern is that after a self-insert-command, I can guarantee
>> that the current-buffer hasn't changed much (normally by one char). But,
>> for example, with lentic a self-insert-command in one buffer can in
>> worse case result in all the characters in another buffer changing.
>
> In the worst case self-insert-command can also change the whole buffer.
> So the worst case is not nearly as important as the "reasonably expectable
> cases".

In the case of lentic, the worst case is, unfortunately, not uncommon.
Original it happened every key press, not it is rare enough not to cause
noticable lag, but it is enough to add a lot of stuff into
buffer-undo-list.


>> So amalgamating these changes might result in a big buffer-undo-list.
>
> I don't see how/why the size of buffer-undo-list would be affected.

Oh, sorry, I mean, "big" in the sense of "big chunks between boundaries"
which in turn means "not open for GC".

Regardless, I've made the changes, and pushed them.

I have noticed one problem case. The *scratch* buffer is created without
an undo-boundary after the ";;; This buffer is..." message. I think this
is a bootstrap problem and can be fixed by adding an undo-boundary call
to startup.el.

Other than this, are these changes ready to go?

Phil