Expand description
#611 (ADR 0190): hover’s resolution ladder, as one pure function.
Backend::hover is transport — it resolves the cursor position, gathers the
round’s tables and the live buffer, and packages the result as an LSP
Hover. The order the rungs are tried in is the behaviour: #611’s gap B was
a fall-through bug, where a rung that resolved the offset correctly but
rendered nothing let a later, name-matching rung answer instead — a
confidently wrong hover. That order lives here, once, so a test can pin it
rather than replicate it (a replica agrees with the original only until
someone reorders one of them).
Two text sources, deliberately: the index rungs read the round’s analysed snapshot (the tables’ spans index into it), while the lexical rungs read the live buffer, which is what makes hover work mid-edit. They diverge while the user types, so the ladder keeps them distinct rather than assuming one.
The rungs, in trial order (see hover_content’s inline numbering):
- the binding index — a resolved symbol reference, described from its
defining file (a resolved
Servicegets a #855 wire-contract appendix); - a
storefield operation; - a local/param/
self; - #855: a handler’s HEADER (
on, the method/kind token, the route literal) — guarded to that byte range so it cannot shadow rung 1; - a top-level declaration by name (lexical, first live-buffer rung);
- the
key/storecontextual keywords and agent-state references; - a handler-position
@cacheannotation; - a
Recv.membername-receiver access; - a project-wide name scan;
- the embedded first-party sources.
Structs§
- Hover
Analysis - The analysed round’s tables, positioned at the cursor.
- Hover
Input - Everything the ladder reads.
Functions§
- hover_
content - The hover Markdown for the cursor, or
Nonewhen no rung resolves it.