Skip to main content

Module install

lattice_diff

Module install 

Source
Expand description

BC.6 / DX.7 / CR.6: the crate-owned install(boot) entry point.

The diff subsystem registers its own modes + commands through the generic [SubsystemBoot] surface, collapsing the host wiring into one Phase-B line (lattice_diff::install(&mut boot)) — the terminal / claude-code / multibuffer shape.

CR.6 (2026-06-24): the diff subsystem registers its own commands. Every diff action (action:diff-*, action:hunk-*) and ex-command (ex:diff* / ex:hunk-* / ex:describe-diff) is declared here via boot.commands_mut() — the “modes register commands” pattern (multibuffer precedent). The command declarations are mode-owned; the command bodies split two ways by what they need:

  • mode-owned bodies — the do/dp, conflict (d2o…dB), and hunk-nav (]c/[c) chords resolve through the modes’ action_handlers() (the ActionHandlerRegistry is consulted before the CommandSpec), which read the DiffSubsystemHandle service and return an Effect. The action specs here are pure shells.
  • host Effect appliers — the ex-command apply closures parse args and return a host-boundary Effect (DiffOpen, Diffsplit, DiffGetCmd, …) that the host’s handle_effect applies. The lifecycle appliers (do_diff_open/diffsplit/off/accept/reject/diffthis) stay host-side: they mutate &mut Editor (pane tree, document actor, task spawning), which lattice-diff cannot reach without a dependency cycle. This is the Effect-vocabulary-is-the-host-boundary rule.

The commands register under their plain user-facing names (diff, diffsplit, hunk-next, …) — no ex: prefix and no host alias shim (the multibuffer pattern); :diff resolves to them directly.

Two diff touch-points still stay host-side, and are not mode-ownership violations (see docs/dev/architecture/diff-extraction.md, couplings C6/C10):

  • The DiffSubsystem lifecycle — bind with the host’s BufferRegistryDocumentResolver, the diff_subsystem / diff_subscription_guard / diff_forwarders Editor fields, and the apply_pending_diff_mode_changes dispatch-tail drain — is host actor-loop state (terminal-invocation-runner category). The subsystem handle is published as a service (DiffSubsystemHandle) so the modes reach it generically.
  • The +N ~M modeline element is registered against the host’s ModelineService, created after the Phase-B install list (boot ordering). The descriptor + diff_content formatter are mode-owned (in crate::mode); only the registration call is host-sequenced.

Functions§

install
Wire the diff subsystem’s modes + commands into the editor at boot.