From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: phillip.lord@russet.org.uk (Phillip Lord)
Cc: emacs-devel@gnu.org
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 [thread overview]
Message-ID: <jwvio7uqgou.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <87d1y272f9.fsf@russet.org.uk> (Phillip Lord's message of "Tue, 01 Sep 2015 13:24:26 +0100")
> 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
next prev parent reply other threads:[~2015-09-01 16:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20150821093606.11577.60349@vcs.savannah.gnu.org>
[not found] ` <E1ZSik4-000326-4S@vcs.savannah.gnu.org>
2015-08-30 3:30 ` [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change e5ff575 2/2: Add a timer to ensure undo-boundaries in buffers Stefan Monnier
2015-09-01 12:24 ` Phillip Lord
2015-09-01 16:16 ` Stefan Monnier [this message]
2015-09-01 17:19 ` Phillip Lord
2015-09-06 23:03 ` Stefan Monnier
2015-09-14 14:41 ` RFM: How to make a buffer-local var in C layer Phillip Lord
2015-09-15 1:48 ` Stefan Monnier
2015-09-15 12:08 ` Phillip Lord
2015-09-15 14:18 ` Stefan Monnier
2015-09-15 14:20 ` Stefan Monnier
2015-09-15 15:27 ` Phillip Lord
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvio7uqgou.fsf-monnier+emacsdiffs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=phillip.lord@russet.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).