Exafunction / codeium.vim

Free, ultrafast Copilot alternative for Vim and Neovim
https://codeium.com
MIT License
3.77k stars 126 forks source link

Virtualtext hides what I'm typing #85

Closed Vermoot closed 1 year ago

Vermoot commented 1 year ago

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. image image

pqn commented 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

dyonathakramer commented 1 year ago

yeap, same here

hornyjailfish commented 1 year ago

same for me

martin-braun commented 1 year ago

I noticed this as well, but it's more subtile for me, because the delay is shorter in my case, yet still annoying:

2023-04-01 8 15 29 PM

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.

Cy-r0 commented 1 year ago

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#Clearwith 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.

martin-braun commented 1 year ago

@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. :)

pqn commented 1 year ago

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.

Cy-r0 commented 1 year ago

Ahhh, I misread the vimscript documentation! I thought a:0 was the first argument, not the number of arguments.

It all makes sense now.