Module buffers 

Buffer-kind discriminator for the multi-buffer foundation (DESIGN.md §5.9).

Phase 1 wiring: every concrete buffer type the App can hold a cursor in (today: a code Document and an optional HelpBuffer) is tagged with a BufferKind. The App carries one active_buffer: BufferKind which decides where keystrokes land – a j in Normal mode resolves the same line_down motion against the active buffer, regardless of kind.

BufferId is a stable, monotonically-allocated handle. v1 only has at most one buffer per kind, but the id scaffolding lands now so position-history entries (§5.1.1) can identify “which buffer” once Phase B.1.c spawns multiple Document buffers.

Structs

BufferFlags

Vim-style per-buffer flags (DESIGN.md §5.9). The shape is fixed now so additions don’t churn every call site; v1 ships with listed populated (:bn / :bp / :ls skip unlisted buffers once the wiring lands) and hidden reserved for “keep loaded without a window” semantics. Both default to “normal buffer” (listed = true, hidden = false).

BufferId

Stable monotonic handle identifying one buffer instance. Two buffers with the same BufferKind still have distinct ids. The App allocates these via BufferId::next at buffer- creation time and stores them on each buffer + on every position-history entry.

Enums

BufferKind

Which kind of buffer the App’s input pipeline currently routes to. The chord grammar, motions, and position history are shared; kind only matters at a few discrete decision points: which cursor a motion mutates, whether mutating actions are accepted (most non-document kinds are read-only), and which buffer-local bindings apply (Help binds <CR> to follow-link, FileTree binds <CR> to follow-entry, etc.).