On 26/09/2024 10:09, João Távora wrote:

On Wed, Sep 25, 2024 at 12:31 PM Eli Zaretskii <eliz@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.