Symptom
The LSP editor hover popup renders many URL strings in link colour (theme.md_link) but they don't respond to clicks. Discovered during #488 smoke testing.
Concrete example
Hovering Rust's Vec (rust-analyzer doc) produced a popup with 143 lines of content. Debug output at draw time showed:
popup.lines = 143
popup.links = 13 ← only 13 registered as clickable
scroll_top = 38
max_visible_rows = 20 ← so visible window = lines 38-57
The 13 registered links lived on lines 48, 76, 104, 106, 106, 127, 127, 135, 135, 142, 142, 142, 142. With scroll_top=38, max_visible=20, only link[0] (line 48) falls in the visible window. The other 12 are out of view.
Meanwhile, looking at the visible content (lines 38-57), there are many URLs rendered in link colour — e.g. (https://doc.rust-lang.org/stable/alloc/macros/macro.vec.html), (https://doc.rust-lang.org/stable/alloc/vec/struct.Vec.html#capacity-and-reallocation), etc. None of these correspond to entries in popup.links → no hit rect → click does nothing.
Root cause (suspected)
editor_hover_to_quadraui_rich_text (src/render.rs:1045) populates popup.links from eh.links. That field comes from the markdown parsing pipeline. The markdown parser appears to handle [text](url) syntax (creating links where the visible "text" is registered) but does NOT auto-link bare URL text — even though the same URL might be styled in link colour via MdStyle::LinkUrl / MdStyle::Link.
Look at src/core/markdown/ for the link extraction logic. Likely missing: an auto-link pass that scans rendered lines for https?://[^\s)]+ patterns and registers each as a link if not already covered.
Fix sketches
Option A — auto-link bare URLs at adapter time
In editor_hover_to_quadraui_rich_text (or upstream in markdown rendering), scan each eh.rendered.lines[i] for URL patterns and append a RichTextLink for each match that doesn't already overlap an entry in eh.links. Pros: contained to render layer, doesn't change markdown parser. Cons: regex maintenance, false positives for URLs inside backticks or code spans.
Option B — fix the markdown parser to emit auto-links
Update the markdown parser to recognize bare URLs (CommonMark §6.5) and emit them as links during parsing. Pros: correct by construction, also benefits any other consumer of the parser. Cons: bigger change, needs to honour CommonMark autolink edge cases.
Option C — handled at the LSP layer
rust-analyzer markdown output for Vec does NOT wrap bare URLs in autolink syntax (it uses [url](url) for some, bare text for others). Could pre-process the LSP markdown server-side... no, this is rust-analyzer's content, we can't change it.
Recommended: Option A. Smaller, faster to ship, fixes the user-visible problem.
Related
Repro
cargo run --bin vimcode -- some_rust_file.rs- Hover any symbol with rich rust-analyzer docs containing bare URLs (e.g.
Vec, HashMap)
- Scroll the popup with arrow keys / mouse wheel
- Try to click any URL rendered in link colour
- Most do nothing. The
[text](url)-style links (where text != url) work. The bare-URL ones don't.
Symptom
The LSP editor hover popup renders many URL strings in link colour (theme.md_link) but they don't respond to clicks. Discovered during #488 smoke testing.
Concrete example
Hovering Rust's
Vec(rust-analyzer doc) produced a popup with 143 lines of content. Debug output at draw time showed:The 13 registered links lived on lines 48, 76, 104, 106, 106, 127, 127, 135, 135, 142, 142, 142, 142. With
scroll_top=38, max_visible=20, only link[0] (line 48) falls in the visible window. The other 12 are out of view.Meanwhile, looking at the visible content (lines 38-57), there are many URLs rendered in link colour — e.g.
(https://doc.rust-lang.org/stable/alloc/macros/macro.vec.html),(https://doc.rust-lang.org/stable/alloc/vec/struct.Vec.html#capacity-and-reallocation), etc. None of these correspond to entries inpopup.links→ no hit rect → click does nothing.Root cause (suspected)
editor_hover_to_quadraui_rich_text(src/render.rs:1045) populatespopup.linksfromeh.links. That field comes from the markdown parsing pipeline. The markdown parser appears to handle[text](url)syntax (creating links where the visible "text" is registered) but does NOT auto-link bare URL text — even though the same URL might be styled in link colour viaMdStyle::LinkUrl/MdStyle::Link.Look at
src/core/markdown/for the link extraction logic. Likely missing: an auto-link pass that scans rendered lines forhttps?://[^\s)]+patterns and registers each as a link if not already covered.Fix sketches
Option A — auto-link bare URLs at adapter time
In
editor_hover_to_quadraui_rich_text(or upstream in markdown rendering), scan eacheh.rendered.lines[i]for URL patterns and append aRichTextLinkfor each match that doesn't already overlap an entry ineh.links. Pros: contained to render layer, doesn't change markdown parser. Cons: regex maintenance, false positives for URLs inside backticks or code spans.Option B — fix the markdown parser to emit auto-links
Update the markdown parser to recognize bare URLs (CommonMark §6.5) and emit them as links during parsing. Pros: correct by construction, also benefits any other consumer of the parser. Cons: bigger change, needs to honour CommonMark autolink edge cases.
Option C — handled at the LSP layer
rust-analyzer markdown output for
Vecdoes NOT wrap bare URLs in autolink syntax (it uses[url](url)for some, bare text for others). Could pre-process the LSP markdown server-side... no, this is rust-analyzer's content, we can't change it.Recommended: Option A. Smaller, faster to ship, fixes the user-visible problem.
Related
Surface::RichTextPopupmigration that surfaced the broader issuesrc/render.rs:1045(editor_hover_to_quadraui_rich_text)src/core/markdown/(parser)Repro
cargo run --bin vimcode -- some_rust_file.rsVec,HashMap)[text](url)-style links (where text != url) work. The bare-URL ones don't.