3 ms·
In this methodology, without exposing the tree, how does the user select between the two branches created after the butterfly is squashed? It seems like Google
by ec109685 4y ago
In this methodology, without exposing the tree, how does the user select between the two branches created after the butterfly is squashed?
It seems like Google Docs does it in an intuitive way where undo / redo works normally, but there’s another time ordered history of the document to select from.
Is this what the author’s approach is advocating?
- zwkrt 4y agoIn the author’s algorithm there is no two branches. The following diagram is an undo tree where we made change B, went back to A, then made C C ——— now / —— A \ B But time doesn’t branch, so our history shouldn’t /have to/ branch. What if our undo was itself part of the linear history? Then we could build up the history like this: A A —— B A —— B —- undo_B A —— B —— undo_B —— C For complex undo/redo scenarios this could get out of hand. A — B — undo_B — C — undo_C — undo_undo_B —undo_B — undo_A… But the author (I think correctly) states that for the average user this behavior is intuitive and desired. They also added the optimization that undoing and then redoing a set of changes doesn’t make it into the history, as it’s basically a no-op.
- kdmccormick 4y agoNope, the author's solution is to consider the original undo (the "time travelling") to be an undo-able change in itself. No branching history. So you end up with: state 1 * change A state 2 * change B state 3 * undo B state 2 * change C (the "butterfly squashing") state 3a * undo C state 2 * undo <undo B> state 3 (!) * undo B state 2 * undo A state 1 The traditional editor would differ by putting you right at state 1 at (!), blocking your access to state 3.