Re: Integration of undo-tree in Emacs

[Toby Cubitt <tsc25@cantab.net>]

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