Files
MeshTerm/meshterm
Jean-Pierre MartineauandClaude Opus 5.5 3095e3b236 Every page with a highlight edge-scrolls, with no code of its own
Edge scroll reached only the eight screens that answered cursor_at_edge, one
gate each; the trace screen, the autocomplete prompt and anything built
tomorrow went without. Now no screen says where its edges are. An arrow goes
to the screen like any key, and the next paint reads the answer off the page:
a highlight on the same line, drawn the same, moved nothing, so the page
takes the line instead. Comparing the drawn line, not just its index, keeps a
list that scrolls in its own window from looking stuck. Arrows pressed faster
than the screen paints are judged together. All a screen supplies is its
highlight's line in cursor_line, which keeping it in view asked for already.
The eight gates and row_at_edge are gone.

The snap-back's arrow is now the one pointing at the off-screen highlight,
read from where the paint left it, so it no longer needs to know which edge
the page went past. Home and End take the page to its ends after the screen
has handled them, without assuming the highlight followed.

The remote CLI opts out (edge_scrolls = False): the line it keeps in view is
its prompt, and its arrows recall history. The autocomplete prompt now names
its highlighted suggestion, so a short box follows it; an empty select list's
"no matches" line stands in for the highlight; and the reorder list's Home
and End jump to its first and last rows, as on every list.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-04 17:15:15 -04:00
..
2026-09-29 02:09:04 -04:00