all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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



  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

* 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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.