nsf
Display GoDoc when autocompleting in Vim
Just a feature request:
When using omnicomplete for languages like python, vim can display the documentation for the function.
This would be awesome if gocode did it with godoc.
Here's an example of what the python autocomplete it looks like in vim:
This feature request appeared many times. Shortly: no.
The reasons why I don't want to add documentation display in gocode is that gocode doesn't parse the source code (that's where documentation is). It uses compiled libraries directly which contain only type information.
However, gocode can be used to extract type information about the thing under the cursor and perhaps then some other service could be used to find the related documentation. No one did it so far and I'm not interested in that at all. If someone wishes to do this, I will cooperate.
@nsf I was looking into this a bit, and I think all I would have to do is have gocode return the package and type the symbol that is autocompleted to.
Unfortunately, I was looking at the source, and it seemed like it would be somewhat difficult to extract this context out of how things are stored since most of the mappings are from package name -> *, and I need to make from the symbol to the package name.
The other thing I was thinking is if gocode were able to return the position and source file it found the symbol in originally, it would be pretty easy to add ctags-like functionality to the plugin.
If you could provide some guidance how one could go about modifying gocode to propagate more of the context of the symbols it is auto-completing for, it would be a huge help.
Also let me know if you don't feel this functionality is appropriate for gocode and belongs in a different sort of module.
Yeah, I tried a couple of things today too and it didn't work, I'll try few more things tomorrow and will post a detailed report on that. I think gocode has all you need to get the full library path and the printable type out of it, but it's not as simple as I was expecting.
So, I've just committed this thing: 64791d9e7b7e4322996
As commit says:
Add deduction of a type from the expression at the cursor position.
It's implemented as an example for future maintainers of that feature.
Hence, not documented in the -h yet. Probably buggy right now.
Works on test.0009, to test it do:
cd _testing/test.0009
gocode -in test.go cursortype 126
Will print:
sync.Mutex,,/home/nsf/go/pkg/linux_amd64/sync.a
Neat?
Perhaps it's not exactly what you want (it returns the type of the expression before the dot '.'), but it's a starting point. Good luck with that, as you can see what I did is just about 130 lines of code.
I dont like this feature neither, at least not by default. I hate plugins which opens windows when I don't want it :-)
Can we close this feature. I really hate when a new window opens and I can't close it. It's annoying. Any settings for disabling it?
@farslan This feature wasn't implemented. If you're using vim, perhaps set completeopt-=preview in your .vimrc may help.
@nsf - picking up where you left off on 64791d9e7b7e4322996 (and the 'hidden' cursortype option)
The behaviour you implemented was different to what I expected given the name "cursortype". Taking this very basic example:
package main
import (
"fmt"
)
func main() {
my_string := fmt.Sprintf("This is a test %d", 5)
fmt.Println(my_string)
}
With the cursor over s of my_string in fmt.Println(my_string) I would have expected the result string.
With the cursor over the first n of fmt.Println(... I would have expected the result to be the function signature, func(a ...interface{}) (n int, err error)
i.e. the implementation would be something like this - very very rough cut... but you get the idea.
Have I misunderstood what was intended for cursortype?
If so, would you be happy to accept a PR which implements the behaviour (code tidied up or course)
It not, would you be happy to accept a PR which fixes the behaviour?
Whatever works for you guys. If it doesn't break anything else. cursortype isn't documented and has no well defined behaviour. My intention was to show what's possible.
Awesome. I will create a PR to implement this more along the lines of what the name suggests.
Just chiming in to say this feature would be quite useful for GoClipse as well. In typical Eclipse fashion, doc comments can be show on the code completion popup:
Unfortunately I don't have the time either to try to find a solution. :cry:
