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: disabling undo boundaries Date: Sun, 09 Aug 2015 13:40:36 -0400 Message-ID: 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> <878u9kcsot.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1439142069 2806 80.91.229.3 (9 Aug 2015 17:41:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 9 Aug 2015 17:41:09 +0000 (UTC) Cc: Emacs-Devel devel , Phillip Lord To: phillip.lord@newcastle.ac.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 09 19:41:03 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 1ZOUaj-0000Xm-BQ for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 19:41:01 +0200 Original-Received: from localhost ([::1]:55875 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOUai-0003Zd-Gs for ged-emacs-devel@m.gmane.org; Sun, 09 Aug 2015 13:41:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOUaQ-0003ZU-JW for emacs-devel@gnu.org; Sun, 09 Aug 2015 13:40:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZOUaN-00007S-E1 for emacs-devel@gnu.org; Sun, 09 Aug 2015 13:40:42 -0400 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:50726) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZOUaN-00006A-1d for emacs-devel@gnu.org; Sun, 09 Aug 2015 13:40:39 -0400 Original-Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.DIT.UMontreal.CA (8.14.1/8.14.1) with ESMTP id t79HeXC0016990; Sun, 9 Aug 2015 13:40:33 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 8C926660E9; Sun, 9 Aug 2015 13:40:36 -0400 (EDT) In-Reply-To: <878u9kcsot.fsf@newcastle.ac.uk> (Phillip Lord's message of "Sun, 09 Aug 2015 17:50:10 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5393=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5393> : inlines <3585> : streams <1485716> : uri <2009816> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.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:188655 Archived-At: >>> 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? The general goal is: add undo-boundaries often enough so the undo-log doesn't grow too large, both in FOO and in BAR, and ideally in ways which are somewhat predictable for the user. If you ask my ideal: FOO would get an undo-boundary after each command, and BAR would get an undo boundary after each N bytes inserted, or after every N seconds. >>> 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. In the scenario of "add boundaries to every buffer modified since last time"? Why do you think so? The boundaries in Foo will not be influenced by the timer. The boundaries in Bar will, indeed, because they'll only be inserted as a side-effect of the commands in Foo and depending on how much you think, the timer could fire several times between commands. Hence my ideal wish of "get an undo boundary after each N bytes inserted, or after every N seconds" for things like process output or timers. >>> 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. Ah, you're thinking of a long-running idle-timer, basically a poor man's background task. Yes, then it needs to call sit-for, but I don't think it makes much difference in the end result in the scenarios discussed here. Stefan