pub struct TransientContext {
pub major_mode: Option<String>,
pub minor_modes: Vec<String>,
pub buffer: Option<BufferId>,
pub args: Args,
}Expand description
Registry of named transient builders, populated at boot by each
owning mode crate (magit registers magit-dispatch /
magit-file-dispatch; per the module doc, which-key / command
palette / future plugin transients are meant to reuse the same
mechanism). Effect::OpenTransient { source } carries only the
name — resolving it to an actual TransientSpec (which can’t
cross into lattice-grammar’s Effect enum directly, since
TransientSpec lives downstream of it) happens here, at the
renderer’s effect-handling site. Mirrors PickerRegistry’s
named-source shape, simplified: transients have no candidate
generator or arg-schema concept, just a name and a builder.
Read-only after boot in practice (each owning crate’s install
populates it once), so this stays a plain mutex-guarded map
rather than an ArcSwap RCU registry like PickerRegistry —
there’s no runtime plugin-load use case for it yet.
MG.23h: where a transient was opened from, so a builder can vary
its rows.
A dispatch menu bound globally has to degrade: rows that act on the
thing under the cursor are meaningless in a buffer that has no such
thing, and a row whose only useful reading depends on which buffer
you are in should say the useful thing. Emacs magit answers both
with predicates on its prefix definitions — :if-derived for “any
buffer of this family” and :if-mode for “exactly this major” —
and this is the same question, asked of the two mode axes.
Major and minors are separate fields on purpose. A flat list of
active mode ids can only answer one of those two questions; magit’s
dispatch asks both of them about the same key (j is “jump to
section” in magit-status and “display status” everywhere else,
while its whole “Applying changes” group is gated on the looser
family test).
What is deliberately absent: the buffer id, the cursor, and the
selection. A builder produces rows; it does not act. The row’s
action receives its own ActionContext, which already carries the
underlying buffer, its cursor and any Visual region — resolved at
fire time, when they are current. Duplicating them here would be
speculative surface that could also go stale between build and fire.
Fields§
§major_mode: Option<String>The active major mode’s id, if the buffer has one. The
:if-mode question.
minor_modes: Vec<String>The active minor mode ids. The :if-derived question is asked
here: a magit buffer is one where magit-core-mode is active,
whatever its major happens to be.
buffer: Option<BufferId>MR.4: the buffer the menu was opened over.
A builder whose rows depend on something the buffer owns —
magit’s dispatch offers rebase --continue only while a rebase
is stopped, and which repository that is depends on the buffer —
cannot answer from the mode axes alone. None mid-boot, where
the builder degrades exactly as it does for the mode fields.
Still not the cursor or the selection: a row’s own action receives those at fire time, when they are current.
args: ArgsTR.3a: the arguments the open carried
(Effect::OpenTransient { args }).
The one field here that is not a fact about WHERE the menu was
opened — it is what it was opened FOR, and it is what lets a menu
drill down. Org’s capture menu has a row per template; the fields
menu that row opens reads the template key from here rather than
from guest memory, which <Esc> never clears.
Implementations§
Trait Implementations§
Source§impl Clone for TransientContext
impl Clone for TransientContext
Source§fn clone(&self) -> TransientContext
fn clone(&self) -> TransientContext
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more