bug#73452: Code lens support in eglot

[Dmitry Gutov <dmitry@gutov.dev>]

On 27/09/2024 09:53, Eli Zaretskii wrote:
>> Date: Fri, 27 Sep 2024 03:20:35 +0300
>> Cc: 73452@debbugs.gnu.org, federico.beffa@fbengineering.ch
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> 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.
> 
> This seems to be in contradiction with what's been said previously
> (and my understanding from reading the linked pages): that code lenses
> are UI sugar for server actions.

There is no such term as "server action" in LSP, so the above statement 
is probably both true and false at the same time. But lenses are not 
sugar on top of code actions, if that's what you means.

 > (If this is different from "Code> Actions", then I guess there's some 
subtlety here I don't get yet.)

They are different parts of the LSP protocol, even though, practically, 
some "actions" could be implemented as either. Anyway to quote from 
https://go.googlesource.com/tools/+/master/gopls/doc/features/transformation.md:

   A code action is an action associated with a portion of the file. Each
   time the selection changes, a typical client makes a textDocument/
   codeAction request for the set of available actions, then updates its
   UI elements (menus, icons, tooltips) to reflect them. The VS Code
   manual describes code actions as “Quick fixes + Refactorings”.

   A codeAction request delivers the menu, so to speak, but it does not
   order the meal. Once the user chooses an action, one of two things
   happens. In trivial cases, the action itself contains an edit that the
   client can directly apply to the file. But in most cases the action
   contains a command, similar to the command associated with a code
   lens.

   ...

   The main difference between code lenses and code actions is this:

   * a codeLens request obtains commands for the entire file. Each
   command specifies its applicable source range, and typically appears
   as an annotation on that source range.
   * a codeAction request obtains commands only for a particular range:
   the current selection. All the commands are presented together in a
   menu at that location.

To give a couple of example: 'rename' is a code action, whereas 'run the 
test near point' is a code lens. Because the server will tell you which 
tests are defined in the current file and at which positions.

> You yourself say later that "the strongest point of code lenses is
> advertising actions specific to language and/or to a context", which
> seems to affirm my understanding.  And since Eglot already supports
> actions, what seems to be missing is that UI sugar, i.e. a way of
> presenting the lenses and a way for the user to select those he/she
> wants to invoke.

Yes, and what might be missing is not really a UI feature (we know how 
to print buttons, after all), but higher-level decisions, I guess, for 
how and when to print such buttons. It shouldn't be very difficult to 
implement, but people might disagree on the finer details of behavior.