Skip to content

x/tools/gopls: support autocompletion of unimported packages #31906

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
stamblerre opened this issue May 8, 2019 · 30 comments
Closed

x/tools/gopls: support autocompletion of unimported packages #31906

stamblerre opened this issue May 8, 2019 · 30 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsFix The path to resolution is known, but the work has not been done. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@stamblerre
Copy link
Contributor

See for microsoft/vscode-go#2484 for context.

@gopherbot gopherbot added this to the Unreleased milestone May 8, 2019
@gopherbot gopherbot added the gopls Issues related to the Go language server, gopls. label May 8, 2019
@andybons andybons added the NeedsFix The path to resolution is known, but the work has not been done. label May 8, 2019
@ramya-rao-a
Copy link

When this does get into gopls please send a PR or log an issue to the vscode Go plugin so that we can disable the similar feature (in non module mode) there to avoid duplicate suggestions

@zchee
Copy link
Contributor

zchee commented May 16, 2019

@stamblerre
Just a question.
Is this issue means only of stdlib like gocode?
Or, all of packages ingo.mod?

@stamblerre
Copy link
Contributor Author

It would be all available packages, not just stdlib.

@zchee
Copy link
Contributor

zchee commented May 16, 2019

@stamblerre
great.

Are you doing now develop this feature?
I do not know what you remember to me, but I maintained nsf/gocode for a while. If you not yet develop this feature, I would want to help you.

@stamblerre
Copy link
Contributor Author

I am not actively working on it yet, so you're absolutely welcome to get started on it.

@jackielii
Copy link

jackielii commented Jun 12, 2019

@stamblerre @saibing I found out that this is a difference between https://github.com/saibing/tools & https://github.com/golang/tools/tree/ : saibing/tools already have this feature:

image
screenshot from saibing/tools + coc.nvim + neovim nightly build

@stamblerre
Copy link
Contributor Author

From microsoft/vscode-go#2575:

There are really two components to this issue. For example (in both cases, time is not imported):

  1. Typing "ti<>" and getting package time as part of the autocompletion results.
  2. Typing "time.<>" and getting autocompletions for the members of package time.

@suzmue
Copy link
Contributor

suzmue commented Aug 27, 2019

https://golang.org/cl/190338 adds support for autocompletion of unimported standard library packages

This supports autocompletions in the first case listed above

  1. Typing "ti<>" and getting package time as part of the autocompletion results.

@suzmue suzmue assigned heschi and unassigned suzmue Aug 30, 2019
@gopherbot gopherbot added the Tools This label describes issues relating to any tools in the x/tools repository. label Sep 12, 2019
@islishude
Copy link
Contributor

It works now!

屏幕快照 2019-10-22 上午9 21 46

@chengyayu
Copy link

It works now!

屏幕快照 2019-10-22 上午9 21 46

does it works for go modules gpls? which version is it ?

@chengyayu
Copy link

chengyayu commented Oct 22, 2019

versions

  • vscode : 1.39.2
  • vscode-go: 0.11.7

my settings

 // go settings
    "go.buildOnSave": "off",
    "go.lintTool":"golangci-lint",
    "go.lintFlags": [
        "--fast"
    ],
    "go.useLanguageServer": true,
    "go.languageServerExperimentalFeatures": {
        "documentLink": false,
        "format": true,
        "autoComplete": true
    },
    "[go]": {
        "editor.snippetSuggestions": "none",
        "editor.formatOnSave": true,
        "editor.codeActionsOnSave": {
            "source.organizeImports": true
        }
    },
    "gopls": {
        "usePlaceholders": true,
        "completeUnimported": true,
    },

when i type this codes go internal package can be auto import, but third party package in my go.mod can not be import.

gopls output error

[Info  - 5:23:18 PM] 2019/10/22 17:23:18 no completions found
	Failure = cannot resolve grpc

@stamblerre
Copy link
Contributor Author

We don't yet have the exports loaded for the unimported packages, so it won't complete if you type grpc.. However, if you begin typing grpc, you will see the completions suggestions pop up, and then when you select one and hit enter, the corresponding import will be added so you can then add the period and get further completions from the package.

@chengyayu
Copy link

#31906 (comment)

Sorry No suggestions pop up

@stamblerre
Copy link
Contributor Author

@chengyayu: Are you using gopls at master? To install it, you have to clone the repo, cd into the gopls directory and run go install.

@chengyayu
Copy link

@chengyayu: Are you using gopls at master? To install it, you have to clone the repo, cd into the gopls directory and run go install.

yes! it works! thanks for your suggestions.

@neoli0222
Copy link

Does anybody know how to make this work for YCM in vim? I've tried to update the code of gopls (in YCM) to master, but the completion of unimported packages still doesn't work.

@110y
Copy link

110y commented Oct 25, 2019

When we're using go mod and enabling completeUnimported, gopls seems to suggest all modules in module caches. As a result, too many modules appear as candidates.

I think it is helpful that gopls only suggests modules that the project we are editing are depending on excepting indirect modules, isn't it?

@stamblerre
Copy link
Contributor Author

We haven't yet implemented ranking for unimported candidates, but I think that issue can be solved with improved rankings. The ordering should probably be something like standard library packages are preferred over dependencies in the main module followed by packages in the module cache.

We still want to suggest packages from the module cache that haven't been added as dependencies because users may still be interested in importing them.

@110y
Copy link

110y commented Oct 26, 2019

@stamblerre

Thank you for your response!

The ordering should probably be something like standard library packages are preferred over dependencies in the main module followed by packages in the module cache.

It sounds good!

We still want to suggest packages from the module cache that haven't been added as dependencies because users may still be interested in importing them.

I think we have several different needs for completeUnimported like below:

  1. do not complete unimported packages.
  2. complete only standard packages.
  3. 2 + direct dependent modules.
  4. 3 + indirect dependent modules.
  5. 4 + all module caches.

So, I think it is better that gopls provides the option to control completeUnimported behaviour (or change completeUnimported option from just bool type to string type like hoverKind) in addition to sorting you mentioned.
How about this?

@ianthehat
Copy link

I don't think the number of results matters, only the order in which they appear.
So long as the ranking is good, there is no need for any kind of control of filter of the nature you suggest, the editor can just limit the total number of candidates shown.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/204203 mentions this issue: internal/imports: sort import candidates by "relevance"

gopherbot pushed a commit to golang/tools that referenced this issue Oct 30, 2019

Verified

This commit was signed with the committer’s verified signature.
When proposing packages to import, we can propose more relevant packages
first. Introduce that concept to the pkg struct, and sort by it when
returning candidates.

In all cases we prefer stdlib packages first. Then, in module mode, we
prefer packages that are in the module's dependencies over those that
aren't. We could go further and prefer direct deps over indirect too,
but I didn't have the code for that handy.

I also changed the alphabetical sort from import path to package name,
because that's what the user sees first in the UI.

Updates golang/go#31906

Change-Id: Ia981ee9ffe3202e2a68eef3a36f65e81849a4ac2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204203
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/204204 mentions this issue: internal/imports: provide export completions for unimported packages

@hbd
Copy link

hbd commented Oct 31, 2019

@110y to @ianthehat's point, why have yet another option (or n+ options), if instead the packages are ranked by some hierarchy? e.g. (autocompletions ranked first to last)

  1. imported packages
  2. stdlib
  3. unimported packages
  4. ...

more options = more complexity = harder to maintain and for new users to understand

gopherbot pushed a commit to golang/tools that referenced this issue Nov 4, 2019
Add a function that returns all the exported identifiers associated with
a package name that doesn't have an import yet. This will allow
completions like rand<> to return rand.Seed (from math/rand) and
rand.Prime (from crypto/rand).

Updates golang/go#31906

Change-Id: Iee290c786de263d42acbfabd76bf0edbf303afc9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204204
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
@heschi
Copy link
Contributor

heschi commented Nov 7, 2019

I think the only thing left to do here is turn it on by default.

@muirdm
Copy link

muirdm commented Nov 7, 2019

What about the increased completion latency when there are a lot of unimported packages?

@zulhfreelancer
Copy link

@heschik

I think the only thing left to do here is turn it on by default.

How to turn it on currently?

@stamblerre
Copy link
Contributor Author

You can add the following to your VSCode settings:

"gopls": {
    "completeUnimported": true
}

@zulhfreelancer
Copy link

zulhfreelancer commented Nov 26, 2019

UPDATE

Working now after upgrading to Go 1.13.4 — sorry for the trouble.


@stamblerre thank you. Any idea why this popup keeps showing?

Screen Shot 2019-11-26 at 1 30 37 PM

I already have gopls installed by pressing that Update button. I also tried cloning github.com/golang/tools repo, and ran go install inside the gopls folder.

The popup remains there everytime I opened VS Code. Quitting doesn't help.

My environment:

  • OS: Mac OS 10.12.6
  • Go: go1.11.4 darwin/amd64
  • GO111MODULE: on
  • gopls: version 0.2.0, built in $GOPATH mode
  • VS Code: 1.40.1 (commit 8795a9889db74563ddd43eb0a897a2384129a619)

@stamblerre stamblerre modified the milestones: gopls v1.0, gopls/v0.3.0 Jan 15, 2020
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/214947 mentions this issue: internal/lsp/source: enable unimported completions by default

@golang golang locked and limited conversation to collaborators Jan 16, 2021
@rsc rsc unassigned heschi Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. NeedsFix The path to resolution is known, but the work has not been done. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests