>> I'm not sure why you say they're largely incompatible.
> Maybe I overstated it. I meant that treating undos as new changes
> that can themselves be undone is conceptually very different to
> treating undos and redos as a way of navigating around a history of
> buffer states.
Just think of the undo command as a traversal in a tree. Imagine it is
called "undo-retrace" instead of "undo", then the two models don't
seem so incompatible. buffer-undo-list is just a kind of event log of
buffer changes. Together with the undo-(equiv|redo)-table it conveys
sufficient information to construct a tree.
The usefulness of integrating something like undo-tree is in
visualizing the tree and providing commands to more capably and
intuitively traverse it (eg choosing exactly which branch to descend).
>>> From memory (and git logs), I think that without this mechanism
>>> undo-tree used to sometimes resurrect dead markers when undoing. A
>>> lisp package might delete a marker from a buffer and drop all
>>> references to it, expecting it to be garbage collected. But
>>> because it was referenced from buffer-undo-tree (a strong
>>> reference, rather than the specialized buffer-undo-list weak
>>> reference), the marker never got GCd. Undoing a changeset
>>> containing the deleted marker would then restore the marker. I
>>> remember this created all kinds of havoc with overlays.
>> Sounds like bug 16818, which affected the builtin undo system too.
>> It is fixed in the upcoming Emacs 24.4.
> I'm not sure. I remember it affected normal undo-tree undo, not
> undo-in-region (which I hadn't even implemented at the time).
The bug isn't specific to undo in region. It merely lent itself to
demonstrating the bug, because the mark and region overlay markers are
necessarily in the region, and so are swept up into marker
adjustments. They also remain eq over time whilst mutating to point to
various locations.
The problem was that primitive-undo applied marker adjustments without
concern for whether they moved to unrelated locations. Maybe this
somehow contributed to the overlay havoc you had seen.
The vast majority of Elisp packages shouldn't care whether GC is going
to happen sooner or later. So if you think the early removal of marker
adjustments via compact_undo_list is essential to correct functioning,
I would wonder why a package depends on that.
Instead, I suspect compact_undo_list is just an optimization. The
asymptotic performance of low level editing functions depends on how
many markers there are in the buffer. If it's common for markers to
become unreachable (except via buffer-undo-list) while still pointing
into a buffer, then compact_undo_list will remove them. This means
that theoretically the performance of editing functions is not a
function of undo-limit.
If I'm right, then the only bad symptom in undo-tree would be a
possible performance degradation.
>> undo-tree may require an analagous change, since it doesn't use
>> undo-make-selective-list.
> Thanks. Either that function didn't exist when I wrote the
> undo-in-region support, or I overlooked it. It ought to simplify
> undo-tree's undo-in-region implementation a little. Currently it
> constructs the region changeset manually using undo-elt-in-region.
There have been a few changes in that area, eg under bug 17235, and
there will be more under bug 16411.