[WIP] lsp: Add codelens support #13165
Conversation
|
in one of your previous gif, you showed some haskell code: is this motivated by haskell-language-server ? (I was not sure wether it does this via a codeAction or codeLens) |
Yes it's motivated by haskell-language-server for the evaluate feature https://github.com/haskell/haskell-language-server#features There's also an issue in the repo to support it via code action, but currently it only works with codelens |
|
ocaml-lsp uses codelens for type information, which I find very useful too. I haven't been doing a lot of ocaml lately, but I really appreciate this being added to neovim! |
|
gopls (go language server) also supports a bunch of code lenses which are quite helpful: https://github.com/golang/tools/blob/master/gopls/doc/settings.md#code-lenses |
e1731f1
to
9cd3a3a
|
Pushed a couple of changes. It now is in its own module similar to Should be functional now. |
|
It would be very convenient to have this API out of the box. At the moment, codeLens information may be obtained using |
| local chunks = { {lens.command.title, 'LspCodeLens'} } | ||
| api.nvim_buf_set_virtual_text(bufnr, ns, line, chunks, {}) | ||
| else | ||
| -- todo: Should there be a different logic to decide whether to resolve the codelens? |
fsouza
Dec 6, 2020
Contributor
I've implemented codelenses in my vimfiles and there I resolve just before executing (would be on M.run here). It makes execution slower, but afaik I don't use any language server that supports codeLens/resolve, so not sure which approach is better or how to measure it :(
I've implemented codelenses in my vimfiles and there I resolve just before executing (would be on M.run here). It makes execution slower, but afaik I don't use any language server that supports codeLens/resolve, so not sure which approach is better or how to measure it :(
mfussenegger
Dec 7, 2020
Author
Contributor
I did that in a first version as well, but it doesn't really work for unresolved lenses.
If the lens isn't resolved already there isn't anything sensible that could be displayed to the user.
For example, language servers like eclipse.jdt.ls provide the option to enable reference counts via code lens.
The response just contains lens like this:
data = { "file:///path/to/file.java", {
character = 13,
line = 145
}, "references" },
range = {
end = {
character = 20,
line = 145
},
start = {
character = 13,
line = 145
}
The data part is arbitrary.
Once resolved it receives the command part in addition:
{
command = {
arguments = { "file:///path/to/file.java", {
character = 16,
line = 557
}, { {
range = {
end = {
character = 64,
line = 55
},
start = {
character = 23,
line = 55
}
},
uri = "file:///path/to/file.java"
} } },
command = "java.show.references",
title = "1 reference"
}
}
I did that in a first version as well, but it doesn't really work for unresolved lenses.
If the lens isn't resolved already there isn't anything sensible that could be displayed to the user.
For example, language servers like eclipse.jdt.ls provide the option to enable reference counts via code lens.
The response just contains lens like this:
data = { "file:///path/to/file.java", {
character = 13,
line = 145
}, "references" },
range = {
end = {
character = 20,
line = 145
},
start = {
character = 13,
line = 145
}
The data part is arbitrary.
Once resolved it receives the command part in addition:
{
command = {
arguments = { "file:///path/to/file.java", {
character = 16,
line = 557
}, { {
range = {
end = {
character = 64,
line = 55
},
start = {
character = 23,
line = 55
}
},
uri = "file:///path/to/file.java"
} } },
command = "java.show.references",
title = "1 reference"
}
}

Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.



Adds some basic support for codelens.
See codeLens specification
Opening this to get some feedback about the UI for them.
vim-lsp implemented them similar to code actions - the user gets prompted for which codelens to run.
See https://github.com/prabirshrestha/vim-lsp/pull/831/files
I think that may be a bit hard to use, because many code lens have the same title, so it will be hard for users to choose the right one.
LanguageClient-neovim implements them using virtualtext. I followed the same approach for now.
Example:
TODO:
Example usage: