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

Previous Next

Full log

View this message in rfc822 format

From: Federico Beffa <federico.beffa <at> fbengineering.ch>
To: João Távora <joaotavora <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 73452 <at> debbugs.gnu.org
Subject: bug#73452: Code lens support in eglot
Date: Thu, 26 Sep 2024 17:35:21 +0200

[Message part 1 (text/plain, inline)]

On 26/09/2024 10:09, João Távora wrote:
> On Wed, Sep 25, 2024 at 12:31 PM Eli Zaretskii<eliz <at> gnu.org> wrote:
>
>> Then maybe someone could describe such an abstraction.
> Maybe.

Code lenses are not too different from code actions (see below). A new 
abstraction would make sense only if you plan to reorganize the entire 
`eglot` code. In that case the concept of a "code reviewer" or 
"assistant" could be useful, with functions like
- signal-error
- suggest
- exec-in-comment
- visit
- show-references
- show-type
...

>
>>> 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.
> Yes, that's part of the problem.  This LSP feature is a VSCode/VStudio MS
> UI thing, and I also don't know those things well.  The few times I open
> these apps I get turned off by all the clutter.

I'm not an expert, but my understanding is as follows:

A code lens represents a command that should be shown to users along 
with source code text, like the number of references, a way to run 
tests, etc. It goes like this:

1. The client sends a code lens request.
2. The server replies with commands along with the text to show to the user.
3. When/if the user chooses to run any of them, the client sends the 
request to run it to the server. (As an option it's also possible for 
the client to run the command.)
4. The server executes the command and replies with the change in the 
source code.

So, the main difference between code actions and code lens is the fact 
that the latter should show some text to the user. A few examples from 
the Haskell language server are:

- You can run some code in comments and get the result added. Here is a 
screenshot from VSCode

"Refresh..." is sent by the server. (It's "Execute..." before the first 
execution).

- An "import" lens suggests changing a library import to only import 
used symbols


- Expressions without type annotations get a lens showing the type and, 
if executed, it's added.


You may not like the VSCode UI, but Emacs doesn't have to use exactly 
the same interface. The client decides how to present the code lens 
text, and you may choose to only display it in some circumstances.

Code lenses are part of the core features of LSP since several years and 
are used by many servers. If Emacs ignores them, all those features are 
not available in Emacs. A client can't decide that it prefers to use 
actions instead of lenses. It's the server how decides how to offer the 
functionality.

[Message part 2 (text/html, inline)]

[4xBEPkgoXUmaIYt5.png (image/png, inline)]

[prAlDPTayQnnVXu0.png (image/png, inline)]

[3cw4R60JKTw4gJ80.png (image/png, inline)]

Previous Next

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