Trait ViewArgsResolver 

pub trait ViewArgsResolver:
    Send
    + Sync
    + Debug {
    // Required method
    fn view_args(&self, buffer: BufferId) -> Option<Vec<String>>;
}

What arguments a provider view is currently showing (slice OA.27).

A scan view is opened with arguments the host routes verbatim to the provider and then KEEPS, so they are the whole of what the view displays: which command, which span, which day, which filters. Whoever owns the view owns them, and that is the host — a provider that tried to remember them instead has nowhere consistent to do it (a WASM provider is several wasmtime::Stores with separate memory, so “remember them in the guest” means one copy per seam, silently diverging).

Abstract for ExcerptSourceResolver’s reason: the plugin host must answer this without depending on lattice-multibuffer, which sits above it. Whoever owns provider views implements this and wires it at boot; a host with none wired answers None, which is the honest degradation.

Required Methods

fn view_args(&self, buffer: BufferId) -> Option<Vec<String>>

The arguments the view in buffer is showing.

None when buffer is not a provider view, or is one the host holds no state for. Both are ordinary answers: a caller asks about the buffer a chord fired in, and a chord can fire anywhere.

Dyn Compatibility

This trait is dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors