Closed Vermoot closed 1 year ago
@fortenforge I can reproduce it. I would have thought we're re-rendering due to the calls to: https://github.com/Exafunction/codeium.vim/blob/813461c638d086ef41ef6be760b0e27f83ab7380/autoload/codeium.vim#L356-L357 https://github.com/Exafunction/codeium.vim/blob/813461c638d086ef41ef6be760b0e27f83ab7380/autoload/codeium.vim#L272-L274
yeap, same here
same for me
I noticed this as well, but it's more subtile for me, because the delay is shorter in my case, yet still annoying:
I feel confident that this is kinda related. The plugin needs to register keys in a faster pace, so it can remove its on suggestion quicker than this.
I think there is any hidden circumstance that causes a longer delay for you which makes the issue much more dominant.
Hi everyone, I'm on Neovim v0.8.3.
I did some digging and the problem seems to be inside codeium#Clear
.
First off, I noticed that removing v:false
from this call completely solves the issue:
https://github.com/Exafunction/codeium.vim/blob/813461c638d086ef41ef6be760b0e27f83ab7380/autoload/codeium.vim#L357
The above is the only occurrence of a call to codeium#Clear
with an argument, which is odd.
So, looking in the body of codeium#Clear, I saw this: https://github.com/Exafunction/codeium.vim/blob/813461c638d086ef41ef6be760b0e27f83ab7380/autoload/codeium.vim#L272-L274
Playing a bit with the code, I found out call s:RenderCurrentCompletion()
is only executed when codeium#Clear
is called without arguments (e.g. when you exit Normal mode). But it's not executed when codeium#Clear
is called with v:false
(i.e. when you're typing new characters in insert mode).
v:false
is falsy, so a:0 == 0
on line 272 should be true, but for some reason it isn't. Surprisingly, manually changing the argument to v:true
doesn't affect this in the slightest, but removing it completely gives me the desired behavior.
a:0
is the number of arguments passed to the function, so if there are no arguments a:0 == 0
is true and call s:RenderCurrentCompletion()
is executed.
There are other unknowns here that I didn't investigate, like when is the other s:RenderCurrentCompletion()
on line 267 called? And is calling that function on every keystroke a good idea?
I'm far from an expert on this strange language, so let me know your input on this.
@Cy-r0 Thanks for investigating. This indeed looks like a bug, but I'm not 100% sure either. However, this issue drives me nuts, especially in Telescope's grep preview. Maybe it is worth to do a pull request. Even if it won't be accepted for any particular reason, it will give more attraction to the problem. Owners of repositories like to see clean good PRs that solve issues and it will motivate nonetheless. :)
Revisiting my comment and your comment, turns out a:0
is just the number of extra args, so the current behavior now makes sense. Thanks for taking a look.
Ahhh, I misread the vimscript documentation! I thought a:0
was the first argument, not the number of arguments.
It all makes sense now.
Hi! I've been trying out codeium and codeium.nvim, and there's one thing that's very problematic, I'm not sure if it's a setting on my side or a more generalized problem, but when I get a suggestion and decide not to go with it, if I start typing, I can't see what I'm typing because the suggestion stays on top of that. Here's a video showing what I'm describing:
https://user-images.githubusercontent.com/23317434/223553324-7a47fdd8-ef17-40bc-a2a1-ea9875deea19.mp4
Additionally, it seems to fight with LSP syntax errors.