Re: Integration of undo-tree in Emacs

[Stefan Monnier <monnier@iro.umontreal.ca>]

> The appeal of undo-tree is that it allows the user to more
> intuitively and directly navigate the underlying tree. If the
> user wants to reach other branches of the tree using the builtin
> undo system, they must retrace their edge traversals, of which
> there can be many. This is poorer usability.

As mentioned earlier, I'd be happy to accept a patch which removes
"undo+redo+undo" elements rather than accumulating redundant traversals.

IOW, buffer-undo-list can hold multiple copies of the same tree
branch, and I's be happy to change this so as to remove the
redundant copies.

> But if you're willing to address this concern by eliminating any
> requirement for the undo command to retrace edge traversals, that
> would be great.

Yes, that would be fine.

> This kind of tree change at seemingly random times might be very
> surprising to the user, albeit granted the parent-child reversals
> will tend to occur away from the user's local part of the tree.

Note that the set of reachable nodes is reduced in the same order as in
the case of undo-tree.  The difference is in how these are mapped to
a tree.  To a large extent the difference is in "which node is taken to
be the root".  If you always take "the most recent state" as the root of the
tree (instead of the oldest), then both techniques are "stable" and
behave "identically".

> Toby, are there other reasons undo-tree needs to transfer undo
> elements from the buffer-undo-list to its own data model?

Toby's position is that the undo data should be kept as a tree, not as
a list.  That makes a lot of sense: For every branch in a tree, the
undo-list keeps 2 bundles (one going forward and the other going back),
but one of the two is always redundant, so the representation
is inefficient.  Of course, this inefficiency only applies to the
*branches*, i.e. only for those elements generated by `undo', so this is
irrelevant as long as most of the changes are not undos.


        Stefan