Module scan_view 

OM.A1 (2026-08-25): the *agenda* view — every dated row that plugin scanned-excerpt-source producers find under the project root, globally ordered and date-grouped, as editable source excerpts. Feature-gated like search because it pulls the ignore walker. OM.A1 (2026-08-25): the agenda provider — a date-grouped multibuffer of rows contributed by plugin scanned-excerpt-source producers.

Design: org-mode.md §6. Slice plan: slice-plans/org-mode.md OM.A1–A3.

Nothing here knows what an org file is

That is the point. The provider walks the project, asks the ScannedExcerptSourceRegistry which sources claim each file’s extension, and hands the matching ones its text. Which extensions those are, what a headline is, what SCHEDULED: means, how a date sorts — all of it lives in the guest. The host contributes the walk, the ordering primitive, and the multibuffer.

Why a multibuffer and not a rendered list

An agenda row IS an excerpt: Excerpt { source, start_line, end_line, header } (§6.1). Taking that seriously buys jump-to-source, edit-propagates-to-source, headerline status and refresh from machinery that already ships. The second of those is the one that decided it — org’s agenda is a place you change TODO states from, and an agenda you can only read is a lesser feature wearing the name.

Why the whole scan finishes before anything is appended

Unlike providers::search, the agenda’s row order is global: a row from the last file scanned may belong at the top. So the scan collects, stable-sorts on the guest’s sort_key, and appends once. Progress is not lost — it moves to the headerline, which reports files scanned as the walk runs (§6.2). Appending per file and re-sorting per batch was rejected: rewriting every row on each batch is a whole-viewport restyle, which the UX rules veto outright.

Structs

InMemoryScanViewService

RowAnnotationAt

HB.5: one annotation, and the composed row it hangs below.

RowAnnotationProvider

HB.5: renders a scan’s per-row annotations as virtual rows below their rows.

ScanViewArgs

OA.27 — [lattice_core::ViewArgsResolver] over the per-view scan state.

ScanViewIdentity

Open (or re-drive) the agenda view.

ScanViewMode

agenda-view-mode — the minor the provider activates on the agenda view.

ScanViewOptions

What a scan walks.

ScanViewState

Per-view scan state. OM.A3’s gr reads the root back out of this so a refresh re-scans what the view already shows rather than resetting to the current working directory.

Constants

REFRESH_ACTION

The refresh body this view declares. Named, not anonymous, because refresh_action returns a target and the handler below must supply it — declaring one without the other is the gap magit-project-diff shipped with and PD.9 had to come back for.

Traits

ScanViewService

Per-view state, shared between the trigger and the scan task.

Functions

open_scan_view

MV.3: the agenda’s opener, with its identity as a parameter.

register_scan_view_actions

Register action:agenda-refresh so the mode’s refresh_action target resolves. The body lives on the mode; this is the registry entry the host looks the name up in.

register_scan_view_mode

Register the view’s minor mode.

register_scan_view_service

Register the per-view state service.

row_annotation_provider_id

The ProviderId a view’s annotations register under.

spawn_scan_view_scan

Run the scan off-thread and populate view.

Type Aliases

ScanViewServiceHandle

Register and look up with this exact alias (the ServiceRegistry TypeId rule).