Type Alias PickerSourceSpec 

pub type PickerSourceSpec = PickerSourceSpec;

Aliased Type

pub struct PickerSourceSpec {
    pub id: String,
    pub doc: String,
    pub args_schema: Vec<ArgSpec>,
    pub args_hint: String,
    pub live: bool,
    pub create_label: Option<String>,
    pub rooted: bool,
    pub delete_command: Option<String>,
}

Fields

id: String

doc: String

args_schema: Vec<ArgSpec>

args_hint: String

live: bool

create_label: Option<String>

OR.5: when set, the picker offers one synthetic create row whenever the query is non-empty — the offer to make the thing the user was looking for and did not find. %s in the label is replaced by the query.

Two things about the row are load-bearing and neither is obvious. It appears whenever the query is non-empty, NOT only when nothing matches: offering it only on zero matches makes it impossible to create Rust while Rust Async exists, which is precisely when you most want to. And it is pinned last and never ranked, because a create row that could sort above a real match would let <CR> produce a duplicate through ranking noise — destructive rather than merely wrong.

Accepting it hands routing-payload::create(query) to this source’s accept, which decides what creation means. none — every source but roam’s — behaves exactly as before.

rooted: bool

PP.2: these results are scoped to a project / workspace root, so the picker prompt names the root it is operating on (files ~/src/lattice> ).

A DECLARATION, not an inference. The host resolves a root for every picker open — picker-context.workspace-root is always filled — so it could show one everywhere, and a path on a list that spans every open project is noise on the one line the user reads to know what they are looking at. Only the source knows whether the root is part of what its list MEANS.

Set it when the answer to “would these results be different in another project?” is yes. false is the answer for a list that is global, buffer-local, or registry-wide — and for a source whose QUERY already names a path, where a root beside it would be a second and staler answer to the same question.

delete_command: Option<String>

PD.1: <C-d> — the ex-command that REMOVES the selected row from whatever backs this list, invoked with that row’s routing argument. none leaves <C-d> doing nothing.

The SOURCE owns the verb and the host owns only the key. <C-s> / <C-v> / <C-t> are host concerns — it knows how to open a thing in a split without asking. Deletion is not: only the source knows that removing a row from a project list means forgetting a root. Naming a command is how a source says so, and it is the same routing its rows already take, so declaring this needs no new seam and no new capability.

Not destructive to the filesystem, and must not be. A project list forgets a path; deleting a directory is oil’s job and the file tree’s. A source whose delete verb touched disk would make <C-d> mean two very different things depending on which picker had focus.