Module which_key 

Which-key’s resolver — prefix → continuation model.

Design: docs/dev/architecture/which-key.md §4 (data model), §4.1 (label resolution), §4.2 (ordering). Sequencing: docs/dev/operations/slice-plans/archive/which-key.md (WK.1).

Pure and synchronous. Everything here is a function of a NodeView plus the command registry — no editor state, no renderer type, no I/O — so the whole model is unit-testable with a hand-built trie and no host at all.

Why this lives in lattice-keymap. Heuristic #6: which-key extends the keymap rather than introducing a new mechanism, so it belongs to the crate that already owns the trie, the layers and the resolution. And per the substrate-vs-mode-helper rule, the resolver’s only consumer is which-key’s own handler — so it is a helper function in the owning crate, not host machinery and not a trait method.

Structs

Entry

One row of the popup.

GridOpts

Grid geometry knobs, supplied by which-key’s options (§8).

GridSpan

A styled byte range within one rendered line.

RenderedGrid

The laid-out popup: lines to write, and where the keys are.

WhichKeyModel

The popup’s content, before layout.

Enums

EntryKind

What a row’s key leads to.

GridSpanKind

What a GridSpan covers. Deliberately semantic rather than a colour: this crate has no styling dependency, and the consumer maps these onto the editor’s existing style vocabulary.

Sort

Row ordering (§4.2). An explicit total order is required either way, because a node’s children live in a HashMap — without one the grid reshuffles between openings of the same prefix, which is a worse discoverability surface than no popup at all.

Constants

MIN_USABLE_WIDTH

Below this pane width the popup is suppressed entirely (§8) — a single column of truncated labels is worse than nothing.

Functions

build_model

Build the popup model from a resolved NodeView.

layout_grid

Lay the model out (§6). Pure: no renderer type crosses in, so both the column algorithm and the span placement are unit-testable with no renderer at all.