-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Accepting a completion logs a weird message to statusline #3272
Comments
I'm not able to duplicate what you're describing. When I try the same thing I don't see any such message output either on the statusline or on the last line of the screen (I think that when you say statusline, you mean the last line of the screen, which is distinct from the statusline - can you confirm?). |
Thanks for the quick response. I do mean the last line. I've attached a screenshot to clarify. It starts with I should note I'm also using |
I agree that it's coming from vim-go, but I'm not sure how or why, and I can't duplicate what you're describing. |
It might be useful to see the messages from the gopls log window. Can you execute |
I'm not sure why there would be a What's does |
After looking at the coc code, I'm virtually certain that this is happening because of the coc code that tries to extend the completion time. You can disable this entirely by using |
With Enabling the lsp log before doing the completion gives me this rather large log:
If I disable Setting Do you have any tips on what I might ask the |
That's quite odd. It's hard to know why that might be, but I suspect you have your coc configuration setup to hook into vim-go's
It's around here: https://github.com/neoclide/coc.nvim/blob/c49acf35d8c32c16e1f14ab056a15308e0751688/src/completion/complete.ts#L245 and how that interacts with vim-go when |
I realized my broken omnifunc was due to a clash with a completely unrelated shortcut that was intercepting Thanks! |
Just a follow-up on this, CoC author @chemzqm said:
I think this is ultimately just a case of an unfortunate interaction between the two plugins |
That seems like an odd answer given that the CompleteDone event identifies the completed item in I can add a workaround to vim-go for this. |
Return early from the CompleteDone handler when omnifunc is not set to go#complete#Complete. This should help interactions with other plugins like coc.nvim that some users leverage to do completion. Relates to fatih#3272
I've put up #3274 to try to workaround this for you. It's arguably the right thing to do, but I'm a little worried it won't actually work for you, because it's not clear to me how coc.nvim actually works; it seems to use neither |
I appreciate the quick fix, it seems to work! Truthfully I don't know much about Vim plugin implementation so I can't comment as to how Coc is behaving or what's "right" here, but I do appreciate your help on this! If this change causes issues for other uses of course it can always be rolled back |
What did you do? (required: The issue will be closed when not provided)
In a go file, trigger a completion and then accept it. For example:
Hitting
tab
after thetime.S
will pop up a suggestion fortime.Sleep
, and selecting it with enter inserts it.What did you expect to happen?
I expect the completion to be inserted and the statusline to remain unchanged.
What happened instead?
The completion is inserted but an odd message gets written to the statusline:
Is there a way to disable this message?
Configuration (MUST fill this out):
vim-go version:
vimrc
you used to reproduce:vimrc
Vim version (first three lines from
:version
):NVIM v0.5.0
Build type: Release
LuaJIT 2.1.0-beta3
Go version (
go version
):go version go1.16.6 darwin/amd64
Go environment
go env
Output:gopls version
gopls version
Output:vim-go configuration:
vim-go configuration
filetype detection configuration:
filetype detection
The text was updated successfully, but these errors were encountered: