Roadmap: cursor-selectable inline link highlighting for the 40-column text viewer

[JC-000]

Roadmap / design capture. Not scheduled, and possibly not for this repo — see Scope.

The idea

Render fetched HTML as text on the 40-column screen with cursor-selectable inline links: link text is highlighted (reverse video), cursor keys move between links on screen, and RETURN follows the selected one. The motivating case is a text-only Wikipedia reader, where the article body is the point but navigating to the next article is most of the value.

Why it is not the obvious first choice

Raw link text is clutter at 40 columns — an inline [edit] or a citation superscript costs a meaningful fraction of a line. Three options, in increasing cost:

Approach	Navigation	Cost
Strip links entirely	none	trivial; fine for lwn.net, useless for Wikipedia
Lynx-style numbering — Commodore 64[7] inline, numbered list at the end, "type 7" to follow	keyboard, no cursor	cheap: no screen-position table, no repaint-on-scroll, no reverse video
Cursor-selectable highlighting (this issue)	cursor keys + RETURN	needs a link table mapping screen positions to targets, highlight/unhighlight on move, and rebuild on every scroll

The numbered variant delivers most of the navigational value for a fraction of the state, and is the sensible first implementation if this is ever built. This issue records the cursor-selectable version because it is the better end experience and because the design is worth capturing while it is fresh — not because it should be built first.

Design notes worth keeping

• The body already lives in the REU. HTTPS_BODY_TO_REU=1 streams the response to $10:0000 and src/viewer.s renders from there (125,235 B Wikipedia article, byte-verified on hardware). So a link table can live in REU alongside the text rather than competing for the C64 RAM this project keeps running out of. That is the single most important structural fact for anyone picking this up.
• State is the cost, not the highlighting. Reverse video is one bit per screen byte. The expense is the position→target table and keeping it correct across scrolling — the table must be rebuilt or offset every time the viewport moves.
• Rendering prerequisites, independent of link handling: tag stripping, entity decoding, whitespace collapsing, paragraph breaks, and 40-column word wrap. None of that exists yet. ascii_chrout case-folds for display (http_resp_buf rendered as ASCII on C64 screen (missing PETSCII translation) #28) and http_resp_buf keeps raw ASCII.
• Chunked bodies over 64 KB desync today (documented in CLAUDE.md), which matters for large articles.

Scope — read before starting

This repo's focus is delivering TLS 1.3, not building a browser. A Lynx-style renderer is a substantial piece of work with its own concerns — HTML parsing, layout, navigation, history — and is probably better as a separate repository consuming c64-https as the transport, in the same way libs/nistcurves and libs/x25519 are consumed here.

If that split happens, this issue should move with it. It is filed here to keep the design from being lost, not to claim the work.

Related

• src/viewer.s — the existing REU text viewer, the natural starting point
• http_resp_buf rendered as ASCII on C64 screen (missing PETSCII translation) #28 — body rendering / case folding