From: Federico Beffa via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "João Távora" <joaotavora@gmail.com>, "Eli Zaretskii" <eliz@gnu.org>
Cc: 73452@debbugs.gnu.org
Subject: bug#73452: Code lens support in eglot
Date: Thu, 26 Sep 2024 17:35:21 +0200 [thread overview]
Message-ID: <402b37ee-8f2a-4c44-8861-be9054ed5255@fbengineering.ch> (raw)
In-Reply-To: <CALDnm502SfssD7HyjxEjG9co00tc1WR_tyyZAqcaMk0JWe1EFA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]
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.
[-- Attachment #2.1: Type: text/html, Size: 4267 bytes --]
[-- Attachment #2.2: 4xBEPkgoXUmaIYt5.png --]
[-- Type: image/png, Size: 8581 bytes --]
[-- Attachment #2.3: prAlDPTayQnnVXu0.png --]
[-- Type: image/png, Size: 22479 bytes --]
[-- Attachment #2.4: 3cw4R60JKTw4gJ80.png --]
[-- Type: image/png, Size: 32276 bytes --]
next prev parent reply other threads:[~2024-09-26 15:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 14:02 bug#73452: Code lens support in eglot Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-24 14:26 ` João Távora
2024-09-24 15:48 ` Eli Zaretskii
2024-09-24 21:01 ` João Távora
2024-09-25 11:31 ` Eli Zaretskii
2024-09-26 8:09 ` João Távora
2024-09-26 15:35 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-09-26 17:12 ` João Távora
2024-09-26 19:07 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-26 23:47 ` Dmitry Gutov
2024-09-27 5:55 ` Eli Zaretskii
2024-09-27 0:20 ` Dmitry Gutov
2024-09-27 6:53 ` Eli Zaretskii
2024-09-27 19:27 ` Dmitry Gutov
2024-10-02 11:57 ` Felician Nemeth
2024-10-02 23:26 ` Dmitry Gutov
2024-10-03 22:43 ` João Távora
2024-10-07 23:33 ` Dmitry Gutov
2024-09-25 7:04 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-25 7:50 ` João Távora
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=402b37ee-8f2a-4c44-8861-be9054ed5255@fbengineering.ch \
--to=bug-gnu-emacs@gnu.org \
--cc=73452@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=federico.beffa@fbengineering.ch \
--cc=joaotavora@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.