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: Sat, 16 May 2015 14:31:49 +0100 Message-ID: <87iobsr6m2.fsf@newcastle.ac.uk> References: <87fv746rd5.fsf@newcastle.ac.uk> <87617zl4kh.fsf@newcastle.ac.uk> <87h9rjhy8w.fsf@newcastle.ac.uk> <87oalqrgm7.fsf@newcastle.ac.uk> <87ioby3tdy.fsf@newcastle.ac.uk> <87y4kth5ps.fsf@newcastle.ac.uk> <87sib0a3jr.fsf@newcastle.ac.uk> <871tiiowjw.fsf@newcastle.ac.uk> <87siaxk4dl.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431783136 11084 80.91.229.3 (16 May 2015 13:32:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 16 May 2015 13:32:16 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 16 15:32:09 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 1YtcCH-0007vH-2t for ged-emacs-devel@m.gmane.org; Sat, 16 May 2015 15:32:09 +0200 Original-Received: from localhost ([::1]:34655 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtcCG-0002DB-K1 for ged-emacs-devel@m.gmane.org; Sat, 16 May 2015 09:32:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtcCC-0002D5-Ro for emacs-devel@gnu.org; Sat, 16 May 2015 09:32:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtcC8-0002ri-R5 for emacs-devel@gnu.org; Sat, 16 May 2015 09:32:04 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:38988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtcC8-0002nE-Kz for emacs-devel@gnu.org; Sat, 16 May 2015 09:32:00 -0400 Original-Received: from smtpauth-vm.ncl.ac.uk ([10.8.233.129] helo=smtpauth.ncl.ac.uk) by cheviot12.ncl.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1YtcC5-000432-AD; Sat, 16 May 2015 14:31:57 +0100 Original-Received: from cpc7-benw10-2-0-cust228.16-2.cable.virginm.net ([77.98.254.229] helo=localhost) by smtpauth.ncl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YtcC4-0003sg-PM; Sat, 16 May 2015 14:31:56 +0100 In-Reply-To: (Stefan Monnier's message of "Fri, 15 May 2015 19:45:58 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.0.0.0 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 128.240.234.12 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:186534 Archived-At: Stefan Monnier writes: >> Yes, I can see that. Although iff this is the reason for the >> undo-boundary, it would still make more sense to me to have the process >> code insert this. Aside from being a more discrete effect, it would also >> avoid the current "do nothing now, but insert an undo-boundary before >> the next change where ever that is" semantics. > > I don't claim it's the best solution, indeed. It's just that if we > remove it, we'll have to replace it with other mechanisms. > So we need a clear description of the current cases that are considered > misbehaviors and those that are considered good (tho not necessarily > perfect). I entirely agree with this, of course. This is why I am trying to find positive behaviour. So, I have tested this, and indeed commenting out that code does affect undo behaviour. To test this, I wrote a "countdown" script which, well, counts down, and then ran this in *shell*. Then I typed into *scratch* at defined points. With the undo-boundary code, indeed, the typing in *scratch* does add boundaries -- so that a countdown from 100 say, gets split up into multiple undos. Without this code, the countdown gets undone in one go. So, while it clearly has an effect, I am not sure why this is better. For example, if I launch two shell buffers, then run "countdown 20" in both at the same time, then both buffers now undo in 20 steps, one second at a time, because their output interleaves. Again, the "add an undo boundary because of a change in another buffer" semantics does not seem intuitive to me. >> I don't understand how that would that work. undo-boundaries are nil, so >> surely they are all the same object? > > No, we'd record put the cons cell in which the nil is placed. Oh, yes, of course. That does assume, though, that any operations on buffer-undo-list are destructive. For instance, if I filter the buffer-undo-list with seq.el or dash, do I not get all new cons cells? Still, most of the undo.c code seems to change in place, so I guess it would work in most cases. Phil