Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff575 2/2: Add a timer to ensure undo-boundaries in buffers.

[Stefan Monnier]

> Iff I do this, I would like to keep into elisp as much as possible.

Yes, that's generally what we try to do.

> I guess adding undo-pre-extend and undo-post-extend hooks should do the
> trick?

Not sure.  There's also the desire to keep costs down.  Adding undo
elements can happen *very often* in some cases (for some commands which
perform many changes), so the case of adding an undo record in a buffer
that already has had other undo records added since the last undo
boundary should be fast and I'd rather not run undo-pre-extend and
undo-post-extend hooks in that case.

So I think we should have a hook run whenever we push the first change
after a boundary.  That would let you (from Elisp) add the buffer to
some set of "modified" buffers, start timers, etc...

> Then anyone could switch this behaviour off. Then undo-outer-limit would
> become the final backstop.

Sounds good.

> Two issues. simple.el does not depend on timer, so I am not clear where
> to add this.

I think you can add it to simple.el for a first attempt (timer.el is
preloaded anyway).  Bootstrap is always slightly delicate, and it's
difficult to guess in advance what problems will show up and how to best
fix them.  So just assume the gods will be with you for now, and if they
don't show up, we'll see what needs to be done.

> And, I am aware that `buffer-undo-list' is just a list.  Anyone can
> change it anywhere in lisp, which would make the hooks difficult
> to enforce.

It's a problem in theory, indeed, but in practice it should be mostly
a non-issue.  IOW, I wouldn't worry about it.

> Just to clarify, you are suggesting a post-command add undo-boundary,
> rather than post-change (i.e. potentially many times per command)? I
> would need to think on this.

I'm not suggesting it: that's what the code does currently (look for
Fundo_boundary in src/keyboard.c).


        Stefan