Do you know what changed recently?

[9mm]

I know this is a problem with copilon.nvim and not copilot.lua. Mr pope has issues turned off though, and I figure maybe someone knows here due to the knowledge sharing between these 2 projects.

Do you know what happened recently with autocompleting the text? it is atrocious, like when it makes a suggestion, Its like its treated as "real text" now, so when i move up/down with the cursor, I cant type "through" the incorrect stuff anymore and just ignore it, now it actually affects cursor movement as if its real text

Im wondering if anyone else notices this, it truly ruins the experience :[

[MunifTanjim]

Do you know what happened recently with autocompleting the text? it is atrocious, like when it makes a suggestion, Its like its treated as "real text" now, so when i move up/down with the cursor, I cant type "through" the incorrect stuff anymore and just ignore it, now it actually affects cursor movement as if its real text

Can you share a recording? I can't reproduce it.

---

Also what's the output of :Copilot version?

[9mm]

Not sure how to copy this but here is a screenshot, will try to get a recording when im back home

[matijas-05]

I just rolled back to commit 38a41d0d78f8823cc144c99784528b9a68bdd608 and everything works as it did.

[9mm]

@matijas-05 so you noticed it too? How would you describe it? It's a bit hard to explain.

I've been trying to record a loom video for @MunifTanjim but it will work perfectly when recording, and as soon as I close it it will come back in a fury... I tried about 5 or 6 times and just gave up.

It basically has tons of "artifacts" and junk which doesn't clear if you type too fast, and they actually completely obscure movement/actual typing as if they're real text.

[matijas-05]

@matijas-05 so you noticed it too? How would you describe it? It's a bit hard to explain.

I've been trying to record a loom video for @MunifTanjim but it will work perfectly when recording, and as soon as I close it it will come back in a fury... I tried about 5 or 6 times and just gave up.

It basically has tons of "artifacts" and junk which doesn't clear if you type too fast, and they actually completely obscure movement/actual typing as if they're real text.

In my case the time it takes to come up with a suggestion is longer, also when I overwrite a part of the suggestion and accept it, the input that overwrote the suggestion gets added after the suggestion.

[9mm]

Yes, I also noticed that for sure as a secondary issue.

The primary issue as well I noticed is that normal mode actually wont move "through" text but around it, it will jump over entire lines

[9mm]

I made a comment on copilot.vim commit but it seems he can't reproduce it. Perhaps there is some indirect problem with the formatting of the responses or something, with the new agent.js? So perhaps the behavior is correct in copilot.vim not breaks in copilot.lua, even though only the agent.js changed

Edit: I actually feel bad about making an issue there first 💀 I suppose at first glance I thought the issue might be in agent.js but also in retrospect it's potentially more likely in this repo and something in the response changed perhaps

[9mm]

Heres a quick example of the issue @matijas-05 encountered. The other issues arent as common but Ill try to get other looms as they come up

https://www.loom.com/share/e3f7407e1fb64857942b66a501935aec

[pavkam]

@matijas-05 so you noticed it too? How would you describe it? It's a bit hard to explain.
I've been trying to record a loom video for @MunifTanjim but it will work perfectly when recording, and as soon as I close it it will come back in a fury... I tried about 5 or 6 times and just gave up.
It basically has tons of "artifacts" and junk which doesn't clear if you type too fast, and they actually completely obscure movement/actual typing as if they're real text.

In my case the time it takes to come up with a suggestion is longer, also when I overwrite a part of the suggestion and accept it, the input that overwrote the suggestion gets added after the suggestion.

Same. Tried tweaking things, but realized it's not working properly anymore.

[idavydov]

same here

[meeehdi-dev]

Hi everyone,

I also noticed the same issue, so I made a few tests:

• Following tpope's advice, I reverted the agent to the previous version => Same issue (So this is not due to copilot.vim)
• I partially reverted the changes of commit dcaaed5 which modifies the schedule() function in the suggestion file (dcaaed5#diff-5f63348c80e3035904e43971249bc360c91fca0a972cca6e51b90ff4246fa1abR405) => This fixes the issue 👍
  

@MunifTanjim I don't really know what this clear() function does, but when it's not called on every schedule() call, the suggestion is not cleared when we keep writing while their is a suggestion shown, so if we decide to accept the suggestion after writing a few additional characters, those characters are being added at the end of the suggestion like shown by @9mm video.
And I don't know why but this simple change also fixes the issue with the suggestion taking more time to appear.
Was there a crucial point to moving the clear() call inside the !is_enabled() condition?
If not, just moving the call will fix everything for us.
But if the change is still needed, we'll have to think of how to fix the condition to call it.

EDIT: The issue might also be due to our configs, so here's mine just in case:

    opts = {
      panel = {
        enabled = false,
      },
      suggestion = {
        enabled = true,
        auto_trigger = true,
        debounce = 500,
        keymap = {
          accept = "<Tab>",
          accept_word = "<C-Right>",
        },
      },
    },

[meeehdi-dev]

Ok so I just noticed this lua code is simply trying to replicate tpope's vimscript code (https://github.com/github/copilot.vim/blob/5b19fb001d7f31c4c7c5556d7a97b243bd29f45f/autoload/copilot.vim#L415)

We can see that the condition is a little bit different in the lua implementation, so I guess this is why we have issues here.
I will try to fix this locally, and if it works I'll create a PR but since i don't know either codebases, if anyone feels comfortable doing it, please go ahead 🙏

[9mm]

@meeehdi-dev that is awesome, especially because you also fixed the delay issue. Nice!! Hopefully this gets merged or looked at soon as this is killin me

[meeehdi-dev]

@meeehdi-dev that is awesome, especially because you also fixed the delay issue. Nice!! Hopefully this gets merged or looked at soon as this is killin me

As @matijas-05 mentioned, you can still rollback to commit 38a41d0d78f8823cc144c99784528b9a68bdd608 while this gets fixed.

---

After further investigation it seems to me there is a drift between this plugin's lua code and tpope's.
For example, the function UpdatePreview (https://github.com/github/copilot.vim/blob/release/autoload/copilot.vim#L331) looks way different than its lua equivalent update_preview (https://github.com/zbirenbaum/copilot.lua/blob/master/lua/copilot/suggestion.lua#L228)

I don't know if it is intended or not, but let's say it is.

The difference in behavior we end up with is that tpope's code updates the suggestion when the user inputs new characters while the suggestion is shown, so his plugin has no issue of additional characters appearing at the end of the accepted suggestion.

I'll wait for the maintainers to tell us what's the best course of action now that we know where the problem comes from.

[9mm]

@meeehdi-dev he replied here with a possible fix, are you able to test it? #259

I'm not at my computer atm but I figured I would put it here anyway as you were investigating that issue, so might be easy for you to test

[meeehdi-dev]

@meeehdi-dev he replied here with a possible fix, are you able to test it? #259

I'm not at my computer atm but I figured I would put it here anyway as you were investigating that issue, so might be easy for you to test

The issue doesn't appear anymore after this fix, with the same options i mentioned above (debounce=500) 👍

[MunifTanjim]

Noice. Sorry for getting back so late.

Let's reopen if the issue comes back again.

[9mm]

Thanks!! Nice work, looks great so far for me

[jtackaberry]

I did skim this issue before I opened #259 but it wasn't clear this was the same problem. Sorry for the redundancy -- but hopefully the sleuthing I did in #259 was helpful to @MunifTanjim (and thanks again!)

[MunifTanjim]

Yep, the description in #259 helped me reproduce the issue. Thanks for that 🙌🏼 @jtackaberry