* bug#73452: Code lens support in eglot @ 2024-09-24 14:02 Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-09-24 14:26 ` João Távora 0 siblings, 1 reply; 20+ messages in thread From: Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-09-24 14:02 UTC (permalink / raw) To: 73452; +Cc: joaotavora [-- Attachment #1: Type: text/plain, Size: 648 bytes --] Hi, This is not a bug report, but rather an inquiry or feature request. I'm wondering if there are any plans for eglot to support code lens. These provide quite useful functionality. For example, the Haskell language server allows putting expressions (typically for test or documentation) in comments with a special syntax. The server then offers to execute the code (in VSCode appearing as a small button above the expression). When pressed, it inserts the result in a comment just below. Here's an example after execution: ```haskell addOne :: (Num a) => a -> a addOne x = x + 1 -- >>> addOne 2 -- 3 ``` Thanks for the great work! Fede [-- Attachment #2: Type: text/html, Size: 1038 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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-25 7:04 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 2 replies; 20+ messages in thread From: João Távora @ 2024-09-24 14:26 UTC (permalink / raw) To: Federico Beffa; +Cc: 73452 There is a discussion thread about this in the Eglot GitHub downstream tracker. https://github.com/joaotavora/eglot/pull/71 The current consensus there is that the feature is not _that_ useful, and that a clean implementation isn't really trivial since there is no underlying Emcas support structure (like there is for documentation, cross-referencing, diagnostics, snippets, etc) João On Tue, Sep 24, 2024 at 3:02 PM Federico Beffa <federico.beffa@fbengineering.ch> wrote: > > Hi, > > This is not a bug report, but rather an inquiry or feature request. I'm wondering if there are any plans for eglot to support code lens. > > These provide quite useful functionality. For example, the Haskell language server allows putting expressions (typically for test or documentation) in comments with a special syntax. The server then offers to execute the code (in VSCode appearing as a small button above the expression). When pressed, it inserts the result in a comment just below. Here's an example after execution: > > ```haskell > addOne :: (Num a) => a -> a > addOne x = x + 1 > > -- >>> addOne 2 > -- 3 > ``` > > Thanks for the great work! > Fede -- João Távora ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 7:04 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2024-09-24 15:48 UTC (permalink / raw) To: João Távora; +Cc: 73452, federico.beffa > Cc: 73452@debbugs.gnu.org > From: João Távora <joaotavora@gmail.com> > Date: Tue, 24 Sep 2024 15:26:55 +0100 > > There is a discussion thread about this in the Eglot GitHub downstream tracker. > > https://github.com/joaotavora/eglot/pull/71 > > The current consensus there is that the feature is not _that_ useful, > and that a clean implementation isn't really trivial since there is no > underlying Emcas support structure (like there is for documentation, > cross-referencing, diagnostics, snippets, etc) What infrastructure would be needed? Perhaps you or someone would like to describe the missing infrastructure, and we could then at least add that to TODO. And maybe someone would even like to work on that. Thanks. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-24 15:48 ` Eli Zaretskii @ 2024-09-24 21:01 ` João Távora 2024-09-25 11:31 ` Eli Zaretskii 0 siblings, 1 reply; 20+ messages in thread From: João Távora @ 2024-09-24 21:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 73452, federico.beffa On Tue, Sep 24, 2024 at 4:48 PM Eli Zaretskii <eliz@gnu.org> wrote: > > > Cc: 73452@debbugs.gnu.org > > From: João Távora <joaotavora@gmail.com> > > Date: Tue, 24 Sep 2024 15:26:55 +0100 > > > > There is a discussion thread about this in the Eglot GitHub downstream tracker. > > > > https://github.com/joaotavora/eglot/pull/71 > > > > The current consensus there is that the feature is not _that_ useful, > > and that a clean implementation isn't really trivial since there is no > > underlying Emcas support structure (like there is for documentation, > > cross-referencing, diagnostics, snippets, etc) > > What infrastructure would be needed? It's not easy to describe, you'd have to be very familiar with how code lens work on VSCode and Visual Studio (I'm not). It's a cross between Flymake and Eglot's custom inlay hints. The lower-level infrastructure (buttons, overlays, jit-lock-register) exists and is probably enough for a decent experience (though there are the typical annoying flaws with overlays and jit-lock-register). The problem is knowing how to tie this together in an sensible and robust infrastructure that Eglot (or other providers) can plug into. An abstraction that will model something presumably more useful and practical than what is already available through other existing Emacs means (vc-* commands, M-x compile, Eglot code actions). Read the last parts of the discussion I linked to if you're interested. João ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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-27 0:20 ` Dmitry Gutov 0 siblings, 2 replies; 20+ messages in thread From: Eli Zaretskii @ 2024-09-25 11:31 UTC (permalink / raw) To: João Távora; +Cc: 73452, federico.beffa > From: João Távora <joaotavora@gmail.com> > Date: Tue, 24 Sep 2024 22:01:02 +0100 > Cc: federico.beffa@fbengineering.ch, 73452@debbugs.gnu.org > > > What infrastructure would be needed? > > It's not easy to describe, you'd have to be very familiar with how > code lens work on VSCode and Visual Studio (I'm not). It's a cross > between Flymake and Eglot's custom inlay hints. > > The lower-level infrastructure (buttons, overlays, jit-lock-register) exists > and is probably enough for a decent experience (though there are > the typical annoying flaws with overlays and jit-lock-register). The problem > is knowing how to tie this together in an sensible and robust infrastructure > that Eglot (or other providers) can plug into. An abstraction that will model > something presumably more useful and practical than what is already > available through other existing Emacs means (vc-* commands, M-x compile, > Eglot code actions). Then maybe someone could describe such an abstraction. > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 2024-09-27 0:20 ` Dmitry Gutov 1 sibling, 1 reply; 20+ messages in thread From: João Távora @ 2024-09-26 8:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 73452, federico.beffa On Wed, Sep 25, 2024 at 12:31 PM Eli Zaretskii <eliz@gnu.org> wrote: > Then maybe someone could describe such an abstraction. Maybe. > > 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 2024-09-26 17:12 ` João Távora 2024-09-27 5:55 ` Eli Zaretskii 0 siblings, 2 replies; 20+ messages in thread From: Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-09-26 15:35 UTC (permalink / raw) To: João Távora, Eli Zaretskii; +Cc: 73452 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-26 15:35 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 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-27 5:55 ` Eli Zaretskii 1 sibling, 1 reply; 20+ messages in thread From: João Távora @ 2024-09-26 17:12 UTC (permalink / raw) To: Federico Beffa; +Cc: 73452, Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 1699 bytes --] On Thu, Sep 26, 2024 at 4:35 PM Federico Beffa < federico.beffa@fbengineering.ch> wrote: > 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. Like Eli said: design and _fully_ specify a model of user interaction with this feature and present it. Doesn't have to be a funcional prototype, a mockup of some sort will do, as long as it is specified enough for future implementers to understand edge cases. I.e. it's not enough to say "I want this thingy here like VSCode". Think what happens if text is inserted before, inside or after, the locus of the "code lens" annotation (if any). What happens if the text is deleted. What conditions, if any, lead to invalidation of the lens's information and what happens on said information. Anticipate the all-too-frequent "this thing flickers and its annoying" complaint and how to possibly deal with it. How it should work (if at all) in non-GUI Emacs. All of that is work that needs to be done, you don't need to be an Emacs/Eglot wiz. I personally don't see enough motivation to do it. I had for inlay hints, and I had to answer all those questions before implementing it. > 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. From what I was able to gather from other's reports , these features are already available to users in one form or another. Indeed, the examples you show here could all be done with code actions. João [-- Attachment #2: Type: text/html, Size: 2055 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 0 siblings, 1 reply; 20+ messages in thread From: Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-09-26 19:07 UTC (permalink / raw) To: João Távora; +Cc: 73452, Eli Zaretskii [-- Attachment #1: Type: text/plain, Size: 440 bytes --] On 26/09/2024 19:12, João Távora wrote: > On Thu, Sep 26, 2024 at 4:35 PM Federico Beffa > <federico.beffa@fbengineering.ch> wrote: > ... > Indeed, the examples you show here could all be done > with code actions. You are right, but, as already mentioned, many language server implementors decided otherwise and that's not going to change because Emacs doesn't like code lenses. Anyway, you made your point and that's fair enough. [-- Attachment #2: Type: text/html, Size: 1180 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 0 siblings, 0 replies; 20+ messages in thread From: Dmitry Gutov @ 2024-09-26 23:47 UTC (permalink / raw) To: Federico Beffa, João Távora; +Cc: 73452, Eli Zaretskii Hi! On 26/09/2024 22:07, Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > You are right, but, as already mentioned, many language server > implementors decided otherwise and that's not going to change because > Emacs doesn't like code lenses. I think the above would be a hasty conclusion: Emacs doesn't like or dislike them, but indeed we don't have an existing built-in UI to plug that feature in. lsp-mode implements it with some custom code. Maybe we could do a similar thing as the first step for Eglot (someone will need to do the work, though), but of course it would be nice to make at least a part of the addition reusable. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-26 15:35 ` Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-09-26 17:12 ` João Távora @ 2024-09-27 5:55 ` Eli Zaretskii 1 sibling, 0 replies; 20+ messages in thread From: Eli Zaretskii @ 2024-09-27 5:55 UTC (permalink / raw) To: Federico Beffa; +Cc: 73452, joaotavora > Date: Thu, 26 Sep 2024 17:35:21 +0200 > Cc: 73452@debbugs.gnu.org > From: Federico Beffa <federico.beffa@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? ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-25 11:31 ` Eli Zaretskii 2024-09-26 8:09 ` João Távora @ 2024-09-27 0:20 ` Dmitry Gutov 2024-09-27 6:53 ` Eli Zaretskii 2024-10-02 11:57 ` Felician Nemeth 1 sibling, 2 replies; 20+ messages in thread From: Dmitry Gutov @ 2024-09-27 0:20 UTC (permalink / raw) To: Eli Zaretskii, João Távora; +Cc: 73452, federico.beffa On 25/09/2024 14:31, Eli Zaretskii wrote: >> 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. It seems to me that a brief description would be "buttons that do things", but unlike Code Actions - already available in Eglot - those things don't typically alter the text that they act on. A LSP-generic mechanism to position those buttons at places in code which are recognized by the LSP server. For the LSP spec: /** * A code lens represents a command that should be shown along with * source text, like the number of references, a way to run tests, etc. * ... Running tests is the #1 use I found for them when writing some Go recently. Eglot doesn't have a built-in test launcher of any sort, so that feels like an omission. There are other lenses for Go (enumerated here: https://go.googlesource.com/tools/+/master/gopls/doc/codelenses.md), and they do sound useful, but less essential in comparison. And I would probably agree that the examples from the original PR are not that impressive (we already know how to search for references, and we know that that action works with every symbol - more or less, and we know how to access VC information - or in any case this would be the same across languages, or without LSP). It seems the strongest point of code lenses is advertising actions specific to language and/or to a context within the source code file (such as, again, launching tests). So the user is made aware of the capability. Admittedly, this seems more useful with some servers than others: gopls, rust-analyzer and ruby-lsp have test runner (and debugger) lenses, whereas clangd and typescript-language-server only have the "references" thing - I guess the usages count is nice, but it's much less essential. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2024-09-27 6:53 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 73452, federico.beffa, joaotavora > Date: Fri, 27 Sep 2024 03:20:35 +0300 > Cc: 73452@debbugs.gnu.org, federico.beffa@fbengineering.ch > From: Dmitry Gutov <dmitry@gutov.dev> > > It seems to me that a brief description would be "buttons that do > things", but unlike Code Actions - already available in Eglot - those > things don't typically alter the text that they act on. This seems to be in contradiction with what's been said previously (and my understanding from reading the linked pages): that code lenses are UI sugar for server actions. (If this is different from "Code Actions", then I guess there's some subtlety here I don't get yet.) You yourself say later that "the strongest point of code lenses is advertising actions specific to language and/or to a context", which seems to affirm my understanding. And since Eglot already supports actions, what seems to be missing is that UI sugar, i.e. a way of presenting the lenses and a way for the user to select those he/she wants to invoke. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-27 6:53 ` Eli Zaretskii @ 2024-09-27 19:27 ` Dmitry Gutov 0 siblings, 0 replies; 20+ messages in thread From: Dmitry Gutov @ 2024-09-27 19:27 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 73452, federico.beffa, joaotavora On 27/09/2024 09:53, Eli Zaretskii wrote: >> Date: Fri, 27 Sep 2024 03:20:35 +0300 >> Cc: 73452@debbugs.gnu.org, federico.beffa@fbengineering.ch >> From: Dmitry Gutov <dmitry@gutov.dev> >> >> It seems to me that a brief description would be "buttons that do >> things", but unlike Code Actions - already available in Eglot - those >> things don't typically alter the text that they act on. > > This seems to be in contradiction with what's been said previously > (and my understanding from reading the linked pages): that code lenses > are UI sugar for server actions. There is no such term as "server action" in LSP, so the above statement is probably both true and false at the same time. But lenses are not sugar on top of code actions, if that's what you means. > (If this is different from "Code> Actions", then I guess there's some subtlety here I don't get yet.) They are different parts of the LSP protocol, even though, practically, some "actions" could be implemented as either. Anyway to quote from https://go.googlesource.com/tools/+/master/gopls/doc/features/transformation.md: A code action is an action associated with a portion of the file. Each time the selection changes, a typical client makes a textDocument/ codeAction request for the set of available actions, then updates its UI elements (menus, icons, tooltips) to reflect them. The VS Code manual describes code actions as “Quick fixes + Refactorings”. A codeAction request delivers the menu, so to speak, but it does not order the meal. Once the user chooses an action, one of two things happens. In trivial cases, the action itself contains an edit that the client can directly apply to the file. But in most cases the action contains a command, similar to the command associated with a code lens. ... The main difference between code lenses and code actions is this: * a codeLens request obtains commands for the entire file. Each command specifies its applicable source range, and typically appears as an annotation on that source range. * a codeAction request obtains commands only for a particular range: the current selection. All the commands are presented together in a menu at that location. To give a couple of example: 'rename' is a code action, whereas 'run the test near point' is a code lens. Because the server will tell you which tests are defined in the current file and at which positions. > You yourself say later that "the strongest point of code lenses is > advertising actions specific to language and/or to a context", which > seems to affirm my understanding. And since Eglot already supports > actions, what seems to be missing is that UI sugar, i.e. a way of > presenting the lenses and a way for the user to select those he/she > wants to invoke. Yes, and what might be missing is not really a UI feature (we know how to print buttons, after all), but higher-level decisions, I guess, for how and when to print such buttons. It shouldn't be very difficult to implement, but people might disagree on the finer details of behavior. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-27 0:20 ` Dmitry Gutov 2024-09-27 6:53 ` Eli Zaretskii @ 2024-10-02 11:57 ` Felician Nemeth 2024-10-02 23:26 ` Dmitry Gutov 1 sibling, 1 reply; 20+ messages in thread From: Felician Nemeth @ 2024-10-02 11:57 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 73452, Eli Zaretskii, federico.beffa, João Távora Dmitry Gutov <dmitry@gutov.dev> writes: > Running tests is the #1 use I found for them when writing some Go > recently. Eglot doesn't have a built-in test launcher of any sort, so > that feels like an omission. Rust-analyzer has some protocol extensions to work together with a remote "Test Explorer". It seems a test explorer module is part of Visual Studio and VS Code. I think a similar Emacs package that lets the user organize/run tests and review test results would be a good ELPA package. (Even if it does not work with Eglot at the beginning.) https://learn.microsoft.com/en-us/visualstudio/test/run-unit-tests-with-test-explorer?view=vs-2022 https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp-extensions.md#test-explorer ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-10-02 11:57 ` Felician Nemeth @ 2024-10-02 23:26 ` Dmitry Gutov 2024-10-03 22:43 ` João Távora 0 siblings, 1 reply; 20+ messages in thread From: Dmitry Gutov @ 2024-10-02 23:26 UTC (permalink / raw) To: Felician Nemeth Cc: 73452, Eli Zaretskii, federico.beffa, João Távora On 02/10/2024 14:57, Felician Nemeth wrote: > Dmitry Gutov<dmitry@gutov.dev> writes: > >> Running tests is the #1 use I found for them when writing some Go >> recently. Eglot doesn't have a built-in test launcher of any sort, so >> that feels like an omission. > Rust-analyzer has some protocol extensions to work together with a > remote "Test Explorer". It seems a test explorer module is part of > Visual Studio and VS Code. I think a similar Emacs package that lets > the user organize/run tests and review test results would be a good ELPA > package. (Even if it does not work with Eglot at the beginning.) > > https://learn.microsoft.com/en-us/visualstudio/test/run-unit-tests-with- > test-explorer?view=vs-2022 > https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp- > extensions.md#test-explorer That looks useful, thank you. I wonder how many of the popular servers implement this, though. And what UI an Emacs implementation should prefer (overall that seems a fair bit more work than adding buttons inside Eglot-managed buffers). ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-10-02 23:26 ` Dmitry Gutov @ 2024-10-03 22:43 ` João Távora 2024-10-07 23:33 ` Dmitry Gutov 0 siblings, 1 reply; 20+ messages in thread From: João Távora @ 2024-10-03 22:43 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 73452, federico.beffa, Eli Zaretskii, Felician Nemeth FTR found this other discussion about code lens in Eglot. https://github.com/joaotavora/eglot/discussions/1376 On Thu, Oct 3, 2024 at 12:26 AM Dmitry Gutov <dmitry@gutov.dev> wrote: > > On 02/10/2024 14:57, Felician Nemeth wrote: > > Dmitry Gutov<dmitry@gutov.dev> writes: > > > >> Running tests is the #1 use I found for them when writing some Go > >> recently. Eglot doesn't have a built-in test launcher of any sort, so > >> that feels like an omission. > > Rust-analyzer has some protocol extensions to work together with a > > remote "Test Explorer". It seems a test explorer module is part of > > Visual Studio and VS Code. I think a similar Emacs package that lets > > the user organize/run tests and review test results would be a good ELPA > > package. (Even if it does not work with Eglot at the beginning.) > > > > https://learn.microsoft.com/en-us/visualstudio/test/run-unit-tests-with- > > test-explorer?view=vs-2022 > > https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/lsp- > > extensions.md#test-explorer > > That looks useful, thank you. > > I wonder how many of the popular servers implement this, though. And > what UI an Emacs implementation should prefer (overall that seems a fair > bit more work than adding buttons inside Eglot-managed buffers). -- João Távora ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-10-03 22:43 ` João Távora @ 2024-10-07 23:33 ` Dmitry Gutov 0 siblings, 0 replies; 20+ messages in thread From: Dmitry Gutov @ 2024-10-07 23:33 UTC (permalink / raw) To: João Távora Cc: 73452, federico.beffa, Eli Zaretskii, Felician Nemeth On 04/10/2024 01:43, João Távora wrote: > FTR found this other discussion about code lens in Eglot. > > https://github.com/joaotavora/eglot/discussions/1376 Thanks, this one seems to have progressed less far than the other. But in both threads there are screenshots, that seems useful. They mention actions like Run/Debug/Run Doctest/Refresh (for code evaluation). ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 2024-09-24 14:26 ` João Távora 2024-09-24 15:48 ` Eli Zaretskii @ 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 1 sibling, 1 reply; 20+ messages in thread From: Federico Beffa via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-09-25 7:04 UTC (permalink / raw) To: João Távora; +Cc: 73452 [-- Attachment #1: Type: text/plain, Size: 484 bytes --] That's an interesting conclusion, but it's up to the servers to decide how to provide the information. Imagine if a web browser implementor would decide not to support an HTML tag used by a non-negligible percentage of web pages. On 24/09/2024 16:26, João Távora wrote: > There is a discussion thread about this in the Eglot GitHub downstream tracker. > > https://github.com/joaotavora/eglot/pull/71 > > The current consensus there is that the feature is not _that_ useful,... [-- Attachment #2: Type: text/html, Size: 1066 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#73452: Code lens support in eglot 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 0 siblings, 0 replies; 20+ messages in thread From: João Távora @ 2024-09-25 7:50 UTC (permalink / raw) To: Federico Beffa; +Cc: 73452 On Wed, Sep 25, 2024 at 8:04 AM Federico Beffa <federico.beffa@fbengineering.ch> wrote: > > That's an interesting conclusion, but it's up to the servers to decide how to provide the information. Imagine if a web browser implementor would decide not to support an HTML tag used by a non-negligible percentage of web pages. Alright, I imagined it. And I don't see the resemblance to this use case. I'm not opposed to anyone implementing it, I just don't see a very interesting cost/benefit. And neither do some of the people who originally proposed it, apparently. João ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2024-10-07 23:33 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).