Skip to main content

binding_layer_mode

Function binding_layer_mode 

Source
pub fn binding_layer_mode(
    handle: &KeymapHandle,
    mode: BindingMode,
    prefix: &[KeyChord],
    chord: &KeyChord,
    layers: &[ModeId],
) -> Option<ModeId>
Expand description

Resolve the next key of a multi-chord Normal-mode sequence via the registry. The caller supplies the prefix chord sequence already absorbed; this helper appends the normalised current chord and looks the resulting path up in the trie. Bound -> the bound action; everything else (Partial / Unbound) -> Action::None to drop the pending state, matching every legacy resolve_after_*’s catchall.

Used by:

  • Pending::AfterG / Pending::AfterZ (slice 8.g.ii) – prefix [g] / [z].
  • Pending::AfterOperator(op) (slice 8.g.iii) – prefix [d] / [c] / [y] / [>] / [<] for the single-chord operators, or [g, U] / [g, u] / [g, ~] for the case operators (mapped via operator_prefix).
  • Pending::AfterTextObject { op, around } (slice 8.g.iii) – prefix [op_prefix..., 'i' or 'a']. The MODE layer whose binding won for prefix + chord under layers, or None when the winner came from the always-on Builtin / User layers (or nothing is bound at all).

This is what makes AP.0.2’s fall-through able to peel ONE layer at a time. A declining action has to be re-resolved without its own layer, and the dispatcher cannot know which layer that was — a chord may be bound in the major and in two minors, and the fold in lookup_with_context decides the winner. Asking the trie which layer produced the binding is cheaper and more honest than guessing at the list’s tail.

Pure lookup against an in-memory trie: no allocation beyond the path, and only reached on the decline path, which is off the happy keystroke route.