bug#73452: Code lens support in eglot

[Dmitry Gutov <dmitry@gutov.dev>]

On 25/09/2024 14:31, Eli Zaretskii wrote:
>> Read the last parts of the discussion I linked to if you're
>> interested.
> I did, but couldn't answer my questions, because the discussion relies
> heavily on VSCode features with which I'm not familiar and whose
> descriptions I saw didn't clarify the issue.

It seems to me that a brief description would be "buttons that do 
things", but unlike Code Actions - already available in Eglot - those 
things don't typically alter the text that they act on.

A LSP-generic mechanism to position those buttons at places in code 
which are recognized by the LSP server. For the LSP spec:

/**
  * 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.
  * ...

Running tests is the #1 use I found for them when writing some Go 
recently. Eglot doesn't have a built-in test launcher of any sort, so 
that feels like an omission.

There are other lenses for Go (enumerated here: 
https://go.googlesource.com/tools/+/master/gopls/doc/codelenses.md), and 
they do sound useful, but less essential in comparison.

And I would probably agree that the examples from the original PR are 
not that impressive (we already know how to search for references, and 
we know that that action works with every symbol - more or less, and we 
know how to access VC information - or in any case this would be the 
same across languages, or without LSP).

It seems the strongest point of code lenses is advertising actions 
specific to language and/or to a context within the source code file 
(such as, again, launching tests). So the user is made aware of the 
capability.

Admittedly, this seems more useful with some servers than others: gopls, 
rust-analyzer and ruby-lsp have test runner (and debugger) lenses, 
whereas clangd and typescript-language-server only have the "references" 
thing - I guess the usages count is nice, but it's much less essential.