From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: phillip.lord@newcastle.ac.uk (Phillip Lord) Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Sun, 09 Aug 2015 17:50:10 +0100 Message-ID: <878u9kcsot.fsf@newcastle.ac.uk> References: <87fv746rd5.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> <87pp2wmpxy.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439139033 23960 80.91.229.3 (9 Aug 2015 16:50:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 16:50:33 +0000 (UTC) Cc: Emacs-Devel devel , Phillip Lord To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 18:50:24 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 1ZOTnj-0008Uw-4d for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 18:50:23 +0200 Original-Received: from localhost ([::1]:55782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOTni-0007fs-Dm for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 12:50:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOTnd-0007bg-Pv for emacs-devel@gnu.org; Sun, 09 Aug 2015 12:50:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOTnZ-0000c1-Pb for emacs-devel@gnu.org; Sun, 09 Aug 2015 12:50:17 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:44157) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOTnZ-0000bf-F1 for emacs-devel@gnu.org; Sun, 09 Aug 2015 12:50:13 -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 1ZOTnY-0005QY-EZ; Sun, 09 Aug 2015 17:50:12 +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 1ZOTnY-0001k4-4B; Sun, 09 Aug 2015 17:50:12 +0100 In-Reply-To: (Stefan Monnier's message of "Sun, 9 Aug 2015 12:30:54 -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:188653 Archived-At: Stefan Monnier writes: >> Will buffer-undo-list not be truncated by GC anyway? > > Truncation is only done at undo-boundaries. Hence the problem. Ah, yes, okay. >> I'm struggling with understanding this also. I've tried tracing when the >> code my patch removes actually runs and it is pretty rarely. > > When you're editing buffer FOO while some process is inserting data in > buffer BAR. Okay. So, buffer BAR should get undo-boundaries when a command runs in FOO? And FOO should get an undo-boundary when the process adds something to BAR? > Or when your commands modify two buffers (e.g. in your case). Well, I think that this is my problem (as the author of the command, rather than as the user). I mean, I modify two buffers, I need to fix the undo, to decide what I want to do about this. For my use case, this would work much better because I could even do the "undo-boundary unless it's self-insert in which case wait for 20 of them" logic. In the case of a logging mode (i.e. which logs all events), I'd switch the undo off in that buffer anyway. >> Also, adding boundaries in all modified buffers strikes me as fairly >> stochastic. > > Not sure what you mean. I am editing a buffer, FOO. I type something in the usual way, with some pauses for me to think. Mean time, an idle-timer is running, doing something to BAR. If I think long, the undo will behave in one way, if I think quick, the undo will behave in another, depending on whether the idle-timer has modified BAR or not. > >> Assuming a well-behaved timer (i.e. one that releases >> control with `sit-for'), > > Hmm? timers usually shouldn't call sit-for. Oh, now I am sure that this used to be recommended (which is why I did it). I use this when I have a long running idle timer -- I sit-for a very short gap, then carry on if there is no input pending, then carry on. Well, that's more code to fix! Phil