editor-concepts

Undo/Redo & History

Every change in Lega — manual or AI-generated — lives in one exact, reversible command history. Here's how the non-destructive editing model works and why it matters.

Undo is the feature nobody notices until the moment they desperately need it — and it's also one of the clearest signals of whether a tool's underlying state model is actually sound. In Lega, undo and redo aren't a bolted-on convenience layered over the editor; they're a direct consequence of how the editor represents change in the first place.

Everything is a command, so everything is undoable

Under the hood, every action you take in Lega — moving a layer, retyping text, adjusting a fill color, resizing a frame, applying an AI-generated layout — is executed as a discrete command. Each command knows exactly how to apply itself and exactly how to reverse itself. History, in Lega, is simply the ordered list of commands that produced the current state of your document.

This has a consequence that's easy to take for granted until you compare it to tools that don't work this way: undo in Lega is exact. It's not a coarse "revert to last saved state" or a snapshot-based approximation that sometimes loses small changes or duplicates layers. Undoing a command puts you back in precisely the state you were in before that command ran, every time.

Because AI generation runs through the exact same command system as manual edits — see the Legon Editor Overview for how that architecture is put together — there's no separate, weaker undo path for AI actions. If the AI regenerates a layout and it's not what you wanted, one undo removes exactly that generation and nothing else, the same as undoing a manual drag.

Why this matters more for an AI-first tool

In a tool where a human draws every element by hand, undo mostly protects against small mistakes — a bad drag, an accidental delete. In a tool where a single action can generate dozens of layers at once, undo does something more important: it makes experimentation safe.

If you're not confident that a big AI action can be cleanly reversed, you hesitate to try it — you second-guess before regenerating a frame, or you manually duplicate your work first "just in case." Lega's exact command history removes that hesitation. Generate a new layout, don't like it, undo — you're back exactly where you started, with nothing orphaned or partially applied. That confidence is what makes it reasonable to treat AI generation as a fast first draft you can freely throw away, rather than a commitment you have to think twice about. We've written more about why this distinction matters specifically in AI-driven tools in Why Undo History Matters More in AI Design Tools.

Non-destructive by default

"Non-destructive editing" gets used loosely, but in Lega it has a concrete meaning: nothing you do is a one-way door within a session. Deleting a layer, replacing an image, regenerating a style — all of it is a command, and all of it can be walked back. You don't need to manually duplicate a frame before trying something risky; the history is the safety net.

This is also why undo composes correctly with everything else in the editor. Multi-select an operation across several layers, and undo reverses the whole operation as one step, not layer by layer in a confusing partial state. Redo moves forward through the same exact sequence if you change your mind again after undoing.

Using it day to day

The standard undo/redo keyboard shortcuts work throughout the editor, and there are also dedicated undo/redo controls in the toolbar if you'd rather click than reach for the keyboard. For the full shortcut reference — undo/redo alongside selection, tool switching, and zoom shortcuts — see Keyboard Shortcuts.

A practical habit worth building: don't be precious about trying things. If you're unsure whether a big edit or an AI regeneration is going to work out, do it anyway and look. The history model means "try it and undo if it's wrong" is always cheaper than second-guessing yourself in advance.

For the architectural reasoning behind why this model was chosen — and how it connects to the plugin-based structure of the rest of the editor — see the Legon Editor Overview.