feature request: autocomplete non imported packages

[trajber]

The Go plugin for IntelliJ has a very useful feature that allows code completion works even when the package is not imported yet.
On this example you can see "fmt" and "os" packages being used even with no imports at all.

[nsf]

People really hate import statements in golang aren't they.

While I'll leave the issue open, I don't think it happens any time soon. I understand why it can be useful, but gocode is only a part of equation here. Say gocode fails to resolve an identifier and then it tries to import a package that may fit. Do I return back the autocompletion result and a suggestion to add an import statement? What if editor doesn't follow that suggestion and doesn't add an import statement? User can be confused why gocode autocompletes something and compilation fails at the end.

Need to think about it.

[nhooyr]

If you're on neovim and use deoplete, zchee/deoplete-go implements this.

[th3noname]

I use the Atom editor with joefitzgerald/go-plus and have a similar problem.

If the package is not yet included in the import statement, then i don't get autocomplete suggestions and i need to open Godoc. The "problem" is that go-plus also uses goimports. If i now add the package to the import statement and save the file without using the package in the code, goimports removes it from the import statement.
This means that i always need to get the information on the first method call from a Godoc page. At least if i don't know it off the top of my head.

I would prefer to get autocomplete suggestions from the most likely package than no suggestions at all.

[Olivia5k]

I would personally not really have any problems with gocode adding the import of "os" as soon as I type the dot in os.. If the identifier before the dot resolves to something, I'm probably about to import it anyway.

Could that be a nice compromise for this?

[th3noname]

I think gocode doesn't normally modify the source code on its own. And there already is goimports to do that.

In my opinion it would be the best if gocode searched for the best fitting package (in most cases probably only one). Maybe prefer stdlib to external packages.

This functionality could be hidden behind a cli flag or a build parameter.

[zmb3]

I'd be interested in working on this if we can come to a consensus on how it should be done.

IMO, gocode doesn't need to add the import - we have goimports for that. I think a good first step would be to only offer suggestions for stdlib packages. It would keep the implementation simple and would offer immediate value.

[nsf]

It should be very easy to add though, maybe I'll try that tomorrow.

[nhooyr]

@zmb3 that is exactly what zchee/deoplete-go does. It builds a json cache of the stdlib packages and uses that to provide completions.

[nsf]

As usual, to try it out, don't forget to kill previously running gocode server:

go get -u github.com/nsf/gocode
gocode close
gocode set unimported-packages true
...
PROFIT

[nsf]

Right now gocode matches identifier against a built-in list of known package identifiers, you can find it here: https://github.com/nsf/gocode/blob/master/cursorcontext.go#L414-L557

Note that even in standard library there are some conflicts, like "text/template" and "html/template". I've made choices to prefer one over another based on my idea of popularity of those packages.

[nsf]

Program used for extracting default package identifiers:

package main

import "os"
import "go/importer"

func main() {
        pkgName := os.Args[1]
        pkg, err := importer.Default().Import(pkgName)
        if err != nil {
                panic(err)
        }
        os.Stdout.WriteString(pkg.Name())
}

[zmb3]

Works like a charm, thanks!

[dmitshur]

Note that even in standard library there are some conflicts, like "text/template" and "html/template". I've made choices to prefer one over another based on my idea of popularity of those packages.

goimports had to solve the same problem. Maybe it's a good idea to copy it's behavior, so that it's consistent. Otherwise it might be a bad experience if one tool tends to prefer similar package A but the other tool picks package B.

See https://github.com/golang/tools/commits/master/imports/zstdlib.go.

Also see relevant golang/tools@0835c73.

[nsf]

@shurcooL I don't think it's very important.