GNU bug report logs -
#73452
Code lens support in eglot
Previous Next
Full log
View this message in rfc822 format
> Date: Thu, 26 Sep 2024 17:35:21 +0200
> Cc: 73452 <at> debbugs.gnu.org
> From: Federico Beffa <federico.beffa <at> fbengineering.ch>
>
> 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?
This bug report was last modified 256 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.