From: Toby Cubitt <tsc25@cantab.net>
To: Barry OReilly <gundaetiapo@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Integration of undo-tree in Emacs
Date: Mon, 2 Jun 2014 22:23:53 +0100 [thread overview]
Message-ID: <20140602212353.GA18125@c3po.lapwing.cam.ac.uk> (raw)
In-Reply-To: <CAFM41H2sv372mBivi-m_ppMy1CoSrysqoTEyGzkQpAaB+W0qvw@mail.gmail.com>
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
next prev parent reply other threads:[~2014-06-02 21:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-28 19:38 Integration of undo-tree in Emacs Barry OReilly
2014-05-28 22:14 ` Toby Cubitt
2014-05-29 2:57 ` Barry OReilly
[not found] ` <20140529180441.GA12623@c3po.maths.private.cam.ac.uk>
2014-05-30 14:40 ` Barry OReilly
2014-06-02 10:57 ` Toby Cubitt
2014-06-02 16:24 ` Barry OReilly
2014-06-02 21:23 ` Toby Cubitt [this message]
2014-05-29 2:08 ` Stefan Monnier
2014-05-29 17:42 ` Toby Cubitt
2014-05-30 12:00 ` Barry OReilly
2014-05-30 16:01 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140602212353.GA18125@c3po.lapwing.cam.ac.uk \
--to=tsc25@cantab.net \
--cc=emacs-devel@gnu.org \
--cc=gundaetiapo@gmail.com \
--cc=toby-dated-1402953837.67d90c@dr-qubit.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.