Document Undo/Redo

[matthew-carroll]

Document Undo/Redo

Requirements

Time Travel

Undo/redo can operate in a transitive manner, clearing the history across user sessions, or it can operate in a permanent manner, persisting history across user sessions. The persistent history approach is known as "time travel", because a permanent history allows the document to be restored to any earlier state at will, like traveling through time.

Time travel has become a common feature in document editors. Super Editor should support time travel.

Extensions

Different editors may need to include different pieces of information in the history ledger.

An editor might choose to include the user's selection in the history, or not. A concurrent editing experience might include all users' selections, allowing for a video-game-style replay, or a concurrent editing experience might only track the primary user's selection.

An editor might convert pieces of text into different content, such as URLs into cards, tags into emojis, and editor macro commands into the result of the command, e.g., typing ":todo" to replace that block with a To-Do item.

Super Editor needs to ensure that clients can represent their arbitrary operations within the history ledger, just like standard document operations.

Transactions

Most editor operations will involve multiple changes. For example, any document edit will almost always coincide with a user selection change, such as moving the caret, or collapsing an expanded selection. These changes need to be batched together for two reasons:

1. Undoing the change needs to reverse both related actions.
2. The document change notification and the selection change notification need to emit after both the changes are applied. The document change notification can't emit before the selection change, because at that moment the document and selection are in an inconsistent state.

(Maybe) User attributions

A concurrent editor might need to attribute each change with the user that made the change. However, this attribution might be handled by the server, instead.

Implementation

History ledger

Our requirements dictate a persistent history, which means that Super Editor needs to include a serializable ledger.

** WORK IN PROGRESS**