emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff57


From: Stefan Monnier
Subject: Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff575 2/2: Add a timer to ensure undo-boundaries in buffers.
Date: Tue, 01 Sep 2015 12:16:18 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> It's possible, but it then negates the utility of the
> `under-outer-limit' functionality.  The point is that after
> undo-outer-limit GC ditches the undo data anyway in the absence of any
> boundaries, but does so noisily.  But, if we run undo-ensure-boundary
> before compaction, the boundary will mean the undo-list is always
> GC'able with noise.

Hmm... making under-outer-limit (virtually) useless would be good,
actually (and your patch also goes in that direction), but indeed doing
it in the GC doesn't work quite the way I hoped.

Basically, the problem with too-long undo steps is that we can't safely
cut them into smaller pieces once they're created (it's not clear what
is a safe cut-point).
[ I mean "safe" in a soft sense: it's not like we risk a crash.  ]

So pushing a boundary is safer, if we can assume that the current state
of the undo-log corresponds to a safe cut-point.

And for some reason I thought that indeed the current state
of the undo-log during GC would usually correspond to a safe cut-point,
but actually this is not really true.

So, yes, I now think your solution is better.

So let's go with your approach, but we need to fix an efficiency problem
with it: with the code you have now, we always run a timer every 10
seconds which always loops through all buffers.
For power-saving reasons, doing that 24/7 on a mostly-idle machine can
be a bad idea, so we should try and make sure we don't wake up Emacs
when there's nothing to do.

Here's a plan:
- change the C code so that it keeps track of a set of "buffers that
  might need a boundary".
- when we push an undo element, we add the corresponding buffer to that
  set.  If the set was empty, call an Elisp function (that can start
  the timer).
- BTW shouldn't `undo-size' be called `undo-step-size' since it should
  only concern itself with the size of the current step.

The "set" could be represented as a list (and the timer can limit its
scan to the given set of buffers), or as a boolean.

BTW, we could also use the same "set" to change the "post command push
undo boundary" so it pushes boundaries on all modified buffers (so we
can through away the "push boundary upon buffer change" which causes
problems for your code).


        Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]