Multi-document undo/redo timeline interleaving

An undo/redo engine that worked across every open document and every application surface in QuarkXPress. Any user action could be unwound and re-played — per-document edits in the obvious way, but also app-wide preference changes that cascaded into multiple open documents at once. The architecturally hard part: actions whose blast radius spanned multiple documents had to interleave correctly into each document's per-document timeline so undoing in any document carried the right slice of the global change.

Single-document undo is a textbook problem. Multi-document undo with shared application state is not. A "set hyphenation rules" change is not local to a document — it modifies an app-wide setting that every currently-open document immediately re-paginates against. Undoing that change has to either roll back the global state AND re-paginate every affected document, or it has to partially roll back if some documents have since moved on. The engine had to know, for every action, who its affected parties were, and how to compose its reverse with the actions that landed after it.

QuarkXPress lived in two state realms at once. The document realm held everything specific to a single open document — pages, text, boxes, style sheets local to that document. The application realm held everything shared — preferences, hyphenation rules, color profiles, font substitution policies, plug-in registry — settings that, when changed, took effect immediately in every currently- open document.

The engine modeled each realm with its own action stack. Each open document carried a per-document undo stack; the application carried a global app-state stack. The challenge was that some actions belonged to both realms — an app-wide preference change is one global action that produces a consequence in every document. The engine had to record one global action with N document-side consequences and route undo requests so the right slice of the change came back at the right moment.

User opens documents A, B, C. Edits boxes in each. Then changes the application-wide hyphenation rules. All three documents instantly re-paginate. User does more work in A and B, then closes C entirely. Now: user presses ⌘Z in A. What should happen?

The naïve answer is "undo the most recent action in A's stack" — which would unwind one of A's box edits. The naïve answer is wrong if the user's mental model is "undo the last thing I changed," because the most recent shared change was the hyphenation. The engine had to surface the hyphenation as an undoable action visible from any currently-open document — not just where it originated. Undoing the hyphenation change has to roll back the global state, then re-paginate every still-open document at its current state. Document C, having closed, does not get re-paginated; the engine drops its shadow when the document unmounts. If the user later re-opens C from disk, its on-disk version reflects its state at close-time — independent of the timeline. The engine must know what it can and cannot reach.

And then there's redo. The user now hits ⌘⇧Z. The hyphenation change has to come back, and every still-open document has to re-receive its shadow. The two action stacks (global, per-document) had to stay in sync without either being authoritative — every undoable was tagged with its scope, and the engine composed reverses across scopes when it had to.

Three primitives carried the weight:

Action records. Every user-visible change emitted a record carrying its forward effect, its reverse effect, and the set of document + application surfaces it touched. Records were immutable and value-typed; reversing produced a new record that the redo stack could re-apply.
Scope-tagged stacks. Each open document held its own undo and redo stack. The application held a global undo and redo stack. A record could appear in more than one stack — once on the global timeline as the canonical event, plus a shadow on each document timeline that sees it. All shadows pointed at the same underlying record.
Reachability awareness. When a document closed, its shadow links dropped from the global record's affected-set. When the user pressed undo, the engine asked: "is this record still consistent given the current set of open documents?" and either applied it normally or applied its partially-effective reverse. No silent corruption.

Two readings the engine carried that the rest of the industry didn't yet have widely. First, undo as a tree, not a line — branches from divergent edits were addressable, not collapsed into a single linear stream. Second, scope as a first-class property of an action — the question "what does this change affect?" was answered at the moment the action was recorded, not inferred at undo time. Both convictions show up later in the network's design — the graph as the substrate where scope is reachable through edges, and the contribution attribution arc as a tree of related actions, not a ledger of disconnected events.

The 2000 thesis ( Backtracking Model Languages ) made backtracking the architecture of execution: every BMA instruction had a forward and a reverse semantics. The Quark engine made the same conviction the architecture of user experience: every user-action had a forward and a reverse, with the reverse aware of its full cross-document blast radius. The Coherence Network now carries the same posture into commit verbs — tend / attune / compost / release — where unwinding without sediment is named directly, and git's tree of commits is the timeline that the QuarkXPress engine carried per-document, scaled out across cells.

Quark Multi-Document Undo/Redo Engine

Two realms of state, one timeline per scope

The architectural shape that emerged