From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.devel Subject: Re: Integration of undo-tree in Emacs Date: Mon, 2 Jun 2014 22:23:53 +0100 Message-ID: <20140602212353.GA18125@c3po.lapwing.cam.ac.uk> References: Reply-To: Toby Cubitt NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1401744261 9402 80.91.229.3 (2 Jun 2014 21:24:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Jun 2014 21:24:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Barry OReilly Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 02 23:24:12 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 1WrZiE-0003mo-3c for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2014 23:24:10 +0200 Original-Received: from localhost ([::1]:49352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrZiD-0006Pk-O7 for ged-emacs-devel@m.gmane.org; Mon, 02 Jun 2014 17:24:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WrZi6-0006Mq-VO for emacs-devel@gnu.org; Mon, 02 Jun 2014 17:24:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WrZi2-000590-Rk for emacs-devel@gnu.org; Mon, 02 Jun 2014 17:24:02 -0400 Original-Received: from sanddollar.geekisp.com ([216.168.135.167]:4761) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1WrZi2-00058v-Me for emacs-devel@gnu.org; Mon, 02 Jun 2014 17:23:58 -0400 Original-Received: (qmail 12609 invoked by uid 1003); 2 Jun 2014 21:23:58 -0000 Original-Received: from localhost (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Mon, 02 Jun 2014 17:23:55 -0400 Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) X-Primary-Address: toby@dr-qubit.org X-detected-operating-system: by eggs.gnu.org: OpenBSD 4.x-5.x [fuzzy] X-Received-From: 216.168.135.167 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:172274 Archived-At: On Mon, Jun 02, 2014 at 12:24:22PM -0400, Barry OReilly wrote: > > I maintain that users are not going to want to hold both models in > > their heads. > > I didn't say users should hold two models in their head. I didn't > propose two. > > > As far as I remember, I've never had anyone ask me if it would be > > possible to combine both systems. > > http://lists.gnu.org/archive/html/gnu-emacs-sources/2009-11/msg00010.html Sure, I completely understand why Stefan said this. And for what it's worth I agree. I meant I don't remember any *user* saying they'd like to be able to use both systems simultaneously. > > It's the latter that I predict will be hard work > > No doubt. > > > If the two are to coexist, how are the two models of undo going to > > interact? > > You've misunderstood something, see the first answer above. I guess I still don't quite follow from the above discussion how redo as undoing-an-undo and redo as descending the undo tree would work together. Probably you've thought this through already and I just didn't understand, or it was discussed earlier in the thread before you cc'd me. > > How will history-discarding work well for both models? > > Discussed already in the thread. Yes, I saw that part of the discussion. Sounds like it might require tweaking the order in which undo history gets discarded to match the undo-tree model. But it also sounds like Stefan is OK with this, so maybe this one's already solved. > > If you want to integrate undo-tree into Emacs, whilst also keeping > > the traditional undo system (presumably an essential requirement), > > why not keep the elegant and conceptually simple (biased personal > > opinion :-) `buffer-undo-tree's data structure, but make the nodes > > point to the appropriate changesets in buffer-undo-list? > > That may be an option. > > > That way most of the undo-tree code, including all the tree-related > > features, will work unchanged or with very minor changes. > > I know the value of starting from code that works now. > > > Reimplementing undo-tree from scratch on top of > > undo-(equiv|redo)-table smacks a little of NIH syndrome to me. > > Nice strawman argument. Sorry if I caused offence. I'm not subscribed to emacs-devel at the moment (no time to keep up with the list), so I only saw the latter half of the discussion from when you started to cc me. It sounded like the proposal was to implement something on top of undo-[equiv|redo]-table, which sounds very much like reimplementing undo-tree from scratch in Emacs. Maybe I misconstrued. > > I think you're still missing the main point I was making. Because > > buffer-undo-tree isn't treated specially by GC, even unreferenced > > *deleted* markers (e.g. from `delete-overlay') continued to exist in > > the undo-tree. Undoing a changeset containing a marker-update entry > > for one of those deleted markers would resurrect the deleted marker, > > recreating overlays, and causing general havoc. > > You may have misattributed the root cause of those problems. Quite possibly. It would be interesting to test with the undo-tree GC-elt pool code disabled, and see what happens with markers/overlays under recent Emacsen. Best, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Fellow of Churchill College, Cambridge Centre for Quantum Information DAMTP, University of Cambridge email: tsc25@cantab.net web: www.dr-qubit.org