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: disabling undo boundaries Date: Sun, 09 Aug 2015 16:39:21 +0100 Message-ID: <87pp2wmpxy.fsf@russet.org.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87siaxk4dl.fsf@newcastle.ac.uk> <87iobsr6m2.fsf@newcastle.ac.uk> <87oalgaicm.fsf@newcastle.ac.uk> <87y4kkkzlo.fsf@newcastle.ac.uk> <87mw0zk7yp.fsf@newcastle.ac.uk> <87617mgp1b.fsf@newcastle.ac.uk> <871ti9ammc.fsf@newcastle.ac.uk> <878ucaqm3g.fsf@newcastle.ac.uk> <87y4hrm911.fsf@newcastle.ac.uk> <87wpx79pz6.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439134795 27829 80.91.229.3 (9 Aug 2015 15:39:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 15:39:55 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 17:39:38 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 1ZOShG-0005BG-9B for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 17:39:38 +0200 Original-Received: from localhost ([::1]:55531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOShF-00055n-IY for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 11:39:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50762) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOShC-00055T-4M for emacs-devel@gnu.org; Sun, 09 Aug 2015 11:39:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOSh7-0008CP-Ta for emacs-devel@gnu.org; Sun, 09 Aug 2015 11:39:34 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:42818) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOSh7-0008Bq-Mh for emacs-devel@gnu.org; Sun, 09 Aug 2015 11:39:29 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot22.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1ZOSh3-0008Ix-E0; Sun, 09 Aug 2015 16:39:25 +0100 Original-Received: from cpc6-benw10-2-0-cust45.gate.cable.virginm.net ([92.238.179.46] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1ZOSh2-0008QO-6e; Sun, 09 Aug 2015 16:39:25 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 8 Aug 2015 17:28:28 -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.22 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:188642 Archived-At: Stefan Monnier writes: >>> Anyway, the patch is there. Any chance? If not, anything (further) that >>> I can add (or remove!) to the branch to make it happen? >> I'll try and look at it soon, > > IIUC this only removes the code which adds a boundary when we change > buffer. IOW it switches from the conservative option of adding > a boundary even if it might not be needed, to the risky option of hoping > that someone else will add the needed boundary. I'd tend to characterise it as the risky option of disrupting the user experience by added unnecessary boundaries on the off-chance of using too much memory, against the conservative option of not adding a boundary. But, otherwise, yes. > As explained, this will most likely introduce problems with ever-growing > undo-logs in buffers filled by process output and timers. Will buffer-undo-list not be truncated by GC anyway? I can't quite understand where the ever-growing logs come from, nor how the functionality I have removed would prevent it. > It's an acceptable first step, but it needs to be compensated by > a second step which keeps track of all buffers modified during the > execution of a command and change the "add a boundary in current-buffer > at the end of a command" to "add boundaries in all modified buffers > at the end of a command". I'm struggling with understanding this also. I've tried tracing when the code my patch removes actually runs and it is pretty rarely. And, yet, undo works correctly, generally on a per-command basis (except for the self-insert-command special handling). Also, adding boundaries in all modified buffers strikes me as fairly stochastic. Assuming a well-behaved timer (i.e. one that releases control with `sit-for'), this logic essentially translates to "we may choose to show an undo-boundary in at this point, or we may not". So I'd need an example, though, or some way of causing this sort of problem that you are worried about. A failing ert test in test/automated would be ideal, but anything is good! Phil