Skip to content
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

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

Open
stamblerre opened this issue May 8, 2019 · 28 comments
Assignees
Milestone

Comments

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented May 8, 2019

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

@ramya-rao-a

This comment has been minimized.

Copy link

@ramya-rao-a ramya-rao-a commented May 9, 2019

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

This comment has been minimized.

Copy link
Contributor

@zchee 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

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented May 16, 2019

It would be all available packages, not just stdlib.

@zchee

This comment has been minimized.

Copy link
Contributor

@zchee 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

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented May 20, 2019

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

@jackielii

This comment has been minimized.

Copy link

@jackielii 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

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Jun 18, 2019

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

This comment has been minimized.

Copy link
Contributor

@suzmue 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 heschik and unassigned suzmue Aug 30, 2019
@gopherbot gopherbot added the Tools label Sep 12, 2019
@heschik

This comment has been minimized.

Copy link
Contributor

@heschik heschik commented Oct 21, 2019

At master, gopls now supports completing all unimported packages. There may still be performance issues, but the functionality exists.

@islishude

This comment has been minimized.

Copy link

@islishude islishude commented Oct 22, 2019

It works now!

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

@chengyayu

This comment has been minimized.

Copy link

@chengyayu chengyayu commented Oct 22, 2019

It works now!

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

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

@chengyayu

This comment has been minimized.

Copy link

@chengyayu 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

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Oct 22, 2019

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

This comment has been minimized.

Copy link

@chengyayu chengyayu commented Oct 23, 2019

#31906 (comment)

Sorry No suggestions pop up

@stamblerre

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Oct 23, 2019

@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

This comment has been minimized.

Copy link

@chengyayu chengyayu commented Oct 23, 2019

@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.

@lpy-neo

This comment has been minimized.

Copy link

@lpy-neo lpy-neo commented Oct 24, 2019

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

This comment has been minimized.

Copy link

@110y 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

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Oct 25, 2019

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

This comment has been minimized.

Copy link

@110y 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

This comment has been minimized.

Copy link

@ianthehat ianthehat commented Oct 26, 2019

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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Oct 30, 2019

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
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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Oct 30, 2019

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

@hbd

This comment has been minimized.

Copy link

@hbd 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>
@heschik

This comment has been minimized.

Copy link
Contributor

@heschik heschik commented Nov 7, 2019

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

@muirdm

This comment has been minimized.

Copy link

@muirdm muirdm commented Nov 7, 2019

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

@zulhfreelancer

This comment has been minimized.

Copy link

@zulhfreelancer zulhfreelancer commented Nov 8, 2019

@heschik

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

How to turn it on currently?

@stamblerre

This comment has been minimized.

Copy link
Contributor Author

@stamblerre stamblerre commented Nov 8, 2019

You can add the following to your VSCode settings:

"gopls": {
    "completeUnimported": true
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.