Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change c7a6601 1/5: undo-size can count number of boundaries.

[phillip.lord@russet.org.uk (Phillip Lord)]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> and do it right before we add something to the undo-list (so the test of
>>> undo_list indeed tells us if this is the first new change pushed since
>>> the last boundary).  It should give us the same behavior but without the
>>> need for that variable.
>> Because, that triggers the hook only after a boundary.  With
>> "undo-buffer-undoably-changed", the hook is triggered after
>> undo-buffer-undoably-changed is set to nil which may or may not relate
>> to the addition of a boundary. And actually, currently it doesn't.
>
> So the question becomes: why doesn't it?


Okay. So, I'll recap, and then explain the logic that I am trying to
implement.

I've removed the behaviour from undo.c which calls undo-boundary in a
buffer whenever a change has happened in any other buffer because it
breaks my use case (and others using post-command-hook).

This removes a default which ensures that an undo-boundary were inserted
in long-running processes periodically, so avoiding the
"undo-outer-limit" situation which largely happens in buggy situations
(or when a user has done something really big).

So, the logic I am trying to implement (or think I have!) is:

- record all buffers which have had undo-able changes in them as we go

- every ten seconds check the size of the undo list, and iff it is
  bigger than undo-limit, and has less than 2 boundaries, add one at the
  start.

We need 2 boundaries because the undo-list compact always leaves upto
the first boundary.

In reality, I have made two optimisations which make life slightly more
complex.

- The timer actually runs 10 seconds only after the first undoable
  change in any buffer, since the last time we checked (i.e. it will run
  once in an idle emacs).

- I have not added a "undoable-change-hook" into lisp space because it
  will get called a lot. Rather, we have "first-undoable-change" which
  is called only if "undo-buffer-undoably-changed" is nil. The timer
  resets the buffer-local values of this to nil when it runs.

I've pushed some more changes and will test further tomorrow. It's
starting to behave as I expected now (my C was broken amoung other
things -- initializing local variables! What's that all about?).

I need to rename "undo-buffer-undoably-changed" to "-recently-changed" I
think.

Just to repeat everything that others have said, your patience and
kindness at dealing with dumb questions is rather humbling. Good luck to
you!

Phil