Undo/Redo Stack Pair¶
Reversible history model — instantiates LIFO Stack Discipline
Keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time.
The Undo/Redo Stack Pair treats each completed user action as a reversible frame and keeps two stacks to move through history. Every action the user commits is pushed, as a self-describing record, onto the undo stack. Pressing undo pops the top of that stack, applies its inverse, and pushes the record onto the redo stack; pressing redo does the reverse. Its defining feature — the one that separates it from a transaction's rollback — is the pair: undone work is not discarded but parked on the second stack, so the user can walk backward and forward through already-committed actions freely, one step at a time. Each frame carries enough state to both reverse and reapply itself, which is what makes the motion two-directional.
Example¶
A designer is building a poster in a vector illustration tool. She draws a rectangle (push "add rectangle"), fills it blue (push "set fill blue"), then rotates it 15° (push "rotate 15°"). The undo stack now reads, top to bottom: rotate, fill, add. She decides the rotation was wrong and hits undo: the tool pops "rotate 15°", applies its inverse (rotate −15°), and moves that record onto the redo stack. The rectangle snaps back to square. She undoes again — the fill is popped and the blue reverts to default, and now "set fill blue" sits on the redo stack above "rotate".
Then she reconsiders: the rotation was actually fine. She presses redo, and "rotate 15°" is replayed from the redo stack and pushed back onto undo. The two stacks let her scrub back and forth over her own history without losing anything — until she makes a new edit. The instant she nudges the rectangle by hand, the redo stack is cleared: history has forked, and the previously-undone actions are no longer reachable.
How it works¶
The pair is coordinated by a small set of rules:
- On a new action: execute it, push a record onto the undo stack, and clear the redo stack — a fresh edit invalidates any forward history.
- Each record is a reversible frame: it stores enough to both
undo(apply the inverse) andredo(reapply). Some tools store an inverse operation; others store a before/after snapshot of the affected state. - On undo: pop the undo stack, apply the inverse, push the record to the redo stack.
- On redo: pop the redo stack, reapply, push back to the undo stack.
- Peek for the menu: the top of each stack names the next reversible step, which the UI surfaces as "Undo Rotate" / "Redo Rotate."
Tuning parameters¶
- History depth — how many actions the undo stack retains before the oldest is dropped. Deeper history is more forgiving but costs memory, especially with snapshot-based records.
- Action granularity / coalescing — whether each keystroke is its own frame or runs are merged into one ("typed a word"). Coarser frames make undo feel natural; too coarse and users can't undo precisely.
- Record strategy — inverse-operation (compact, but every action needs a correct inverse) versus state-snapshot (simple and general, but heavy). The choice trades memory against the effort of defining inverses.
- Branching vs. linear — clear the redo stack on a new edit (simple, standard) or keep alternate branches as a tree (powerful, but the UI to navigate branches is hard).
When it helps, and when it misleads¶
Its strength is fearless exploration: because every action is reversible and undone actions are preserved for redo, users can experiment freely and step precisely back and forth through their own history.[n1] It turns a committed edit into something provisional after the fact.
Its failure mode is that undo can only reverse what was captured as a reversible frame. Side effects that escaped the model — a file already written to disk, an email already sent, a random seed consumed — cannot be pulled back by popping a stack, so undo silently restores the visible document while the world has moved on. The classic misuse is trusting undo as a safety net for irreversible operations. A subtler trap is a buggy inverse that doesn't exactly reconstruct the prior state, so deep undo chains drift. The guarding discipline is to keep the undo model authoritative over all state that actions touch, gate genuinely irreversible operations behind explicit confirmation instead of relying on undo, and test that undo-then-redo round-trips to an identical state.
How it implements the components¶
push_admission_rule— every committed action is admitted to the undo stack as a new top frame (and clears the redo stack).pop_or_unwind_rule— undo pops the most-recent action and reverses it; the newest change is always the first to be undone.frame_payload_and_local_state— each frame carries the reversible action's payload (its inverse or a before/after snapshot), enough to both undo and redo it.peek_or_inspection_rule— peeking the top of each stack drives the "Undo X / Redo Y" menu labels without mutating history.
It does not implement exception_unwind_policy or frame_boundary as transactional markers — bracketing an in-flight unit of work and rolling it back to a savepoint is Transaction Savepoint Stack, its nearest twin (a savepoint rollback discards uncommitted state and cannot be redone, whereas an undo reverses a committed action and can). It also does not implement top_frame_authority as a live navigation position — tracking which nested view you are in is Breadcrumb Navigation Stack (which records *where you are, not what you did).*
Related¶
- Instantiates: LIFO Stack Discipline — reversible edit history is the archetype applied to user actions.
- Consumes: Push/Pop Interface — the pair is two LIFO stacks of action records.
- Sibling mechanisms: Call Stack and Activation Records · Push/Pop Interface · Parser Delimiter Stack · Resource Acquisition/Release Stack · Transaction Savepoint Stack · Breadcrumb Navigation Stack · Depth Limit and Stack Trace
Editorial Notes¶
Form Classification¶
Form family: Structure, Architecture & Configuration
Rationale: Undo/Redo Stack Pair operates as a configured physical, technical, or logical arrangement whose structure creates the effect because it keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time.
Independent corroboration: The frozen evidence defines Undo/Redo Stack Pair as 'Keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time', so its operative form is Structure, Architecture & Configuration.
Nearest alternative: Record, Log & Register — Undo/Redo Stack Pair includes features of a persistent ledger, log, register, or case record that preserves history and traceability, but its defining operation is a configured physical, technical, or logical arrangement whose structure creates the effect.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Universal
Rationale: Vitek and Jagannathan, A Formalization of Undo and Redo documents that the primary computer-science treatment formalizes undo and redo as state-transforming operations with histories. This is direct, mechanism-specific evidence for computer science as the best-evidenced historical home of the operation—Keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time.—rather than evidence merely that the operation is useful there. The retained alternates record genuine adjacent lineages; later portability is represented separately by domain_reach=universal.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping….
- Human-Computer Interaction — Human-computer interaction and interface design supplies a parallel or contributing lineage for the mechanism's defining operation: keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping….
- Organizational & Management Science — Organizational Management supplies a historically relevant adjacent lineage or formative practice for the operation—Keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time.—but the adjudicated evidence more directly locates the defining lineage in computer science.
- Systems Thinking & Cybernetics — Systems science's feedback, boundaries, control, and regulation tradition contributes a separate formative lineage to the mechanism's undo redo stack pair logic.
Review resolution: The blind reviewers disagree on primary lineage (organizational_management versus computer_science). The defining operation is: Keeps two stacks — one of completed actions, one of undone ones — so each undo pops the most recent action and reverses it onto the redo stack, and each redo replays it, stepping through edit history one action at a time. The researched Vitek and Jagannathan, A Formalization of Undo and Redo establishes that the primary computer-science treatment formalizes undo and redo as state-transforming operations with histories. That source therefore supports computer science as the historical origin. organizational management remains in the uncapped alternates where it contributes a formative practice, but application or governance is not itself proof of origin. origin_mode=single_lineage records lineage construction; domain_reach=universal separately records later applicability.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] The Command pattern encapsulates an action as an object carrying both its execution and its inverse, which is the standard way to build undo/redo: a history of command objects that can be reversed and replayed. It is the design that makes "each action is a reversible frame" concrete. ↩