Struct KeyPipeline 

pub struct KeyPipeline { /* private fields */ }

The vim key layer lives in escriba_keymap::pipeline — one implementation every app drives. Re-exported so the gate in tests/operand_capture_order.rs keeps its spelling. The vim key layer: keymap + every piece of half-typed-gesture state.

See the module docs for the contract. Construct with KeyPipeline::default_vim (or KeyPipeline::new over a customised Keymap), then hand every key to KeyPipeline::feed.

Implementations

impl KeyPipeline

pub fn new(keymap: Keymap) -> KeyPipeline

A pipeline over keymap, with nothing half-typed.

pub fn default_vim() -> KeyPipeline

A pipeline over Keymap::default_vim.

pub const fn keymap(&self) -> &Keymap

pub const fn keymap_mut(&mut self) -> &mut Keymap

The live keymap — rc / plugin binding application writes here.

pub fn pending_keys(&self) -> &[Key]

The keys held for an in-progress multi-key sequence (empty when none). What a “showcmd” indicator renders.

pub fn op_state(&self) -> &OpState

The operator machine’s state (Resting, Awaiting, AwaitingSearch).

pub const fn last_find(&self) -> Option<FindSpec>

The last completed f/F/t/T — what ; / , (Motion::RepeatFind) resolve through. Resolving it needs the buffer, so that is the host’s job; recording it is the key layer’s.

pub fn is_pending(&self) -> bool

True while a key sequence, an operator (including d/ with its search prompt open), an object, a find, a replace or a mark is half-typed.

A bare COUNT prefix is not included: it lives in ModalState (pending_count()), which the host already holds.

pub fn reset(&mut self)

Abandon everything half-typed and disarm the operator machine. The keymap and Self::last_find are kept. The count prefix lives in the host’s ModalState; clear it there.

pub fn feed(&mut self, modal: &mut ModalState, key: &Key) -> Vec<(Action, u32)>

Feed one key; get the fully composed steps to execute, in order.

Each (Action, u32) has passed the operator machine: 3d2w yields one ApplyOperator { Delete, WordStartNext } at count 6, ciw one ApplyOperatorObject, fx a Move(FindChar …), gg the resolved sequence. The count is a REPETITION count for most actions; an editor that treats some actions as absorbing their count (3p, 2dd as one operation) decides that itself.

Counts accumulate in modal; the pipeline never mutates text and never changes the mode — mode changes come back as actions.

This is Self::resolve_key followed by Self::compose on every unit. A host that must be able to refuse a unit before the operator machine sees it (see the module docs) calls those two itself.

pub fn compose(&mut self, action: &Action, count: u32) -> Vec<(Action, u32)>

Run the operator machine over one resolved unit.

Also the entry for actions that did not come from a key — anything a host dispatches should pass here, so an armed d composes with it the same way it composes with a keyed motion.

| is folded in first: it is the one motion whose count is an ARGUMENT rather than a repetition (40| is column 40, not “column 1, forty times”). Folding it here keeps the machine at one rule — counts repeat — with the exception living where the exception is.

pub fn resolve_key( &mut self, modal: &mut ModalState, key: &Key, ) -> Vec<(Action, u32)>

The key layer alone: captures, sequences, counts, keymap. Returns the units to hand to Self::compose, one at a time and in order.

A repeated sequence (3gg) and a counted object (2diw) come back as that many count-1 units rather than one counted unit, because that is how they meet the operator machine: each repetition is its own event (d3gg composes the first and runs the other two bare).

Trait Implementations

impl Clone for KeyPipeline

fn clone(&self) -> KeyPipeline

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for KeyPipeline

fn fmt(&self, f: &mut Formatter<'_>) -> Result<(), Error>

Formats the value using the given formatter.

impl Default for KeyPipeline

fn default() -> KeyPipeline

Returns the “default value” for a type.