You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that gopls will be on by default, vscode should delegate its remaining non-lsp functionality to gopls through nonStandardRequest, if said feature makes sense to be moved there.
Starting with the "go.add.imports" command as an example, the "Add Import" action should be a good first migration and it has a number of benefits:
The logic is straightforward and most of it already exists in gopls
The vscode-go implementation is currently using regex to parse an import statement and always adds imports to the top of the line, while gopls can more nicely add an import line in the correct place within an import block.
gopls can filter the list in a much smarter way than the client such as: filtering out already-imported packages, filtering out un-importable internal packages and cyclic imports.
The existence of this method in gopls will also open the door to other editors to use it since some of these functionalities are quite Go specific and are likely not going to make it into the LSP spec.
Once this logic is both in vscode and gopls, more custom features can be proposed to be added to gopls such as "listing all interfaces in a workspace" and "picking an interface to implement" without having to wait for a diagnostic error, etc.
If this looks okay to everyone, I have a couple of working branches for both repos I'd be happy to contribute: here and here
The text was updated successfully, but these errors were encountered:
This CL adds two new commands that let a client request a list of importable packages relative to a Go file and then select which import a programmer would like to add to said file.
Trust: Rebecca Stambler <firstname.lastname@example.org>
Trust: Robert Findley <email@example.com>
Run-TryBot: Rebecca Stambler <firstname.lastname@example.org>
gopls-CI: kokoro <email@example.com>
TryBot-Result: Go Bot <firstname.lastname@example.org>
Reviewed-by: Rebecca Stambler <email@example.com>
I was about to file a quality issue about the quality of gopls.list_known_packages and remembered this issue.
VS Code Go's "go.import.add" (aka "Go: Add Import") was migrated to use gopls.list_known_packages a while ago. Should we continue the quality improvement discussion in this thread, or should we open another issue (because the goal for this issue is already achieved)? @findleyr
Currently gopls.list_known_packages returns results in lexicographical order which is not very useful. And it also includes unimportable packages (e.g. internal/* and vendor/*). The list can be also quite long (I think #32749 may help here).
There are also #32749 and #48545.
They are similar but not exactly capture my feature request.