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: Thu, 06 Aug 2015 22:02:59 +0100 Message-ID: <8737zwyvss.fsf@newcastle.ac.uk> References: <87fv746rd5.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> <87y4hrm911.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1438895017 13810 80.91.229.3 (6 Aug 2015 21:03:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 21:03:37 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 06 23:03:28 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 1ZNSJt-0002dn-VP for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 23:03:22 +0200 Original-Received: from localhost ([::1]:46680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNSJt-0002LY-0m for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 17:03:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39286) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNSJm-0002HU-CN for emacs-devel@gnu.org; Thu, 06 Aug 2015 17:03:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNSJh-0002D9-LG for emacs-devel@gnu.org; Thu, 06 Aug 2015 17:03:14 -0400 Original-Received: from cheviot22.ncl.ac.uk ([128.240.234.22]:58519) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNSJh-0002CU-En for emacs-devel@gnu.org; Thu, 06 Aug 2015 17:03:09 -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 1ZNSJg-00086O-Eo; Thu, 06 Aug 2015 22:03:08 +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 1ZNSJe-0008UT-SE; Thu, 06 Aug 2015 22:03:08 +0100 In-Reply-To: <87y4hrm911.fsf@newcastle.ac.uk> (Phillip Lord's message of "Tue, 4 Aug 2015 15:18:50 +0100") 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:188515 Archived-At: Phillip Lord writes: > 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:-) I have added the change that I am suggesting to: fix/no-undo-boundary-on-secondary-buffer-change The change simplifies undo.c somewhat. I can see no reason for the existing logic, and it is has extremely counter-intuitive consequences when using as discussed when using post-c-h or a-c-f. But clearly it also changes some deep (and old!) logic in undo.c. So, making this my first commit to trunk would clearly be reckless. Let me know what you think. If you are unhappy, I will drop the idea entirely and delete the branch. If you are happy, I will leave you to merge/rebase as you choose. If you don't like my commit message grammar, I can fix and squash on a branch! Cheers Phil