From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@russet.org.uk (Phillip Lord) 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 13:24:26 +0100 Message-ID: <87d1y272f9.fsf@russet.org.uk> References: <20150821093606.11577.60349@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441110298 31227 80.91.229.3 (1 Sep 2015 12:24:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 1 Sep 2015 12:24:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 01 14:24:53 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 1ZWkcO-0007Zo-Vx for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 14:24:53 +0200 Original-Received: from localhost ([::1]:53688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWkcO-0001ur-DL for ged-emacs-devel@m.gmane.org; Tue, 01 Sep 2015 08:24:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWkc8-0001uh-TZ for emacs-devel@gnu.org; Tue, 01 Sep 2015 08:24:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZWkc5-0008PK-Mp for emacs-devel@gnu.org; Tue, 01 Sep 2015 08:24:36 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:44729) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZWkc5-0008OS-Ge for emacs-devel@gnu.org; Tue, 01 Sep 2015 08:24:33 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZWkc1-0005F6-9t; Tue, 01 Sep 2015 13:24:29 +0100 Original-Received: from jangai.ncl.ac.uk ([10.66.67.223] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZWkc0-0005R7-2o; Tue, 01 Sep 2015 13:24:28 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 29 Aug 2015 23:30:13 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:189381 Archived-At: Stefan Monnier writes: >> +(defun undo-ensure-boundary () >> + "Add an `undo-boundary' if `buffer-undo-list' is long. >> + >> +Return t if an undo boundary has been added. >> + >> +Normally, Emacs will only garbage collect data from >> +`buffer-undo-list' when this list is longer than `undo-limit'. It >> +then collects data from after the first `undo-boundary' after >> +`undo-limit'. If there are no boundaries in the list, >> +`buffer-undo-list' will grow until it reaches >> +`undo-outer-limit' (by default a much larger value than >> +`undo-limit'), when it will discard the data anyway. In this >> +case, however, it is treated as an exceptional case, and the a >> +warning is signalled. >> + >> +This function add an `undo-boundary' to `buffer-undo-list' if >> +there is no other `undo-boundary', and `buffer-undo-list' is >> +longer than `undo-limit'. It provides a useful default mechanism >> +for adding an `undo-boundary' which retains data where possible, >> +without signalling warnings to the user." > > I think this makes sense, but we should do it in the GC code, then. 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. Phil