Module foreground_cancel 

The foreground-cancellation seam, as a registered service (CG.2).

Design: docs/dev/architecture/cancellation.md; sequencing: docs/dev/operations/slice-plans/cancellation.md.

Why a service rather than a method on Editor

CG.1 put arm_cancel() on Editor, which needs &mut. That is reachable from a provider’s initial trigger — open_search_view holds a &mut dyn ModeActivator — but not from the places that respawn the same work later. Project search’s gr refresh is an ActionHandlerRegistration closure holding only &self services, and it spawns a replacement scan; LSP requests (CG.3) and plugin calls (CG.4) sit behind the same wall.

Enrolling only where &mut happens to be available is the half-migration this project keeps re-discovering: <C-g> would cancel a fresh search and silently do nothing to a refreshed one, and nothing about the code would say so. So the arming surface takes &self and lives in the ServiceRegistry, where every subsystem already looks things up.

Contract

One token armed at a time. ForegroundCancel::arm cancels its predecessor before handing out the new one, which means supersede is the same mechanism as cancel — a second :search before the first finishes abandons the first scan, and gr refreshing a view no longer needs a private flag to do it.

v1 is deliberately single-slot: a second user-initiated op cancels whatever was running. cancellation.md §8 records why (and what a stack would change) — the user pressed cancel, or started something new, and either way the old work is unwanted.

Registration

Register and look up under ForegroundCancelHandle, never under ForegroundCancel. ServiceRegistry::register::<T> keys on TypeId::of::<T>(), so registering an Arc<ForegroundCancel> and asking for a ForegroundCancel silently returns None.

Structs

ForegroundCancel

The armed foreground token, shared between the host (which cancels) and every subsystem that spawns cancellable work (which arms).

Type Aliases

ForegroundCancelHandle

Register and look up under this alias — see the module docs on the TypeId pitfall.