The canvas example did everything itself; now it runs the way the app
will. The key engine turns keys into commands, the focused view answers
with actions, and the commands every view shares (undo, marks, adding,
deleting, folds, tree moves, modes) answer the rest. A view can still
give a key its own meaning, since it gets the first say. `:` lines become
actions the same way (app::calls).
- View trait: kind, contexts (its key tables), layout, render, command
and mouse. layout comes before render because a view keeps the frame
it drew, to match clicks against, and follows the cursor with its
camera; drawing changes nothing. CanvasView owns the camera, the last
scene and the mouse drag; it reads the rest from a ViewContext.
- Edits travel as data (EditOp), so views never touch the document.
Buffer::apply is the one place a document changes: the edit, its undo
step, where the cursor goes, marks and `''`.
- Mode holds each mode's own state: move mode carries its Grab (whole
branch or not), the command line lives in Mode::Command.
- Undo groups: a whole move-mode session or mouse drag is one undo step,
built up as it goes. After an undo the cursor lands on a node the
change added or removed, before the others it touched.
- Actions run in order, and a problem stops the rest.
Small improvements on the way: zz centers the middle of the node, :find
says which match it's on, :unlink with no links says so, folding a node
without children says why nothing happened, and a captured idea is
placed next to a new Inbox even on the first :in.
The example has end-to-end tests now: they type key sequences and mouse
gestures into it on a test terminal, and `cargo test` runs them.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
skkeyeandClaude Opus 5.5
6eedbe0ce2