x/tools/gopls: provide function that gives list of candidate imports matching pattern

[myitcv]

What version of Go are you using (go version)?

$ go version
go version devel +44c9354c5a Fri Jun 21 05:21:30 2019 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20190620191750-1fa568393b23
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20190620191750-1fa568393b23

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/myitcv/gostuff/src/github.com/myitcv/govim/cmd/govim/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build670036660=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Much like gopls offers completion candidates, it should provide a function that allows editors to tab-complete/fuzzy match/whatever packages to import.

For example, in govim we want to provide the command GOVIMAddImport such that when we type:

:GOVIMAddImport en<Tab>

(where <Tab> is us looking to complete the import), we should be able to call gopls and get a list of import candidates matching en (according to some algorithm)

Reference: govim/govim#317

---

cc @stamblerre @ianthehat

[stamblerre]

I think this fits into the functionality covered by #31906, or is there anything else that we should add to that issue?

[myitcv]

@stamblerre - I think they're different. In this case I'm looking to provide a command that can be run in normal mode (which is the mode in which you can issue commands to Vim).

:GOVIMAddImport en<Tab>

Reason being, not everyone does/will think that completion is the way to add an import.

But also because this will likely become the primary way of adding named imports, e.g.:

import qt "github.com/frankban/quicktest"

Would be added via:

:GOVIMAddImport github.com/frankban/quicktest=qt

or similar.

[stamblerre]

What LSP request would this command map to?

[myitcv]

That's really part of the reason for me raising the issue. The short answer is: I don't know 😄

Is there not any scope for an LSP implementation providing additional methods, beyond the spec?

[stamblerre]

Not that I'm aware of, though we can certainly raise this with https://github.com/microsoft/language-server-protocol. What's the justification behind users wanting to manually add imports rather than using goimports-type behavior?

[myitcv]

As i mentioned in #32749 (comment), because this will be the primary (only?) way of adding a named import.

[stamblerre]

My best guess for how this could work with the current state of gopls is that you automatically add an import using a quick fix, and then you rename it (I believe @suzmue intends to support that behavior, but it hasn't been added yet). govim would have to do the task of combining those 2 together.

[myitcv]

But this won't work where you already have an identifier in scope which has the name of the package being imported, which is exactly why I'd be looking to have a named import.

[myitcv]

Another case where this is required (just stumbled across it again, which reminded me): where you import a package for its side effects.

[suzmue]

It seems like it would require a change to the lsp spec to provide the exact function you are looking for, but there are a few ways I could see something similar potentially fitting in to gopls:

1. autocomplete in import spec (import qt "gith<>)
2. try to resolve imports by ignoring package name and provide the renamed package import (fix: Add import qt "github.com/pkg")
3. Provide multiple quick fixes to choose from that would satisfy the missing import.

With finer control about what import fixes are applied, which we are working on supporting, these seem like things that would be possible.