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: Fri, 07 Aug 2015 22:10:00 +0100 Message-ID: <87egjehkk7.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <871tiiowjw.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> <874mkbjj2u.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438981839 29552 80.91.229.3 (7 Aug 2015 21:10:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Aug 2015 21:10:39 +0000 (UTC) Cc: Stefan Monnier , Emacs-Devel devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 07 23:10:31 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 1ZNouM-00045P-Pk for ged-emacs-devel@m.gmane.org; Fri, 07 Aug 2015 23:10:30 +0200 Original-Received: from localhost ([::1]:51241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNouL-0004B6-Ga for ged-emacs-devel@m.gmane.org; Fri, 07 Aug 2015 17:10:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52969) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNouE-0004A6-Qb for emacs-devel@gnu.org; Fri, 07 Aug 2015 17:10:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNouA-0003gE-Nc for emacs-devel@gnu.org; Fri, 07 Aug 2015 17:10:22 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:55962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNou5-0003d2-Il; Fri, 07 Aug 2015 17:10: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 1ZNou3-0007C6-Er; Fri, 07 Aug 2015 22:10:11 +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 1ZNou1-00005Q-Tf; Fri, 07 Aug 2015 22:10:11 +0100 In-Reply-To: <874mkbjj2u.fsf@fencepost.gnu.org> (David Kastrup's message of "Fri, 7 Aug 2015 15:59:05 +0200") 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:188585 Archived-At: David Kastrup writes: > phillip.lord@newcastle.ac.uk (Phillip Lord) writes: > >> Stefan Monnier writes: >> >>>> I think that the current undo-boundary behaviour wrt a single buffer >>>> makes sense. It's the fact that inserting content into *that* buffer >>>> forces an undo-boundary into *this* buffer. I don't know why Emacs >>>> does this. >>> >>> I think the reason is not very deep: for reasons of efficiency (back in >>> the days when 8MB was a lot of memory), Emacs keeps track of a few >>> undo-related pieces of information in global variables, so it can only >>> handle a single buffer at a time. If a command touches some other >>> buffer, the C code has to choose between "just switch" and "push >>> a boundary and then switch", and the choice it makes is to err on the >>> "safe" side of adding a potentially unnecessary undo-boundary rather >>> than risking to let the undo-log grow without intervening boundaries. >> >> >> I meant "deep" in the sense of "deep in version control history" -- or >> in this case, before the version control system. Still, I didn't know >> this was the reason. > > The problem _I_ see is that it is in general not just "a command" which > may touch another buffer, but also compilation buffers, timer events, > font lock and a number of other background activities not immediately > caused by key presses. I don't think this is an issue, because Emacs is single-threaded. So, all of these events happen *between* commands which, in general, means that an undo-boundary has gone onto the current-buffer anyway. So, they don't break the undo behaviour in the current-buffer. If it were not, the current semantics of Emacs undo would have been shown to be problematic a long time ago. As it stands (as I think I mentioned a long time ago!), I've checked how often undo-boundaries are added by the current logic and the answer is hardly ever. The code is almost entirely benign AFAICT, in that it never runs. It just makes undo.c more complex than necessary, and is a total disaster for my use case. As always, it depends on what you do with Emacs and I may be missing something where it is the right thing. I can't tell. Phil