Closed valentin-krasontovitsch closed 4 years ago
@puremourning hey ben, sorry about posting an incomplete issue prematurely - i've completed it all now, hopefully as required.
would you mind reopening the issue please?
Of course ! Thanks.
Considering that vim-go also does completion and also uses gopls, this issue could easily be a conflict.
Thanks a lot! I’m still confused about who does what - gonna try and reproduce without gopls.
Does the expected behavior I describe sounds familiar though, in the sense of being a feature of ycm? Is what I expect even understandable?
On Fri, 31 Jan 2020 at 21:47, Boris Staletic notifications@github.com wrote:
Considering that vim-go also does completion and also uses gopls, this issue could easily be a conflict.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ycm-core/YouCompleteMe/issues/3586?email_source=notifications&email_token=ADZR2BN4LHR6PQKQ4CZI6R3RASE6FA5CNFSM4KOHI77KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKP6RHI#issuecomment-580905117, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZR2BKOHKEOEX3JAQ7NT2LRASE6FANCNFSM4KOHI77A .
There's a ton of overlap between YCM and vim-go. We're talking about completion and both plugins do it. I have no idea how vim-go works, but YCM assumes that it owns the completion menu and :h 'completefunc'
. Even if there's no actual conflict between plugins, it's possible that gopls just isn't smart enough to give you the expected completions.
Yeah vim-go has a philosophy of doing everything including completion so it’s not compatible with other completion systems like YCM.
Tbh I’m not even sure YCM would trigger semantic completion at that point in the file.
Can you please try without vim-go and gitgutter so the case is actually minimal?
There's a ton of overlap between YCM and vim-go. We're talking about completion and both plugins do it.
Yeah vim-go has a philosophy of doing everything including completion
Hmm I see - I really don't know precisely who is doing what, and after some quick test I just assumed that it was YCM. I'm going to try to investigate more, and in particular figure out how to see completion results with vim-go.
In the meantime, a trial without vim-go and gitgutter (removed from vimrc and deleted from bundle category) gave the same result.
Tbh I’m not even sure YCM would trigger semantic completion at that point in the file.
I see - I don't know if it's difficult to describe in a language agnostic way, but let me try:
I have a (struct) type defined, and in the same scope, I'm initiating a variable of said type, and once I'm syntactically in the unique place for setting fields that are part of the type, without entering any prefix, I would like to autocomplete to the fields of the struct type. does that make sense?
Trying to find other examples, I see that you usually have some symbol that would trigger semantic completion in such a context, like a period. Is it possibly as simple as allowing semantic completion at an empty prefix / without a trigger prefix? hope that makes sense... I sadly understand very little of how completion works under the hood, so I apologize for any confusion
ya OK after reading a bit on how to toggle completion with vim-go (turns out it's ctrl-x ctrl-o) it seems like the behaviour i was experiencing was indeed due to vim-go. hmm. there I indeed get, well, not only the struct fields, but the struct fields come as first suggestions, with the general stuff below...
I guess i'm gonna close this, thank you for the help and support!
Trying to find other examples, I see that you usually have some symbol that would trigger semantic completion in such a context, like a period. Is it possibly as simple as allowing semantic completion at an empty prefix / without a trigger prefix? hope that makes sense... I sadly understand very little of how completion works under the hood, so I apologize for any confusion
YouCompleteMe does allow configuring this behaviour. You can use <C-Space>
to force semantic completion and you can also configure g:ycm_semantic_triggers
.
Thank you for the pointers! I was using Ctrl-Space to trigger completion, and your comments means that what I was getting was semantic completion.
the value of g:ycm_semantic_triggers
is just {}
for me in a go file.
hmm I'm gonna have to dive a bit deeper and figure out how to get a behaviour that I would like... thanks again!
I can confirm the behaviour you see regarding completion.
I tried in VScode too and it behaves the way you expect. I suspect this difference is because vscode-go uses gocode by default and we use gopls.
SO I found these instructions which said to set "go.useLanguageServer": true,
Setting that, I get the same behaviour in vscode. So this is a gopls limitation, nothing YCM can do about that.
FWIW I get the same result with master of gopls.
oohh thanks a lot for testing and confirming that!
so basically one could say that if one desired the described behaviour, one should revert to using gocode
instead of gopls
, or investigate whether some changes can be made to gopls
to get the desired behaviour? perhaps upstream at gopls, this is a feature rather than a bug...
or could one just pipe together / fix the settings to use both gopls and gocode, or godef and go doc where appropriate? would prefer to have something "working out of the box", of course, for my personal preference of "working" ; )
I'm not sure what exactly you're asking, but YCM uses gopls. We're not going back to gocode.
So yes, try asking the gopls people.
I assumed that you could perhaps "choose" the completion command/engine for go completion using some option - based on your comment, that assumption was obviously wrong : D
gonna direct my attention to gopls then. thanks again for the support, I really appreciate it!
Issue Prelude
[x] I have read and understood YCM's CONTRIBUTING document.
[x] I have read and understood YCM's CODE_OF_CONDUCT document.
[x] I have read and understood YCM's README, especially the Frequently Asked Questions section.
[X] I have searched YCM's issue tracker to find issues similar to the one I'm about to report and couldn't find an answer to my problem. (Example Google search.)
[x] If filing a bug report, I have included the output of
vim --version
.[x] If filing a bug report, I have included the output of
:YcmDebugInfo
.[x] If filing a bug report, I have attached the contents of the logfiles using the
:YcmToggleLogs
command.[x] If filing a bug report, I have included which OS (including specific OS version) I am using.
[x] If filing a bug report, I have included a minimal test case that reproduces my issue, including what I expected to happen and what actually happened.
[x] I understand this is an open-source project staffed by volunteers and that any help I receive is a selfless, heartfelt gift of their free time. I know I am not entitled to anything and will be polite and courteous.
[x] I understand my issue may be closed if it becomes obvious I didn't actually perform all of these steps.
Thank you for adhering to this process! It ensures your issue is resolved quickly and that neither your nor our time is needlessly wasted.
Issue Details
I recently updated my go version to 1.13 and started using modules. this prompted me to update ycm, since something seemed broken (completion didn't quite work anymore). after not being able to get completion to work as i was used to, i resorted to trying a clean and newest setup, without fixing the problem.
:PluginInstall
in vimpython3 install.py --go-completer --ts-completer --clangd-completer
main.go
move cursor to where the star is, in insert mode, and trigger completion e.g. by crtl+space
What did you expect to happen?
I expected the suggested completions to be precisely the fields of the defined struct type
I got a bunch of generic completion suggestions from the global namespace, like for instance
see screenshot here:
Diagnostic data
Output of
vim --version
Output of
YcmDebugInfo
Contents of YCM, ycmd and completion engine logfiles
gist with logs for ycm, ycmd, and gopls
OS version, distribution, etc.
macos high sierra 10.13.6