get info from gocode asynchronously

[bhcleek]

No description provided.

[codecov-io]

Codecov Report

Merging #1697 into master will decrease coverage by 0.13%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #1697      +/-   ##
==========================================
- Coverage    19.7%   19.57%   -0.14%     
==========================================
  Files          57       57              
  Lines        4735     4787      +52     
==========================================
+ Hits          933      937       +4     
- Misses       3802     3850      +48

Flag	Coverage Δ
#nvim	14.95% <0%> (-0.15%)	⬇️
#vim74	17.15% <0%> (-0.17%)	⬇️
#vim80	18.5% <0%> (-0.12%)	⬇️

Impacted Files	Coverage Δ
autoload/go/complete.vim	0% <0%> (ø)	⬆️
autoload/go/debug.vim	0% <0%> (ø)	⬆️
autoload/go/guru.vim	9.52% <0%> (+0.01%)	⬆️
autoload/go/lint.vim	57.3% <0%> (+0.73%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4f9c2e9...2499155. Read the comment docs.

[arp242]

I used this in the last few days, and <C-x><C-o> completion mostly seems to work okay, but in some cases it seems to return the wrong results in ways that I don't think happened before.

It only seems to happen in larger more complicated files. I can't create an easily reproducible test cas; I noted a particular case earlier when I was working, but now that I return to it, it works fine :-/ But mostly it's in cases where you have something like:

pkg.outerFun(anotherpkg.fun(innerFun()))

And you try to edit/complete something on outerFun it will actually half-way complete fun.

I'm not 100% sure that this branch is even at fault – perhaps I'm just more attentive to possible defects – and it hasn't happened very often (2 or 3 times in total). As far as I'm concerned it doesn't have to prevent merging this, but just wanted to note it.

[bhcleek]

🤔 this PR actually changes very little on that code path, but there's one aspect of that code path that I've wondered if it's correct (though I should point out that it's not something that was altered here). That code path is the one place that uses go#util#CursorOffset() instead of go#util#CursorOffset()+1. I'm not sure why; it may be a bug that's always existed, but I'm not sure 🤷

[fatih]

I can verify that the garbage character issue is gone with this. Also I haven't seen any completion related issues yet, but will add here if I find anything (I also just use c-x c-o myself whenever I need it).

[GregDuhamel]

Hello Guys,

i have this issue since few days :

<SNR>88_auto_type_info[3]..go#tool#Info[3]..go#complete#Info[2]..<SNR>166_async_info :
line   73 :
E475: Argument invalide : env 

each time i open a go file.

it's doesn't appear if i put :

let g:go_auto_type_info = 0

or using guru :

let g:go_auto_type_info = 1
let g:go_info_mode = 'guru'

in my ~/.vimrc

i'm using :

go version go1.10 linux/amd64
VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Jul 26 2017 20:13:43)
My version of vim-go is the latest installed by vim-plug.
My version of gocode is the latest installed by vim-plug.

Any idea ?

Regards,
Gregory.

[bhcleek]

The version of Vim that you're using doesn't support the env field of the job options. Can you upgrade to at least patch 8.0.0902? The commit that introduced env to Vim8 is vim/vim@05aafed.

In the future, please create a new issue instead of commenting on a closed PR or issue; it will help other users and keeps your comment from getting lost.

[GregDuhamel]

Thanks, you are right, this outdated version from ubuntu repository is at fault. It's working very well on version 1-1605.

Do you want me to open an issue or PR to make it appears clearly ?