Expand description
Picker source registry (metadata layer).
Each picker source — files, recent, lines, marks,
lsp-references, … — registers a PickerSourceSpec
into a PickerRegistry at boot. The registry powers
three things:
:picker <Tab>completion. The cmdline source-id completion mode iterates the registry and surfaces every registered source as a candidate.- Source-arg completion. Once the source id is resolved,
arg-2+ completion consults the source’s
[
ArgSpec::completion] hooks — samegen:*completion sources every other ex-command uses. :describe-pickerintrospection. Walks the registry to render:describe-picker(and:describe-picker <id>for per-source detail).
The registry only holds metadata at this stage. The
PickerSourceGenerator trait (slice 4 in
docs/dev/architecture/picker.md) elevates the registry to
hold generator trait objects so source dispatch is registry-
driven end-to-end. Today the App still owns the
source_id → method dispatch table; the registry just
supplies the names + arg schemas the grammar needs.
§WIT mirror (Phase 7)
When the plugin host lands, WIT-imported sources register
their spec record into the same PickerRegistry. Plugin
sources are indistinguishable from first-party at the
registry level — both appear under :picker <Tab> and
flow through the same dispatch.
The registry interface is therefore deliberately small:
register, get, iter. Nothing host-specific leaks in.
Structs§
- Picker
Registry - Registry of every picker source the
:picker <id>ex-command can dispatch to. Populated at boot by each feature crate’sregister_picker_sourcesentry point. - Picker
Source Spec - Static metadata describing one picker source.
- Registry
Entry - Registry entry: either metadata-only (slice 12 path, retained for tab-completion of source ids whose generator isn’t yet wired) or metadata + generator (the canonical slice 13 path – dispatch resolves the generator from here).
Enums§
- Picker
Init Result - Three init shapes covering every Phase 4-8 picker
pattern. The choice is per-invocation – a single source
can return different shapes depending on args (e.g. a
future grep source could
Inlinean empty result on empty pattern,Streamotherwise).
Traits§
- Picker
Source Generator - Source generators implement this trait. Registered into
PickerRegistryat boot; the:picker <source>dispatcher looks up byspec().idand callsinitto obtain candidates, thenacceptto translate the user’s chosen routing payload into a typed outcome.
Type Aliases§
- Accept
Future - One-shot async future a source returns from
accept_asyncwhen translating the chosen routing payload requires off-thread work — the motivating case is a WASM plugin source whoseacceptis an async guest call bound to its actor task (lattice-plugin-host). Same'static + Sendcontract asCandidateFuture: the source extracts everything it needs (the projected context, the routing token) during the synchronousaccept_asyncprelude and moves it into the closure. - Candidate
Batch - One batch of
(candidate, routing payload)pairs from a source. Identical shape across all three init flavors; the host’s seat / append paths use it uniformly. - Candidate
Future - One-shot async future a source returns when the
candidate set requires off-thread work (LSP request,
large directory walk, etc.).
'static + Sendbecause the source extracted everything it needs from the context during the synchronousinitcall and moved it into the closure. - Candidate
Stream - Streaming source channel. Sources spawn a producer task
during
initand return the receiver; the host pumps each batch into the picker incrementally so the popup updates as results arrive (live-grep, future live-LSP-completion). - Picker
Registry Handle - The runtime-mutable registry handle the editor holds and shares as a service.
ArcSwapgives wait-free reads on the picker-open path and copy-on-write RCU writes for runtime plugin-source registration (:plugin-load/ boot-discovery): clone the current registry,register_generator/unregister, thenstorethe new snapshot. The plugin loader (lattice-plugin-loader) reaches this viaservice::<PickerRegistryHandle>()and RCU-registers each loaded picker plugin’sWasmPickerSource. - Source
Result - Source-side fallible result. Errors are user-facing
strings the host echoes verbatim. Wrapping in
Result<...,String>rather than a typed error keeps the WIT mirror (Phase 7) trivial – plugin-emitted errors cross the boundary as strings.