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

[Stefan Monnier]

>> I think this code should be called from self-insert-command rather than
>> from pre-command-hook.
> On a hook?  Or do I just directly call a function defined in lisp form C?

Yes, you can just call a Lisp function directly from C.  Typically, you
do it as follows:

   ...
      call2 (Qmy_function, arg1, arg2);
   ...
   foo_syms ()
   {
     ...
     DEFSYM (Qmy_function, "my-function");
     ...
   }

Since these functions are somewhat internal, I like to call them with
a leading "internal-" prefix, but that's my own preference rather than
a real convention we follow.

> Does the same argument apply to the post-command-hook and
> after-change-functions also?

For the after-change-functions: yes, very much so.

For the post-command-hook, I also think we could/should call the
function directly rather than go through post-command-hook, but there
are arguments in favor of either choice.

At least, calling the function directly is safer in the sense that it
is closer to the pre-existing code.

>> And it should also be called from delete-char.
> Yes, next on my list.

Ah, fine, then.

>> We don't actually know that (cdr last-before-nil) and (car
>> last-before-nil) are numbers.  The previous self-insert-command might
>> have performed all kinds of buffer modifications (via abbrev-expansion,
>> post-self-insert-hook, ...).
> Hmmm. That's unfortunate -- I was trying to avoid "global" state and
> just user buffer state; the undo-list seemed like a sensible place to
> get this knowledge from.

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.


        Stefan