Skip to main content

Module registry

Module registry 

Source
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§

InMemoryMultibufferRegistry
Default in-memory MultibufferRegistry implementation. One RwLock<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).
MultibufferExcerptSource
OA.23 — the ExcerptSourceResolver a multibuffer-aware host wires into the plugin host.

Traits§

MultibufferRegistry
Typed handle lookup for active multibuffer views, keyed by the view buffer’s BufferId. Registered as a service in ServiceRegistry at boot.

Functions§

view_owning_source
OA.23b: the view that owns source, across every registered view.

Type Aliases§

MultibufferRegistryHandle
Cheap-clone Arc’d alias matching the existing service-handle convention (BufferStoreHandle, LspSupervisorHandle, TerminalStoreHandle).