feat(lsp): code lenses

[matoous]

Initial (limited) implementation of LSP code lenses¹. This is purposefully as small of a change as possible, it displays code lenses in the gutter and adds a single new command show_code_lenses_under_cursor that displays a picker for code lenses on the current line. Notably, displaying code lenses as annotations for the current line is not implemented and this implementation doesn't support resolving code lenses from multiple language servers. I am happy to address both but would prefer to do so separately to make this PR reviewable amidst the low bandwith and large backlog for maintainers.

Code Lens

From the VS Code features docs²:

The essence of the feature is "actionable contextual information interspersed" in your source code. That's quite a mouthful. Let me break it down for you. CodeLens are links in your code:
Actionable - You can click on the link and something happens.
Contextual - The links are close to the code they are representing.
Interspersed - The links located throughout your source.

And from the official LSP docs³:

A code lens represents a command that should be shown along with
source text, like the number of references, a way to run tests, etc.

Support

The support for code lens varies among LSPs but there are already nice features that can be achieved via code lenses (some of them listed below). The biggest limitation is that some language servers rely on client-side command execution which is usually solved via plugins. For other LSPs code lenses are opt-in only and without plugins can for example only display inline hints about number of references or number of implementations⁴.

Still, LSP is part of Helix and given Code Lenses are part of the specs, I think it's fair to implement them. Even if - without a plugin system - with limited capabilities.

• golang
  • generate, vendor, update dependency, and more.
  • test execution isn't supported⁵
• rust-analyzer
  • run for tests and main - requires client side execuity
  • references/implementations (show number of references/implementations and can be opened to view them, disabled by default) - requires client side execution
• deno
  • run test support - requires client side execution

(didn't check more languages).

Future work

As mentioned above this implementation is limited and doesn't provide Code Lens as they should be provided - displayed contextually as a text - close to the code that they apply for. There should be a follow up PRs for:

• supporting multiple language servers
• displaying the code lenses as a line annotations

Showcase

Screen.Recording.2025-11-21.at.14.16.32.mov

---

Related/fixes: #3005
Related: #3272

Footnotes

1. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeLens ↩

2. https://code.visualstudio.com/blogs/2017/02/12/code-lens-roundup ↩

3. https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_codeLens ↩

4. https://github.com/typescript-language-server/typescript-language-server?tab=readme-ov-file#code-lenses-textdocumentcodelens ↩

5. https://github.com/golang/go/issues/36787 ↩

[sigmaSd]

rust-analyzer doesn't support executing commands (on the server side) so the commands need to be executed client side.

This is not specific to rust-analyzer, I think that other lsps work the same way (especially for test codelens), for example I know its the case with deno lsp.

I think this would require plugins to handle, because executing the commands is lsp dependent

[matoous]

@sigmaSd yes, indeed, you are right. Rust for example returns rust-analyzer.showReferences which is custom extension command which would indeed require plugins. I will push a few more changes but otherwise I guess this will need to be put on hold until the plugin system is available. Other option would be for the commands to be for now mapped to the shell via languages.toml configuration and the output being display the same way we do for :run-shell-command.

[pascalkuthe]

:sh currently does not return anything if the command returns an error (which is the interesting case for tests I would assume) aslo any tests that might want input will freeze the editor. I think for running tests to be a good experience we would need an integrated terminal #4649. Also going the sh route requires developing, maintaining and installing a separate CLI tool for each LSP command (these binaries don't exist yet) which I don't see people developing (and would only work for a subset of commands I guess).

How many servers actually support server side execution? If rust-analyzer is the odd-one out with client-only commands then this might be worth merging but if almost all LSPs only allow client-side command execution then I think this should probably wait for plugins.

[ayoub-benali]

rust-analyzer doesn't support executing commands (on the server side) so the commands need to be executed client side.

This is not specific to rust-analyzer, I think that other lsps work the same way (especially for test codelens), for example I know its the case with deno lsp.

I think this would require plugins to handle, because executing the commands is lsp dependent

I can confirm that at least Metals also expects the client to run some code lens commands and they are implemented in the plugin for sublime for example.

[Esnos33]

Hi, I'm new to git and I have question. I already have helix 23.03 and in release notes there is information about Initial support for snippets, but #3005 bug is still there. This is how it is supposed to be? Automatic type annotation is one of best things in haskell.

[matoous]

Closing this until Helix has support for plugins that are prerequisit for this being useful.

[maralorn]

I have a question about this: It is my impression that there are code lenses which don’t need a plugin to work. I think haskell-language-server has some of those. Is that wrong? Or could we maybe implement this, but only show code lenses in the case where they don’t require a plugin?
Actually, haskell-language-server simply offers code actions for when you click on the code lens. And those code actions can already be used right now. I am primarily interested in the code lenses because they display useful information, even if you don’t want to activate them right now.

[alexaandru]

Similar to the above comment, in gopls there are code actions that are available after running code lenses and there already is support for code actions so we wouldn't need any plugins to use them.

For example, when in go.mod file, there is a code lense Check for upgrades which when run it will populate diagnostics with info about which packages can be upgraded. Then for each of those lines, there is a code action available to upgrade it. So code lenses alone would be a very valuable addition.

[matoous]

👋 let me take a look if I could revive this. Indeed, the support might vary language to language but for some languages this might be worthwhile even in limited capacity.

[maralorn]

Also: Even if Code lenses can’t be triggered it might still be useful to show them, right? And that part should always work without plugin support, right?

[maralorn]

I am test driving this and it works just fine with haskell-language-server. Of course it would be nice if the code lenses would auto-update, but this is good enough for me.

Thank you!

[matoous]

Heya 👋 I picked this up again after a loooong time, there seems to be way more of the ground work done to get this working properly. Rebase was too hard, so I started from scratch, sorry for the nuked history of this PR.

It should now work properly by auto-requesting code lenses for documents. space + l on a line with code lenses to view them/execute them. Some parts that are missing and I will try to take a look into in the following days:

• supporting multiple LSPs
• rendering code lenses using virtual text (see below, keeping this out of scope of this PR)
• code lenses refresh request (server -> client)

Done parts which weren't part of the outdated PR:

• auto-request code lenses for documents (re-used the scaffolding build for color swatches)
• code lenses resolve requests

Feel free to test-drive (I will try to keep the branch up to date) and report any issues (just keep in mind what's unimplemented and expected vs. what should be working and isn't).

[matoous]

Displaying code lenses as a virtual text would ideally be done by implementing EndOfLineAnnotation (similar to InlineAnnotation but anchored at the end of the graphem after the newline character). So I am leaving this out for now with gutter being the only place where the code lenses are denoted. It would blow up the size of the PR and I think it can be done separately as a follow-up enhancement.