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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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".

> 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.


        Stefan