lattice_multibuffer/events.rs
1//! Crate-level multibuffer events.
2//!
3//! ## Why this module exists (PV.1, 2026-08-12)
4//!
5//! [`MultibufferExcerptsReady`] was declared inside
6//! `providers::search`, which is behind the `search` cargo feature —
7//! and so was `install`'s `wake_on_event` registration for it. That
8//! made a **generic** signal ("this view's excerpts changed, repaint
9//! without waiting for a keypress") conditional on one provider being
10//! compiled in: a `--no-default-features` build, or any provider living
11//! outside this crate, had no wake at all and would show the
12//! blank-results-until-keypress symptom the event was added to fix.
13//!
14//! The event is about a multibuffer view, not about searching, so it
15//! belongs at the crate root with an unconditional wake. Providers in
16//! *other* crates (magit's project-diff is the first) publish it the
17//! same way `providers::search` does.
18
19use lattice_core::BufferId;
20
21/// Published by any provider after appending / replacing a view's
22/// excerpts, so the cells worker rebuilds the display matrix
23/// off-keystroke.
24///
25/// The subscriber is the boot-registered wake
26/// (`install`'s `wake_on_event::<MultibufferExcerptsReady>()`), which
27/// fires `async_landed` — the primitive that makes async results reach
28/// the screen without a keypress. A provider that appends excerpts and
29/// does NOT publish this will appear to work in tests that press a key
30/// first, and appear broken in use.
31#[derive(Debug, Clone)]
32pub struct MultibufferExcerptsReady {
33 pub view: BufferId,
34}
35
36lattice_protocol::register_event!(
37 MultibufferExcerptsReady,
38 "multibuffer.excerpts-ready",
39 "New excerpts appended to a multibuffer view.",
40 "lattice-multibuffer",
41);