gocode: switch to https://github.com/mdempsky/gocode

[bhcleek]

nsf/gocode is not working well with Go 1.10. I just encountered it
myself again. The author of original gocode also states and recommends
the mdempsky/gocode fork over nsf/gocode:
https://github.com/nsf/gocode#an-autocompletion-daemon-for-the-go-programming-language

We actually moved once, but
because we didn't removed the obsolote settings, we weren't prepared for
issues that were
reported, and hence
reverted it back

This PR also removes all settings. The reason is that the new gocode
doesn't support settings anymore. The author decided not the support it.

• For autobuild, this was removed because the author believe it's not
  worth tackling it inside gocode: auto install doesn't always work mdempsky/gocode#13
• For propose builtins, this is actually still supported but disabled in
  the source code, we need to add it back again in the future:
  mdempsky/gocode@787cfae
• For unimported packages: this was just removed and I couldn't find
  upcoming plans for it

Going forward this package seems to be more stable and is a better bet.
Most important, as I stated nfs/gocode is not 1.10 compatible and the
author has no intentions to fix it.

[bhcleek]

Continuation of #1851

[bhcleek]

@fatih I can't get this to work at all. I never get autocompletion results and type info is never displayed when g:go_info_mode='gocode'. nsf/gocode works fine for me, though.

Without the autobuild option, I wonder if we don't need to go install -i sometimes so that users will get accurate results 🤔

As a reminder to myself (and anyone else that tests): when testing, it's important to make sure to kill any running gocode processes before trying the other gocode fork. With nsf/gocode, the command is gocode close. For mdempsky/gocode, the command is gocode exit.

Here's the basic test procedure:

1. stop any running gocode server processes
2. set g:go_info_mode='gocode'
3. set g:go_auto_type_info=1
4. open a Go file
5. position the cursor over an identifier and verify that the command-line display the type information for the identifer.
6. Test autocompletion.

[bhcleek]

I'm getting inconsistent results. Sometimes autocomplete with mdempsky/gocode works, and sometimes it doesn't; I'll try to create some reproducible failures in a simple file.

[bhcleek]

The problem I was experiencing was that I hadn't done go install with one of the packages that is a dependency of the file in which I was trying to use autocompletion. With this PR as-is, because mdempsky/gocode doesn't support autobuild, users will have to go install all dependencies to get autocompletion to work correctly. That seems like a pretty big step backwards.

Without the autobuild feature, the utility of gocode goes way down. Interestingly, all the complaints in nsf/gocode about Go's package cache seem to be irrelevant when autobuild is enabled. Others seem to be reporting the same thing: nsf/gocode#500 (comment)

I see four possibilities to resolve these concerns:

1. close this PR without merging; I have yet to see any problems with nsf/gocode when autobuild is enabled.
2. wait to merge this PR until after mdempsky/gocode's cache branch is merged.
3. use mdempsky/gocode's -source flag so that autocompletion doesn't need to packages to be installed to work. From a purist standpoint, I like this option the best, but performance of mdempsky/gocode's source importer is currently poor: autocompletion takes about 1.5 seconds 😞 .
4. Implement our own mechanism for installing out-of-date packages and their dependencies.

Technically, this PR lgtm, but I don't think we should merge it due to the usability concerns.

[fatih]

I see that autobuild is a very useful feature. I'm not happy myself either. However the bigger issue is that nfs/gocode straight up refuses to work anymore. I've tried everything, installing a new version, purging GOPATH/pkg, etc.. It just doesn't work anymore.

I could live with that if the author (nfs) had any intentions to fix the issue, but it's not. If we go this way, we'll end up having a crippled, not maintained autocompletion daemon. It will hurt more in the long term.

I totally understand that missing autobuild or other features sucks, but at least the project is active. The Go team also actively works on improving the current loaders and tools. Which means things like --source will eventually be very fast. Once that is the case, we'll just add that support (we can add it even today, but it wouldn't make sense due the slowness).

It's a double edged sword, but I think it should be merged because nfs/gocode is broken, doesn't work and going forward will be not fixed in any case.

[bhcleek]

Let's merge it then and deal with the problems it introduces. Before you do that, though, I only have one quick question: have you tried running the nsf/gocode server with the -debug flag to see what's going wrong?

[fatih]

It's weird. After installing nfs/godoce again, deleting the old binary and starting with gocode -debug -s it started working again. I wonder what was the issue here :/

[ramya-rao-a]

Hello @fatih and @bhcleek,

I am very glad to have found this thread. I want to share some of my findings from the Go plugin to VS Code's perspective

• We found that using the autoBuild option of nsf/gocode was slowing things down. We disabled this option (user could enable it if they wanted to) last November. We were able to do this as we use the -i flag when the code is built on save. See 0.6.67 makes typing in a medium-sized project too laggy microsoft/vscode-go#1323 (comment) and 0.6.67 makes typing in a medium-sized project too laggy microsoft/vscode-go#1323 (comment). I am curious, did you ever have perf issues by enabling this option?
• We moved to using mdempsky/gocode this June when we got complaints on completions just not working on 1.10 and above. I didnt make the connection between autoBuild feature of gocode and this issue before, and so the only option I had was to make the move to using the fork
• We use the -builtin flag when using mdempsky/gocode which is the counterpart to nsf/gocode's propose builtin
• We also found that using -source slows things down significantly and so we dont use it as of now and are also hoping that the cache branch gets merged soon
• We also have users who are using nsf/gocode with Go 1.10 and above who dont see any issues.

In conclusion, I do wish we had a unified solution here, but there isnt seem to be any. I am gate crashing this thread in hopes of being notified of further discussions in this space.

[bhcleek]

I am curious, did you ever have perf issues by enabling this option?
I've never noticed any performance issues specifically related to using autobuild, but I can certainly imagine that there could be performance issues when large packages have to be rebuilt.

Although we didn't see performance issues specifically related to autobuild, we did see some performance issues with gocode, especially when calls to gocode had to be executed synchronously. Those issues were mostly resolved in #1697.

We also found that using -source slows things down significantly and so we dont use it as of now and are also hoping that the cache branch gets merged soon

Yes, the -source flag is too slow without caching. Once the caching branch is merged and is stable, we will likely switch to using mdempsky/gocode.

[joshuarubin]

FWIW, I've had to switch to github.com/visualfc/gocode as it's the only version that supports the upcoming Go modules.

[bhcleek]

@joshuarubin thank you for the tip. We've been discussing the work that needs to be done to vim-go to support modules.

[isaachess]

I'm currently experiencing a severe slowdown in performance from using autobuild. I'm using vim 8.1, go1.10.3 linux/amd64. If I don't disable gocode's autobuild, on some files I experience a full 5-to-10-second delay between pressing the . and seeing the autocomplete results. When I disable autobuild the results appear instantaneously (though I assume will eventually get out of date).

For now I've disabled autobuild, otherwise gocode has become completely unusable for me.

[bhcleek]

Builtins are now supported again, so I've added that option back in.

The source mode is slow on big projects, but is easier to work with, because packages don't have to be installed manually. I've added an option to use it source mode, but it's disabled by default so that users can opt-in.

[bhcleek]

@fatih Given that nsf/gocode panics on Go 1.11 packages due to changes in the export format, I think it's time to merge this. WDYT?

[fatih]

lgtm

@bhcleek let's do it. nfs is a dead end. There is not much we can do here as we know. Let's continue with mdempsky's fork.

[ramya-rao-a]

awesome! Thats 3 out of 3. Now vim-go, go-plus and vscode-go all use mdempsky's fork. Meaning we all will see the same issues and can look into finding solutions.