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: Tue, 04 Aug 2015 15:18:50 +0100 Message-ID: <87y4hrm911.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87y4kth5ps.fsf@newcastle.ac.uk> <87sib0a3jr.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438705376 6971 80.91.229.3 (4 Aug 2015 16:22:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Aug 2015 16:22:56 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 04 18:22:51 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 1ZMezL-00019N-2X for ged-emacs-devel@m.gmane.org; Tue, 04 Aug 2015 18:22:51 +0200 Original-Received: from localhost ([::1]:36325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMezK-0004xb-Eu for ged-emacs-devel@m.gmane.org; Tue, 04 Aug 2015 12:22:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40975) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMezF-0004wV-CH for emacs-devel@gnu.org; Tue, 04 Aug 2015 12:22:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMezB-000279-8T for emacs-devel@gnu.org; Tue, 04 Aug 2015 12:22:45 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:42276) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMezB-00024n-1v for emacs-devel@gnu.org; Tue, 04 Aug 2015 12:22:41 -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 1ZMe4G-000488-D1; Tue, 04 Aug 2015 16:23:52 +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 1ZMe4F-00018T-Q7; Tue, 04 Aug 2015 16:23:51 +0100 In-Reply-To: (Stefan Monnier's message of "Sun, 28 Jun 2015 20:46:26 -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:188400 Archived-At: Stefan Monnier writes: >> Actually, I have been thinking about this. What I worry about with this >> is that we may be adding the same form of heuristic into undo.c as the >> "insert an undo-boundary if the buffer has changed". > > Yes, because we do want this to happen, pretty much always (having > changes accumulate without intervening boundary is actually a problem > that can lead to nasty behaviors). > > There are exceptions, but they're rare. Sorry for late reply -- been travelling. The heuristic I was refering to is the "insert an undo-boundary if the current-buffer has changed". Or, rather, insert an undo-boundary if some *other* buffer has changed. 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. In most cases, this is irrelevant and doesn't happen anyway, and where you have a p-c-h or a-c-f it changes undo behaviour. I worry that I am missing a good reason for this behaviour, but I have thought about it and failed to come up with a reason; negative conclusions are always worrisome, but what else can you do? I'll write a patch to trunk and send it in, once my life has caught up, then I can happily pass the buck of making the final decision to you:-) Phil