Undo and Redo

An editor without undo is a threat, not a tool. Two classic designs:

• Snapshots (the memento pattern): before each change, save the whole buffer; undo = restore. Trivially correct — undo can never disagree with what happened, because it is what happened — and memory-hungry in proportion to buffer size, not edit size. For source-file-sized buffers, honestly fine, and the final challenge uses it for exactly that reason.
• Inverse operations (the command pattern): record each edit as a small object that knows how to reverse itself. An insert's inverse is "erase those characters"; an erase's inverse is "put this text back" — note that the erase record must therefore carry the erased text; the operation alone isn't invertible without it. Memory scales with the edits, which is why every serious editor lives here. The cost is a new invariant to defend: the records must replay against exactly the document states they were recorded against, in exactly reverse order. One position off and undo corrupts the file it was supposed to protect.

This lesson builds the second kind. Two stacks: undo holds done things; redo holds undone things. undo pops, reverses, pushes to redo. redo pops, re-applies, pushes back. And the rule everyone knows from using editors without knowing they know it: a fresh edit clears the redo stack — history is a line, not a tree, and editing after an undo abandons the future you undid. (vim actually keeps the abandoned branches — :help undo-tree — one of its deepest features, built on exactly the representation you're about to write.)

Granularity: coalescing

The subtle design decision is not how to undo but how much. Type hello — five insert operations. Should undo peel back o, then l, then l...? Every real editor says no: one undo removes the word. vi's rule is that the whole insert-mode session — from i to Esc — is one undo unit. The mechanism is coalescing: when a new insert arrives, check whether it extends the unit on top of the undo stack, and if so, merge instead of push. Extends means:

• the top unit is an insert (you can't merge typing into a deletion),
• nothing has broken the run since (leaving insert mode calls break_run() — that's the i-to-Esc boundary made explicit; cursor motions in a real editor would too),
• the new text lands exactly at the end of the top unit's text (pos == top.pos + top.text.size() — type in the middle of a word after moving the cursor and positions won't line up, correctly forcing a new unit),
• and the new text isn't a newline — we cut units at line breaks, so undoing a paragraph of typing goes line by line rather than vaporizing all of it. (vim keeps whole sessions; our dialect is line-grained. Both are defensible; ours makes the tests nicer and the behavior less destructive.)

Deletions could coalesce too (backspace-backspace-backspace as one unit — note the positions decrease), but that's symmetric bookkeeping you can add later; here, each erase is its own unit.

The document in this challenge is a plain std::string with byte positions — undo logic is completely independent of the 2-D row/column structure, and testing it in 1-D removes every distraction. In your editor, the same class runs against the flattened buffer, or against Pos-keyed edits; the algebra is identical.