x/tools/gopls: support "go generate" via CodeLens #37680
Labels
FeatureRequest
Issues asking for a new feature that does not need a proposal.
FrozenDueToAge
gopls
Issues related to the Go language server, gopls.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Comments
gopherbot
added
Tools
stamblerre
added
the
FeatureRequest
|
Completely agree with the idea. We've had a similar issue opened here: #31817. I think the code lenses are a great starting point. I'm not sure if LSP has that functionality, as we haven't used any of the in-progress RPC features. Let's experiment with what's currently available, and if something seems to be missing, we can open issues with the LSP specification. Thanks for doing this work, @marwan-at-work! Looking forward to getting these features in |
marwan-at-work
added a commit
to marwan-at-work/tools
that referenced
this issue
Mar 6, 2020
This change adds support for recognizing a //go:generate directive and offering a CodeLens that will then send a "generate" command to the server to run "go generate" or "go generate ./...". Because "go generate" can only be executed per package, there is no need to show the CodeLens on top of every //go:generate comment. Therefore, only the top directive will be considered. The stdout/stderr of the go generate command will be piped to the logger while stderr will also be sent to the editor as a $/progress notification. Stderr in this case shows every command that go generate is running through the "-x" flag so that the user can be aware of the work in progress. Fixes golang/go#37680 Change-Id: I89a9617521eab20859cb2215db133f34fda856c7
|
Change https://golang.org/cl/222247 mentions this issue: |
marwan-at-work
added a commit
to marwan-at-work/tools
that referenced
this issue
Mar 11, 2020
This change adds support for recognizing a //go:generate directive and offering a CodeLens that will then send a "generate" command to the server to run "go generate" or "go generate ./...". Because "go generate" can only be executed per package, there is no need to show the CodeLens on top of every //go:generate comment. Therefore, only the top directive will be considered. The stdout/stderr of the go generate command will be piped to the logger while stderr will also be sent to the editor as a $/progress notification or a window/showMessage based on client capabilities. In the case of $/progress, Stderr shows every command that go generate is running through the "-x" flag so that the user can be aware of the work in progress. While with window/showMessage, the user will only know when the process starts and when it ends so that they wouldn't get bogged with a large number of message windows popping up. If a user wants to cancel the "go generate" command, they will be able to do so with either the window/workDoneProgress/cancel request or with a showMessageRequest ActionItem based on client capabilities. Fixes golang/go#37680 Change-Id: I89a9617521eab20859cb2215db133f34fda856c7
|
Change https://golang.org/cl/222981 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Mar 16, 2020
This CL adds support for sending progress notifications through $/progress calls as well as being able to cancel them through window/workDoneProgress/cancel. This feature is only supported in clients running LSP 3.15 and therefore the initialize request will check for client capabilities for its progress support. Updates golang/go#37680 Change-Id: Iff8c016694746a9dd553e5cc49444df7afcc21f5 Reviewed-on: https://go-review.googlesource.com/c/tools/+/222981 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
|
Change https://golang.org/cl/223739 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Mar 17, 2020
This commit will make the 'go generate' CodeLens command check the client capabilities to use $/progress to report the progress of the command or otherwise it will fallback to showing the message box already in place. The $/progress will give you a play by play update while the message box shows only the beginning and the end. The gopls logs will have all the details in either case. Note that the $/progress is an LSP 3.15+ feature and not yet supported in all clients. Updates golang/go#37680 Change-Id: I5ba37448be8e388f728394795e1bb5f1d50cc30d Reviewed-on: https://go-review.googlesource.com/c/tools/+/223739 Reviewed-by: Rebecca Stambler <rstambler@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
apstndb
pushed a commit
to apstndb/gotoolsdiff
that referenced
this issue
Jan 11, 2025
This change adds support for recognizing a //go:generate directive and offering a CodeLens that will then send a "generate" command to the server to run "go generate" or "go generate ./...". Because "go generate" can only be executed per package, there is no need to show the CodeLens on top of every //go:generate comment. Therefore, only the top directive will be considered. The stdout/stderr of the go generate command will be piped to the logger while stderr will also be sent to the editor as a window/showMessage The user will only know when the process starts and when it ends so that they wouldn't get bogged with a large number of message windows popping up. However, they can check the logs for all the details. If a user wants to cancel the "go generate" command, they will be able to do so with a "Cancel" ActionItem that the server will offer to the client Fixes golang/go#37680 Change-Id: I89a9617521eab20859cb2215db133f34fda856c7 Reviewed-on: https://go-review.googlesource.com/c/tools/+/222247 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
TL;DR:
It would be helpful if gopls recognized
//go:generatedirectives in Go files and offered the option to run "go generate" from the editor through a CodeLens. Here's a demonstration video: https://vimeo.com/395630819Motivation - feel free to skip if you are already convinced :)
Code generation is widely used in Go projects. The
//go:generatecommand makes long and tedious commands much easier to execute by just runninggo generateorgo generate ./....However, whenever a programmer wants to regenerate the code, they end up doing some context switching from their editor to the terminal to regenerate the code.
Therefore, if the editor understood the
//go:generatedetective and offered to rungo generateon the user's behalf, then the programmer can remain within the editor and not worry about switching contexts.VSCode already does this with Go Test functions by giving you the option to run tests from within the UI. The "go generate" feature was actually requested for a few years in the VSCode extension but was never implemented: microsoft/vscode-go#263
Therefore, I think gopls is the right place to offer this functionality as the feature is very Go-specific.
Implementation question
The video above is from an initial implementation I wrote here: https://github.com/golang/tools/compare/master...marwan-at-work:gg?expand=1
The CodeLens part seems super straightforward. However, the moment we click on "go generate" and the client sends the command back to gopls, we need to show the stdout/stderr of "go generate" back to the client.
The one supported way I saw was using the
$/progressserver->client rpc which lets you show one message at a time. Each message shows as a progress bar on the bottom right in VSCode. However, would it be more appropriate to show this as a window instead of a progress bar?If so, does the LSP provide a way to tell the editor to open a window and show a stream of logs?
In any case, if everyone is happy with this proposal, I'm happy to add tests and contribute the implementation above!
The text was updated successfully, but these errors were encountered: