From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: disabling undo boundaries Date: Tue, 19 May 2015 15:42:42 -0400 Message-ID: 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> <87iobsr6m2.fsf@newcastle.ac.uk> <87oalgaicm.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432064606 29212 80.91.229.3 (19 May 2015 19:43:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 May 2015 19:43:26 +0000 (UTC) Cc: Emacs-Devel devel To: phillip.lord@newcastle.ac.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 19 21:43:15 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 1YunQ2-0001RA-KK for ged-emacs-devel@m.gmane.org; Tue, 19 May 2015 21:43:14 +0200 Original-Received: from localhost ([::1]:48465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YunQ1-0005dC-RB for ged-emacs-devel@m.gmane.org; Tue, 19 May 2015 15:43:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YunPy-0005d7-6N for emacs-devel@gnu.org; Tue, 19 May 2015 15:43:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YunPv-0000kQ-1B for emacs-devel@gnu.org; Tue, 19 May 2015 15:43:10 -0400 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:58589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YunPu-0000jy-Pm for emacs-devel@gnu.org; Tue, 19 May 2015 15:43:06 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 00C9F9C146; Tue, 19 May 2015 15:43:06 -0400 (EDT) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 55F9F1E5B8D; Tue, 19 May 2015 15:42:42 -0400 (EDT) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 239F6B4334; Tue, 19 May 2015 15:42:42 -0400 (EDT) In-Reply-To: <87oalgaicm.fsf@newcastle.ac.uk> (Phillip Lord's message of "Tue, 19 May 2015 12:59:21 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:186628 Archived-At: >> 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. Agreed. > Just wanted to bump this. I am still not sure why this is a good > behaviour. My own feeling is that the "undo-boundary when a buffer > change happens" logic may not have been implemented for this reason, but > as a belts-and-braces way of detecting the end of a command -- after > all, buffer changes (followed by an undoable event) normally happen > between commands rather than within. For process filters, I think the "right way" would be to add an undo-boundary every N insertions. > I did start working on this, but haven't got it functional yet. One > problem is that if I record the cons cell at the head of > buffer-undo-list, I have to search the whole buffer-undo-list to see if > it is there (unless I get a match). A cons cell with a nil gets added > for every self-insert-command and then removed again, so this tends to > happen quite a lot. Sounds rather ugly. Let's see how far we can go with the option of changing the current behavior rather than trying to add workarounds in your code. Could you describe the exact case that bothers you, so we could start by thinking what should be the ideal behavior for that one? Stefan