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: Integration of undo-tree in Emacs Date: Wed, 28 May 2014 22:08:08 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1401329319 947 80.91.229.3 (29 May 2014 02:08:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2014 02:08:39 +0000 (UTC) Cc: toby-undo-tree , emacs-devel@gnu.org To: Barry OReilly Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 29 04:08:30 2014 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 1Wpplc-0000PR-90 for ged-emacs-devel@m.gmane.org; Thu, 29 May 2014 04:08:28 +0200 Original-Received: from localhost ([::1]:45756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wpplb-0002nR-Pv for ged-emacs-devel@m.gmane.org; Wed, 28 May 2014 22:08:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpplS-0002nF-3U for emacs-devel@gnu.org; Wed, 28 May 2014 22:08:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WpplK-0000tS-JP for emacs-devel@gnu.org; Wed, 28 May 2014 22:08:18 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WpplK-0000tJ-Ep for emacs-devel@gnu.org; Wed, 28 May 2014 22:08:10 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUGAIDvNVNLd/fU/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSQKh3oI0hkXjnoHhDgElGKUN4Fqg0wh X-IPAS-Result: ArUGAIDvNVNLd/fU/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSQKh3oI0hkXjnoHhDgElGKUN4Fqg0wh X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="64918035" Original-Received: from 75-119-247-212.dsl.teksavvy.com (HELO pastel.home) ([75.119.247.212]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 May 2014 22:08:09 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F065E601CB; Wed, 28 May 2014 22:08:08 -0400 (EDT) In-Reply-To: (Barry OReilly's message of "Wed, 28 May 2014 15:38:56 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:172168 Archived-At: > The appeal of undo-tree is that it allows the user to more > intuitively and directly navigate the underlying tree. If the > user wants to reach other branches of the tree using the builtin > undo system, they must retrace their edge traversals, of which > there can be many. This is poorer usability. As mentioned earlier, I'd be happy to accept a patch which removes "undo+redo+undo" elements rather than accumulating redundant traversals. IOW, buffer-undo-list can hold multiple copies of the same tree branch, and I's be happy to change this so as to remove the redundant copies. > But if you're willing to address this concern by eliminating any > requirement for the undo command to retrace edge traversals, that > would be great. Yes, that would be fine. > This kind of tree change at seemingly random times might be very > surprising to the user, albeit granted the parent-child reversals > will tend to occur away from the user's local part of the tree. Note that the set of reachable nodes is reduced in the same order as in the case of undo-tree. The difference is in how these are mapped to a tree. To a large extent the difference is in "which node is taken to be the root". If you always take "the most recent state" as the root of the tree (instead of the oldest), then both techniques are "stable" and behave "identically". > Toby, are there other reasons undo-tree needs to transfer undo > elements from the buffer-undo-list to its own data model? Toby's position is that the undo data should be kept as a tree, not as a list. That makes a lot of sense: For every branch in a tree, the undo-list keeps 2 bundles (one going forward and the other going back), but one of the two is always redundant, so the representation is inefficient. Of course, this inefficiency only applies to the *branches*, i.e. only for those elements generated by `undo', so this is irrelevant as long as most of the changes are not undos. Stefan