Expand description
M.2.b.2 (2026-06-01): typed handle lookup for multibuffer views.
BufferStore::handle_for(id) returns Arc<dyn Document> (the
kind-agnostic dispatch surface). Providers that need to call
typed methods on the multibuffer handle (append_excerpts,
replace_excerpts, set_headerline once M.4 lands) reach the
concrete Arc<MultibufferDocumentHandle> through this
registry — keeps Document clean (no Any / downcast
contamination) and isolates the multibuffer-specific lookup to
this crate.
Same precedent shape as lattice_terminal::TerminalStoreHandle.
Cleanup runs through a DocumentClosed typed-event subscriber
wired in crate::mode::register_multibuffer_modes; when a
multibuffer view’s underlying buffer closes, the registry
entry is removed.
Structs§
- InMemory
Multibuffer Registry - Default in-memory
MultibufferRegistryimplementation. OneRwLock<HashMap>indexed by view BufferId. Lookups take the read lock (no contention with parallel readers); insert / remove take the write lock (rare paths — view creation + view close). - Multibuffer
Excerpt Source - OA.23 — the
ExcerptSourceResolvera multibuffer-aware host wires into the plugin host.
Traits§
- Multibuffer
Registry - Typed handle lookup for active multibuffer views, keyed by
the view buffer’s
BufferId. Registered as a service inServiceRegistryat boot.
Functions§
- view_
owning_ source - OA.23b: the view that owns
source, across every registered view.
Type Aliases§
- Multibuffer
Registry Handle - Cheap-clone Arc’d alias matching the existing service-handle
convention (
BufferStoreHandle,LspSupervisorHandle,TerminalStoreHandle).