bug#16411: undo-only bugs

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

>> I guess I do have some idea how to do it, but it looks like a lot of
>> work, since we have to adjust the positions in the rest of
>> pending-undo-list.
> Are you saying the buffer positions in the undo data become
> invalidated?  That could indeed be a detail I missed.  Let me take a
> closer look.

Not exactly invalidated, but we can't just skip an undo-record without
adjusting the subsequent records.

We can skip a bunch of undo-record specified via undo-equiv-table
because that table stores pairs of undo states that correspond
to the exact same buffer, so the "adjustment" is a no-op.

>> Right: the loop that undoes N steps (either in undo-more or in undo
>> if we change undo to only call undo-more with a 1) needs not only to
>> use undo-equiv-table at each iteration to skip redo entries, but it
>> also needs to add an entry in undo-equiv-table at each iteration.
> And recall that these N are rolled into one redo record.

Not sure what you mean here.

> So a redo record needs to reference N records it undid.

I'm even more confused.

> Actually, this makes me realize the solution to bug 1 is inadequate.
> Calling (undo-primitive 1) N times creates N redo records whereas
> (undo-primitive N) creates one.

No, primitive-undo does not add any undo boundary.


        Stefan