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, 15 May 2015 20:49:42 +0100 Message-ID: <87siaxk4dl.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1431719416 26431 80.91.229.3 (15 May 2015 19:50:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 May 2015 19:50:16 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 15 21:50:07 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 1YtLcT-0007wX-4S for ged-emacs-devel@m.gmane.org; Fri, 15 May 2015 21:50:05 +0200 Original-Received: from localhost ([::1]:32876 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtLcS-0006tl-Fa for ged-emacs-devel@m.gmane.org; Fri, 15 May 2015 15:50:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtLcF-0006te-Rt for emacs-devel@gnu.org; Fri, 15 May 2015 15:49:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YtLcC-0004MN-ID for emacs-devel@gnu.org; Fri, 15 May 2015 15:49:51 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:46184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YtLcC-0004MB-Bk for emacs-devel@gnu.org; Fri, 15 May 2015 15:49:48 -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 1YtLcA-0005U5-BH; Fri, 15 May 2015 20:49:46 +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 1YtLc9-0004hY-4t; Fri, 15 May 2015 20:49:45 +0100 In-Reply-To: (Stefan Monnier's message of "Fri, 15 May 2015 14:08:56 -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:186519 Archived-At: Stefan Monnier writes: >> That doesn't really make sense to me. Say I am editing a file in this >> buffer while compiling something in that buffer. Why would I want an >> update in the compilation buffer to force an undo-boundary in this buffer? > > It probably won't make any difference in "this buffer" because the > process filter will be run *between* commands (at which point the > read-eval command loop already inserts undo-boundaries anyway). > > The difference is in the compilation buffer where it'll insert undo > boundaries every time you run a command in "this buffer". 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. > >> Sorry to be persistant about this, but at the moment, changing the code >> in undo.c is the only good solution I can see to my problem. It would be >> different if explicitally called and automatic boundaries were >> distinguishable, but they aren't. > > We could make them distinguishable, OTOH (e.g. using a (weak) hash-table where > we insert every explicitly added undo-boundary). I don't understand how that would that work. undo-boundaries are nil, so surely they are all the same object? Using symbols like: '(boundary . user) '(boundary . internal) would enable this, I think. But it would break code like this: (while (or (null (car buffer-undo-list)) (and discard-pos (integerp (car buffer-undo-list)))) (setq buffer-undo-list (cdr buffer-undo-list))) from undo-tree, and I would guess quite a lot of other places. I have thought of a partial solution -- which is to add a symbol to b-u-l in the pre-command-hook, the delete all the boundaries added since that in the post-command-hook. That gets me to a clean "boundary at every command" semantics. I couldn't work out how to do this before, again, because boundaries are all the same object. Phil