Module plugin_view 

CM.4 (2026-07-22): the *problems* view — the current error list grouped as editable source excerpts by file. Like narrow, a first-class built-in (no cargo feature gate): the entry list is static, so no async scan / service / per-view state. MV.1b — the generic provider behind every plugin-owned multibuffer view.

Design: plugin-multibuffer-views.md. Slice plan: slice-plans/plugin-multibuffer-views.md MV.1.

What is generic here, and what is the guest’s

One ProviderViewOpener is registered per view a guest declared, so AppEffect::OpenProviderView { provider, args } and the view’s gr both reach it by the guest’s own name. This module knows nothing about what the view is for: it calls build, resolves each excerpt’s path to a source document, creates or reuses the named buffer, activates the guest’s mode, and writes the guest’s summary into the headerline.

The guest owns the view’s identity (buffer-name), its contents and their order, its interactions (view-mode), and its status text. Before this, all four were host constants and only the agenda had them — which is why providers/agenda.rs is ~1000 lines and org’s second view had nowhere to go.

Why the paths are resolved here rather than crossed as buffer ids

Excerpt carries a BufferId and only the host can mint one. A guest naming a path is the same trade Effect::WriteToFile makes: a path is the stable name both sides already share, and the host resolves it.

One source document per path, however many excerpts point into it — otherwise a file with five rows is opened five times and an edit through one row is invisible through the others. That is providers/agenda.rs’s rule and the reason is identical.

Structs

PluginExcerpt

One excerpt a guest asked for, already across the boundary.

PluginViewResult

What a guest’s build produced.

PluginViewSpec

The identity a guest declared for one of its views.

Functions

decline_plugin_view

Report a guest decline on an already-seated view.

declined

Turn a guest decline into the generic outcome.

fill_plugin_view

Apply a guest’s build result to an already-seated view — the ASYNCHRONOUS half, called from the task that awaited the guest.

open_plugin_view

Create (or reuse) the view’s buffer and hand back its id — the SYNCHRONOUS half.