GNU bug report logs - #73452
Code lens support in eglot

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73452 <at> debbugs.gnu.org, federico.beffa <at> fbengineering.ch, joaotavora <at> gmail.com
Subject: bug#73452: Code lens support in eglot
Date: Fri, 27 Sep 2024 22:27:23 +0300

On 27/09/2024 09:53, Eli Zaretskii wrote:
>> Date: Fri, 27 Sep 2024 03:20:35 +0300
>> Cc: 73452 <at> debbugs.gnu.org, federico.beffa <at> fbengineering.ch
>> From: Dmitry Gutov <dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.