Subject: bug#73452: Code lens support in eglot

From: Eli Zaretskii <[email-masked]>
Date: Fri, 27 Sep 2024 08:55:16 +0300

> Date: Thu, 26 Sep 2024 17:35:21 +0200
> Cc: [email-masked]
> From: Federico Beffa <[email-masked]>
> 
> 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.

Thanks.  So basically, code lenses are suggestions for actions, and
those suggestions are presented as a kind of overlays over the code?

If so, I think the infrastructure we need is mostly the presentation
of the lenses and how the users select the action(s) they want?