Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change 0f3c1db: Changed semantics of first-undoable-change-hook.

[Stefan Monnier]

> Hmmm. So, I had a look at this, and it's actually more complex than it
> appears. The problem, ironically, is the bundling in
> Fself_insert_command. My code (first-undoable-change-hook) only runs on
> the first change after a boundary. And this doesn't mean "after a
> boundary has been added" but "when there is a boundary on the head of
> the list immediately after a change has happened". But,
> self-insert-command removes this boundary. So my hook doesn't run. At

Clearly, remove_excessive_undo_boundaries (and related state like
last-undo-boundary) will need to be fully rewritten, and it will
inevitably be very dependent on the rest of *your* code.  I think we can
move it to Elisp and make it part of your code (it can, and even has to,
be deeply dependent on the rest of your code).  So it can run the hook
by hand, if needed.


        Stefan