Current Goals

[zbirenbaum]

Now that I believe I have the copilot plugins in a stable state, here are the goals I have planned for the future:

1. Customization of result frequency: Currently, completions are requested by cmp which is debounced. I would like to add an option for constant requests for results via the uv loop api, similar to how copilot.vim gets their completions. Depending on the frequency you set, you may have dramatic increases in CPU usage and editor latency, but I do think this is worth implementing.

2. Extend the api, make it easier to use: This one is pretty self explanatory, hooking into copilot and adding your own functionality and handlers should be made much simpler. By virtue of how cmp works, it was easier to just make the buf requests there to get a functional product, but this will need to be implemented as part of goal (1). Development of this will likely precede or occur alongside goal (1)

3. ~~Fix copilot adding extraneous braces, brackets, parenthesis, etc: If characters like closing braces or parenthesis exist, copilot will insert additional ones, which kinda sucks. This isn't going to be easy and is an issue in copilot.vim as well, but if it's done well, it would be a major step forward.~~ This one is done!!!

4. Creation of hosts/terms json files should be implemented as copilot.vim does

5. ???: Provide your input! What else would you like to see? Please feel free to comment and discuss here, or create an issue with the enhancement/feature flags.

[sbulav]

Hi Zack, Thanks for your work on that plugin. I would like to see the following things:

• Async startup of copilot(is it possible?)
• Specifying on which filetypes to start the plugin
• Configurable line length

Something like https://github.com/tzachar/cmp-tabnine#setup would be nice

[zbirenbaum]

Hi @sbulav, thank you for the input, just a couple of comments:

• Async startup of copilot(is it possible?)

I'm not certain of what you mean by this. The server itself is a rpc, so neovim just sends out the command to start it. If you want to have it start automatically rather than InsertEnter, and still not affect startup time, using vim.defer_fn in your packer use to wrap the config should work. It may just take some time playing with the value to get the correct behavior. See the README.md for more details on this.

• Specifying on which filetypes to start the plugin

This is a great idea and something that should be released soon.

• Configurable line length

I'm not sure what you mean by this. If here, you mean ask for completions of a certain length, that's not supported by copilot to my knowledge. The copilot discussion forum has also been complaining over the last couple days about general copilot performance regarding its ability to generate full functions/only getting one line, so it's not just the plugins I wrote...

We are somewhat at the mercy of copilot's api here. I did some testing for https://github.com/zbirenbaum/copilot-cmp/issues/5 and it turns out that while I can force a request for completions in such cases, the server returns no results.

I have requested an openai codex key, and whenever I get off that waitlist, I'll use it to make my own minimal lsp for completions. This should be able to support more fine grained things like how much of a completion you want, but I can't promise anything, and even once I do have one, you would need a codex key to run it.

[zbirenbaum]

@sbulav

Specifying on which filetypes to start the plugin

Checks have been written in to make sure copilot doesn't start in buffers like help or packer. ft_disable has been added to the params, so any languages you don't want to use copilot for can be input there. I think a blacklist makes more sense than a whitelist given the nature of copilot.

Somehow I got my codex key literally today an hour after I responded to you. If you don't have one, I would apply to their waitlist now, so that whenever I have the time to make a much more specialized plugin and api than is possible with copilot you will be able to use it.

[sbulav]

Hi @zbirenbaum Thanks for your in-depth explanation! I had significant input lag with vim.schedule on one of the previous copilot.lua versions, but with the latest version, the lag is gone.

As for the line length, I mean that sometimes completion, provided by the copilot, gets ridiculously long. Check out this example:

I'd like to have an option to limit line length to, let's say, 80 symbols.

[zbirenbaum]

Hi @zbirenbaum Thanks for your in-depth explanation! I had significant input lag with vim.schedule on one of the previous copilot.lua versions, but with the latest version, the lag is gone.

As for the line length, I mean that sometimes completion, provided by the copilot, gets ridiculously long. Check out this example:

I'd like to have an option to limit line length to, let's say, 80 symbols.

Glad to hear the lag issue is fixed!

I noticed that too, but I have cmp's max len limited so it never got that bad lol. I pushed an update to copilot-cmp just now, which caps it at 30 chars or abbreviates it with the first 20 + '...' + last 10 for the label.

I'd like the user to be able to customize it, but integrating setup options has been an ongoing debate with myself regarding how to design them best. For now, I hope the change helps.

I know you said 80, but since there's a preview in the doc window, and more than 30 + the ' ... ' was making my screen cluttered with a vertical split I thought it would be a rational default for most people to cap it there.

I'll definitely make that one of the first customizable options once I figure out how I want to do the user params. It gets really complicated because I want to have the option to make custom options for getting the completions, like having copilot.lua request them every 200ms in a loop and read from there, but to my knowledge most cmp sources haven't been so ambitious in customizability, and the codebase is rather difficult.

I don't want to have a bunch of breaking changes trying to get it done and life is a bit busy right now to even attempt it anyways, but it'll be something to look forward to in the coming weeks once I have a little more time to dedicate to it.

I know that was probably waaay more info than you asked for or even wanted, but I thought giving a general status update here for anyone interested was probably in order.

[zbirenbaum]

edit: sorry posted in the wrong thread

[dklymenk]

Thank you for great work you did with the plugins.

Here are a couple of things that would be good to have:

• Some way to tell if there is an ongoing request to copilot servers. Being able to distinguish between "loading" state and "0 results" state would be a huge productivity boost for anyone using this plugin.
• An alternative to original plugin's Copilot status. I have been using the tpope's version for a few month before I switched to yours and I really miss the ability to check the status of the server after not getting any suggestions for a few minutes.

[MunifTanjim]

@dklymenk :Copilot status should now work as expected.

[MunifTanjim]

Closing this, since everything's pretty much working as expected right now and all the goals are met already.