From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel 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 Message-ID: References: <20150821093606.11577.60349@vcs.savannah.gnu.org> <87d1y272f9.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441124219 19023 80.91.229.3 (1 Sep 2015 16:16:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 16:16:59 +0000 (UTC) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 01 18:16:49 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZWoEr-0003yM-OV for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 18:16:49 +0200 Original-Received: from localhost ([::1]:55678 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWoEr-0001hU-H3 for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 12:16:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55951) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWoET-0001dm-Pz for emacs-devel@gnu.org; Tue, 01 Sep 2015 12:16:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWoEP-0003TF-Sh for emacs-devel@gnu.org; Tue, 01 Sep 2015 12:16:25 -0400 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:46327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWoEP-0003T7-KD for emacs-devel@gnu.org; Tue, 01 Sep 2015 12:16:21 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t81GGI0R013948; Tue, 1 Sep 2015 12:16:18 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 302DD6615C; Tue, 1 Sep 2015 12:16:18 -0400 (EDT) In-Reply-To: <87d1y272f9.fsf@russet.org.uk> (Phillip Lord's message of "Tue, 01 Sep 2015 13:24:26 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered LNG_SB_1=0.2, RV5416=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5416> : inlines <3733> : streams <1498141> : uri <2030118> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189393 Archived-At: > 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