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 18:03:55 +0100 Message-ID: <871ti9ammc.fsf@newcastle.ac.uk> References: <87fv746rd5.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> <87617mgp1b.fsf@newcastle.ac.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1432227858 7017 80.91.229.3 (21 May 2015 17:04:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 May 2015 17:04:18 +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 19:04:18 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 1YvTtI-00030E-Bo for ged-emacs-devel@m.gmane.org; Thu, 21 May 2015 19:04:16 +0200 Original-Received: from localhost ([::1]:58683 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvTtH-0000Pi-Lg for ged-emacs-devel@m.gmane.org; Thu, 21 May 2015 13:04:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvTt5-0000Pc-Fs for emacs-devel@gnu.org; Thu, 21 May 2015 13:04:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YvTt2-0003wF-8d for emacs-devel@gnu.org; Thu, 21 May 2015 13:04:03 -0400 Original-Received: from cheviot12.ncl.ac.uk ([128.240.234.12]:46154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YvTt1-0003vs-L7 for emacs-devel@gnu.org; Thu, 21 May 2015 13:04: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 1YvTt0-0001Ps-AS; Thu, 21 May 2015 18:03:58 +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 1YvTsy-0003pG-3k; Thu, 21 May 2015 18:03:56 +0100 In-Reply-To: (Stefan Monnier's message of "Thu, 21 May 2015 11:44:47 -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:186714 Archived-At: Stefan Monnier writes: >> Yes, you are right, the second buffer is an issue, although I am not >> convinced that the behaviour is worse. > > Worse than the ideal or worse than the current one? The current situation. > Right now, I'm trying to understand what the ideal behavior should be. I don't have a clear handle on this either. For my two use cases, with noisy-change-log, I think the answer is, I don't really care. I don't need undo in a log buffer, and if I had thought about it, I would have switched it off. For lentic, I would like the undo-boundaries to be what they would have been if the commands had been typed manually. > After that, we can try to figure out how to get this ideal behavior, or > how close we can get to it, and which part of the work can be made > generic in undo.c and which part of the work has to be done manually by > each and every particular command/package. That would be good. Another package worth looking at would be gnus, which AFAICT, reimplements undo all for itself, to cope with the fact that it's a multi buffer sort of package. >> ** 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. > > [ You only used self-insert-command in your examples, which gives > a slightly twisted view of what's going on in general. ] > > But ideally, we could have undo.c do most of that for you. > E.g. instead of adding a boundary every time we switch buffer, undo.c > could simply keep track of which buffers have seen changes during the > current command, and then push undo-boundaries on all of them at the end > of the command. Yeah, thought about that and that would get me most of the way there. I think that should not affect *shell* buffers or equivalent right? They actually only update outside of the command loop, so can't have changed in the middle? > Except for self-insert-command, I think this would give you the ideal > behavior (without any manual work on your side) *and* it would mostly > preserve the existing behavior. > > For self-insert-command, it's more tricky, and you'd probably need to do > the extra manual work. E.g. add a post-self-insert-hook which checks if > this self-insert-command removed the previous undo-boundary and then > remove it as well in the sibling buffer. I can't see how undo.c could > do that for you magically, since it doesn't know that the insertions in > the sibling buffer are "clones" of the insertions in the main buffer, > nor that it's done by self-insert-command. I'd agree with this. One possibility would be to have an undo-boundary command which is implements the same sort of "20 steps" logic as self-insert-command. But, even that is going to be hard, since there can be more changes in *that* buffer than in *this* (the two are not necessarily exactly the same). I think this would all be a little easier if buffer-undo-list didn't use "nil" but allowed the developer to differentiate between different kinds of boundary. > Another approach would be for you to arrange such that your a-f-c uses > self-insert-command rather than `insert' when cloning the insertion > from a self-insert-command, but that's probably just as hard if not > harder. That doesn't sound great to me either, as I have to behave quite differently depending on the last-command. It seems to me, that you are not adverse to the idea of changing undo.c to stop it putting boundaries in. Can I suggest a way forward? I will carry on with my hacked Emacs with removed undo-boundaries in undo.c. I can add the "undo-boundary to all changed buffers" using post-command-hook. This will let me test everything makes sense and works as expected, and I don't mind spending the effort, if emacs will support it later. If you are prepared to implement the "add an undo-boundary to every buffer thats changed" logic into undo.c/cmd.c, then we can do that once the logic works. I would be willing to help with that, but my C programming is very poor, and in practice, I'm likely to learn more than I actually help. Phil