✅ Feature Request: LSP hover preview for linked notes

[Lowband21]

Feature request: LSP hover preview for linked notes

Problem

When editing notes with wiki/markdown links, I want to preview the linked note’s contents from the current note.

Currently, to preview what a note contains, I jump to the file with the go to definition action, then navigate back.
This is quick, but opens an extra buffer.

In Helix, space + k triggers LSP hover, but IWE LSP server does not currently advertise hover capability.

Proposed solution

Add LSP textDocument/hover support to IWE:

• When the cursor is on a link (wiki link or markdown link), return a hover popup containing a small preview of the target note.
• If the link target can’t be resolved or the note doesn’t exist, return no hover.

Fit with project goals

IWE already provides editor-assist features via LSP (completion, go-to-definition, references, rename, formatting, code actions).
Hover preview is a standard LSP feature that complements link navigation and improves workflows across editors (Helix, Neovim, VS Code, etc.) without adding editor-specific code.

Implementation approach

1. Add config parameters for preview_length and include_frontmatter.
2. Bump config version and add defaults and/or a migration for backwards compatibility.
3. Advertise hover capability in ServerCapabilities (hoverProvider = Some(...)).
4. Add "textDocument/hover" routing in the LSP router to a new server handler.
5. Reuse the existing link-at-cursor logic used for go-to-definition (parser.url_at(position)).
6. Truncate and strip frontmatter according to config values.

Test plan

Add Rust tests similar to existing LSP tests to assert:

• Hover over link returns markdown contents containing the target note’s first lines.
• Hover outside a link returns None.
• Hover over a missing target returns None.

---

I would be happy to put together a quick PR for this feature if it's aligned with the project goals.

[gimalay]

Hey @Lowband21 , thanks for starting this discussion. I think this feature makes sense!

Could you please explain what include_frontmatter and preview_length config parameters are for?

Is its possible to start with a reasonably good defaults so we don't need any new config parameters?

[Lowband21]

Hi @gimalay, thanks for the quick turn around!

Yes, of course, I did gloss over those without explaining.

I had in mind that include_frontmatter would be a bool indicating whether the note's "frontmatter" (defined as an optional block prior to any other content wrapped in "---") should be included in the preview text. If false, we strip it from the preview up till the first non-empty line.

As for preview_length, I'm thinking of it as a cap on the maximum number of lines of content to include in the preview. The goal being to avoid massive preview windows. Though as I write this out, I wonder if editors already handle this well enough that it's unnecessary. I know that in helix if documentation is too long it becomes scrollable. If we still want to include it, maybe just default to none, meaning no truncation. I'll do some research on how editors typically handle this if you're not sure offhand.

Regardless, we could definitely provide defaults to avoid config changes since neither value is strictly necessary for the feature. As mentioned above, no truncation seems like it would probably be a reasonable default. As for including frontmatter, I'm open to opinions. It might make sense to default to removing it so that users don't end up with previews that only show the note's metadata rather than content. But I do imagine for some that would be desirable, so if we don't want to add any new config values, it might be less problematic to not strip it.

Alternatively, if we have defaults, we should be able to have serde deserialization just fallback to those if the corresponding values are missing from the toml.

Let me know if I overlooked anything and what you think!

[gimalay]

According to the spec it expected by the editors that LSP returns MarkedString which is Markdown.

I would recommend to not include the frontmatter by default. I also recommend returning the entire document (markdown part) to the text edition without adjusting the length so the editor can decide how to present the content.

In this case we don't need any changes in the configuration. (please let me know if I'm missing something)

[Lowband21]

Sounds good to me, though I did notice that MarkedString is noted as deprecated in the spec, so MarkupContent should probably be used instead, unless I'm missing a reason not to.

I'll put together a PR and submit it for you to review this evening after I get off work. Should be quite straightforward.

[gimalay]

Sounds good!

Good catch for the deprecated field, I missed that.

[gimalay]

Released 🎉

Big thanks to @Lowband21 for the contribution!