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, 21 May 2015 12:15:12 +0100 Message-ID: <87617mgp1b.fsf@newcastle.ac.uk> References: <87fv746rd5.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> <87y4kkkzlo.fsf@newcastle.ac.uk> <87mw0zk7yp.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432206989 11570 80.91.229.3 (21 May 2015 11:16:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2015 11:16:29 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 21 13:16:24 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 1YvOSd-0000rs-6X for ged-emacs-devel@m.gmane.org; Thu, 21 May 2015 13:16:23 +0200 Original-Received: from localhost ([::1]:56644 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvOSc-0007s9-CP for ged-emacs-devel@m.gmane.org; Thu, 21 May 2015 07:16:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvORg-0007Dc-1w for emacs-devel@gnu.org; Thu, 21 May 2015 07:15:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvORa-0005XN-Ae for emacs-devel@gnu.org; Thu, 21 May 2015 07:15:24 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:49808) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvORa-0005Wc-2V for emacs-devel@gnu.org; Thu, 21 May 2015 07:15:18 -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 1YvORU-00050Z-Cb; Thu, 21 May 2015 12:15:12 +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 1YvORU-0003sQ-MP; Thu, 21 May 2015 12:15:12 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 20 May 2015 08:53:49 -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:186695 Archived-At: Stefan Monnier writes: >> M-x fill-paragraph > [...] >> At my count it takes 8 undo operations to undo "fill-paragraph". > > Good example, thank you. But IIUC just removing the "undo-boundary on > buffer-change" code still wouldn't give you the perfect behavior, > because you still do want an undo-boundary in the second buffer, right? Yes, you are right, the second buffer is an issue, although I am not convinced that the behaviour is worse. Below I have described two tasks both of which change another buffer on a-c-f. I'm comparing between an Emacs 24.5 (as released, but built from git by me) and my own Emacs (based on 24.4 actually) with the relevant sections of undo.c commented out. Again, built by me. With the existing logic I get a lot of undo boundaries. Without the existing logic I get a sane number of boundaries. I do not get the same undo-boundaries that I would have got in the other buffer if I had made changes by typing commands rather than using a-c-f. But I could add these programmatically with as much or as little fidelity as I choose. The data I make these conclusions on is below. Phil * Noisy-change ** Task Type "abcdef" into *scratch* with (setq noisy-change-log t), then check buffer-undo-list in the created noisy-change-log buffer. I pick this task because it's about as simple as it gets. ** With existing undo-boundary code (nil (402 . 439) nil (329 . 402) nil (256 . 329) nil (183 . 256) nil (110 . 183) nil (37 . 110) nil (1 . 37) (t . 0)) ** Without existing undo-boundary logic (nil (1 . 439) (t . 0)) ** Conclusion The amalgamation of several events is working. * lentic-view ** Task Use "Create Lentic View" (this creates an exact clone, rather like an indirect-buffer). ** With existing undo-boundary logic (nil (197 . 198) nil (196 . 197) nil (195 . 196) nil (194 . 195) nil (193 . 194) nil (192 . 193)) ** Without existing undo-boundary logic (nil (192 . 198)) ** Conclusion Same as last, but with a simpler set of events. * Task 3 Use lentic-view, type in the entire alphabet ** Without existing undo-boundary logig (nil (192 . 217) nil (1 . 192) (t . 0)) ** Conclusion The "undo-boundary every 20 self-insert-command"s logic is not working or it should be something like this... (nil (212 . 218) nil (192 . 212)) I could add this logic in, although it's a bit of pain and requires effectively duplicating logic from cmds.c in lisp. * Task 4 Using lentic view, type in abcdefghijk abcdefghijk ** In *scratch* (nil (208 . 222) nil (206 . 208) nil (192 . 206)) ** In "*lentic: scratch*" (nil (192 . 222) nil (1 . 193) (t . 0)) ** Conclusion All of the insertion events have been amalgamated, so the undo is much too "lumpy". Again, I can add this logic in, but I have to duplicate the "add an undo-boundary after a command" logic from the command loop.