Skip to main content

Module provider_view

Module provider_view 

Source
Expand description

The provider-view seam — one generic host primitive for “open the multibuffer view a provider owns” (PV.1, 2026-08-12).

Design: docs/dev/architecture/multibuffer-views.md §3.7a. First consumer: lattice-magit’s project-diff view (PD.3).

§The problem it solves

A multibuffer view can only be created through ModeActivator, which is &mut-backed and therefore reachable only from the host. A provider’s trigger — an ex-command or a chord-fired action handler — runs against &self state and returns an Effect. So every provider needs some effect that carries “open my view” back to a place holding the activator.

Before this seam each provider spent its own AppEffect variant on that, plus a match arm in the host’s dispatcher and a third arm at the plugin boundary: three crates touched for the N+1th provider, which contradicts the acid test a provider crate is supposed to pass (multibuffer-views.md: a new provider crate should require zero host additions).

This registry replaces the per-provider variant with a single AppEffect::OpenProviderView { provider, args }. Provider crates register an opener under a name at boot; the host arm looks the name up, calls the opener with itself as the activator, and applies the generic outcome (activate + echo). Adding a provider now touches exactly one crate — the provider’s own.

§What deliberately does NOT go through it

:narrow / zn also produce a multibuffer, and they stay on their typed AppEffect::{NarrowTrigger,NarrowLines} variants. They are not the same operation: narrowing resolves a range against live editor state — cursor, last-Visual extent, the mark table, and the composed→source one-hop translation — none of which is a provider parameter. Routing it here would mean exporting marks and visual state through ModeActivator, polluting a generic trait with one consumer’s surface, which is the rejection multibuffer-views.md §3.6 already made against Document::excerpts().

Structs§

ProviderViewRefreshRequested
“re-open the view I own, with these arguments” — asked for from somewhere that holds no activator and returns no Effect (OA.15a).
ProviderViewRegistry
Name → opener, registered at boot and read once per trigger.

Enums§

ProviderViewOutcome
What an opener did, in terms the host can apply generically.

Type Aliases§

ProviderViewOpener
A provider’s view-opening closure.
ProviderViewRegistryHandle
Typed handle for ServiceRegistry lookup.