Re: Integration of undo-tree in Emacs

[Barry OReilly <gundaetiapo@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

> 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

> 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.

> How will history-discarding work well for both models?

Discussed already in the thread.

> 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.

> 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.

[-- Attachment #2: Type: text/html, Size: 2208 bytes --]