gopls code lenses unsupported?

[jzelinskie]

Summary

I can't seem to get the codelenses for Go to work with Helix.

Is this a scenario where this functionality is blocked by a lack of plugins?

Reproduction Steps

Here's the snippet from my languages.toml (more in the recording below):

[language-server.gopls.config]
gofumpt = true
codelenses.gc_details = true

https://asciinema.org/a/BDk7gg56D56mfuDMLBn65xiRF

Helix log

~/.cache/helix/helix.log

These are from me just spamming trying to figure out if I need to toggle the lens somehow. In VSCode I believe you toggle the lens on the package. ``` 2023-08-15T17:18:16.596 helix_view::editor [ERROR] editor error: No code actions available 2023-08-15T17:18:17.507 helix_view::editor [ERROR] editor error: No code actions available 2023-08-15T17:18:18.847 helix_view::editor [ERROR] editor error: No code actions available ```

Platform

macOS

Terminal Emulator

kitty 0.29.2

Helix Version

helix 23.05 (0a45fb43)

[jzelinskie]

After consulting the Matrix channel, it appears that code lenses are unsupported in Helix because they are

1) An extension to LSP 2) Many require server-specific client-side code that would have to be built into Helix or provided by a Helix plugin

For 1) it appears some servers do things consistently, but there're no guarantees and for 2) some code lenses do not require any client-side behavior. It might be possible to add support into Helix for these cases specifically (which would unlock functionality for LSP implementations like rust-analyzer and gopls), but I'm honestly more disappointed in LSP than Helix in this scenario.

[zetashift]

Related: https://github.com/helix-editor/helix/pull/5063

It might be possible to add support into Helix for these cases specifically (which would unlock functionality for LSP implementations like rust-analyzer and gopls),

Hoping for this! But I can understand not wanting to do it before a plugin system.

[pascalkuthe]

Client side code lenses work by attaching an opaque json blob to the request. This json blob is not standardized in any way so every lsp client action for every language server would requure custom code in helix. This custom code would also need to change frequently as these custom json blobs have no stability gsuntre and LSP servers can (and do) change their format frequently.

As with everything else language specific code will not be accepted into helix and must wait for the plugin system

[michaelpj]

I'm slightly confused by this. Code lenses have a sensible specification and are useful if you just implement what's in the spec.

If there are some language servers that deviate from the spec or do weird things with the data field then that seems like it's their problem. Not implementing the basic and generic code lens functionality for that reason seems very odd. For example, haskell-language-server's code lenses are 100% vanilla, using nothing that's not in the spec. It's sad they don't work in helix.

[adonovan]

FWIW, Helix is not the only editor that lacks LSP Code Lens support: eglot, an LSP client package for Emacs, is another. (There's a prototype implementation in https://github.joaotavora/eglot/pull/71.)

Code Lenses have the downside that they push information into the editor UI, which can be obtrusive or distracting, and that's why gopls' code lenses are all off by default. I suspect we will migrate most of those features to code actions, which are unobtrusive, though less discoverable. Users do need to be educated to know to look for them; this is a problem best solved with documentation.