[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Integration of undo-tree in Emacs
From: |
Toby Cubitt |
Subject: |
Re: Integration of undo-tree in Emacs |
Date: |
Mon, 2 Jun 2014 22:23:53 +0100 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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: address@hidden
web: www.dr-qubit.org