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

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

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

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


        Stefan