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

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> Set against this, of course, is that it also becomes harder to change
>> from lisp. Does the
>
>>   call2 (Qmy_function,arg1,arg2)
>
>> work like a normal lisp call? I mean, can I redefine my-function, and
>> will it run the new definition? Is it still open to advice?
>
> Yes.  Qmy_function is just the symbol, so the C code will call whichever
> function is bound to this symbol, like a call from Lisp would do.

Okay, no worries.


>>> The current logic in remove_excessive_undo_boundaries is far from
>>> perfect, but unless you have a really good idea how to do it
>>> differently, I recommend you just try to reproduce it in Elisp.
>> As I said, the difficulty comes about from trying to work out whether
>> the last undo-boundary is an "automatic" one (i.e. added by the C layer
>> and the command loop) or a "manual" one (i.e. added by a call to
>> undo-boundary).
>
> You can solve it in the same way we do it no: save the auto-added boundary
> in a variable (last_undo_boundary) when you add it, so you can
> afterwards use an `eq' test to figure out if this boundary was
> added automatically.
>
> Since you're moving the "auto-adding" to Lisp, last_undo_boundary will
> naturally move to Lisp as well.
>
>> What I didn't like about this logic is that it only works for a single
>> buffer; it assumes that there is only one last_undo_boundary.
>
> No: last_undo_boundary can be buffer-local.  You can also make it
> contain more info (e.g. add for example which was the command that
> created the corresponding change, or which other buffers received
> a boundary at the same, ...).

Yes, that's true, once it's in lisp.

Phil