nsf / gocode

An autocompletion daemon for the Go programming language
MIT License
5.01k stars 657 forks source link

Code completition not properly working for subpackages #233

Open wanton7 opened 10 years ago

wanton7 commented 10 years ago

I have a problem where gocode isn't autobuilding my package when i've used "set autobuild true" and got output "autobuild true"

i have packages business and subpackage object and inside object I have user.go

directory structure

business/user_manager.go (business package) business/object business/object/user.go (object package) site/main.go (main package)

Code completition stops working for user.go after a while. I think it's after .a file is build from business package. Seems that gocode doesn't notice changes in subpackage

I also used gocode -debug and found out that autocompletion is only searching business.a not object.a .

If I do "go install" for object package gocode still can't find changes to user.go. But if I do "go install" for business package gocode finds changes I have done to user.go in object package.

My OS is windows 7 64bit.

wanton7 commented 10 years ago

main.go isn't importing package object. It's only importing package business.

tiziano88 commented 10 years ago

The autobuild functionality is still a work in progress, I would not rely on it too much at this point. I'll look into the issue soon anyway.

nsf commented 10 years ago

The truth is that in Go a package contains all the info it needs to do all the type analysis, even the info from imported packages. So it may happen that gocode reads info about the 'object' package from 'business' package. If you invoke it from a package which imports 'business' only. Therefore rebuilding 'object' won't affect the 'business' package in any way and what it knows about 'object'. That leads to an impression that gocode doesn't see changes in 'object', but in fact it doesn't look into 'object' at all as you've seen with -debug output. So, what happens with go install is expected behaviour. However, autobuild feature is supposed to handle that kind of scenario. But as @tiziano88 said and he's the author of the feature, so I'll leave that on him.

nsf commented 10 years ago

For now I've added a note to the readme that "autobuild" feature is experimental.

nathany commented 10 years ago

I've have a similar issues with gotype where packages become stale unless I run go install when they change: https://groups.google.com/forum/#!topic/golang-dev/PbOShHZFlC8. Maybe there is a simple solution that could help both work better.

nsf commented 10 years ago

The only solution to that problem is to make both gotype and gocode work with package source files instead of actual compiled packages. I will not implement that feature in gocode in near future, because I don't use go right now at all and I'm in maintainance only mode for all of my go projects.

Gocode was written that way historically, because it was written when there was no such thing as GOPATH. Packages were built with makefiles and the only thing we knew is that they are supposed to be installed into GOROOT (no go install either).

nathany commented 10 years ago

That sounds like a lot of work. :-) Thanks for your reply.

nsf commented 9 years ago

Leaving this issue open for informative purposes.