Is anyone interested in writing Github Copilot plugin?

Plugins
1

It really helps a lot:

there is an official vim plugin:

https://github.com/github/copilot.vim

and, an unofficial emacs plugin:

https://github.com/zerolfx/copilot.el

I want to implement it in kakoune, but have absolutely no clue.

1 Like
2

Sublime Plugin: GitHub - TheSecEng/LSP-copilot: GitHub Copilot support for Sublime Text LSP plugin provided through Copilot.vim.

3

I’ve been using Kakoune for over 1 week now and I really like various aspects of Kakoune, but I can’t really stand not having copilot.

Maybe I’ll just have to change to neovim for now …

4

Pure Lua plugin: GitHub - zbirenbaum/copilot.lua: Lua plugin for starting and interacting with github copilot

5

Does anyone know how to implement it in kakoune? I need some outline style guides…

6

Usually the process for implementing a more complex plug-in in kakoune is to write a command-line program that does the functionality and interface kakoune with the program using named pipes.
So writing (or finding) a command-line program that does the heavy lifting will probably be most of the way!

7

Thanks! I learned how to write a basic kakoune plugin, I really like it’s simple concepts, I even wrote one: GitHub - theowenyoung/kakoune-buffer-manager: Managing Buffers within the file, support multiple selections, delete buffers, open buffers , but copilot is another level for me. cause it need to handle login github service, and start a local agent to communicate with github service and text editor.

should I try to a kak-lsp compatible language server for this? or I don’t have to?

8

You should handle all the tricky stuff and communication with github copilot in a command-line program written in your favorite programming language. Then on the kakoune side, it will be similar to kakoune-snippets, I think, where the snippets will be provided by your commandline program.

9

I’ve looked a bit at other plugins, and I think writing a language server is indeed a good idea, if that works, you don’t need a kakoune plugin at all!

I think this file in copilot.vim is in fact already the language server implementation copilot.vim/agent.js at release · github/copilot.vim · GitHub

1 Like
10

Thanks! then I need to learn more about @krobelus kak-lsp, to figure out how to build it.

11

VSCode supports running multiple language servers in a single file. This issue tracks how we can add that feature to kak-lsp. We might be able to write a special language server that merely acts as a proxy to multiple language servers. That would be usable in any editor.

Anyway that’s not needed for basic Copilot support. It would be nice if there was a generic Copilot language server (maybe there is one?) then there is no extra work

12

VSCode supports running multiple language servers in a single file. This issue tracks how we can add that feature to kak-lsp. We might be able to write a special language server that merely acts as a proxy to multiple language servers. That would be usable in any editor.

Anyway that’s not needed for basic Copilot support. It would be nice if there was a generic Copilot language server (maybe there is one?) then it is trivial to integrate it with kak-lsp.

13

neovim also supports multiple lsp. but it seems GitHub - github/copilot.vim: Neovim plugin for GitHub Copilot and GitHub - zerolfx/copilot.el: An unofficial Copilot plugin for Emacs. , both of them are not using lsp.

only GitHub - TheSecEng/LSP-copilot: GitHub Copilot support for Sublime Text LSP plugin provided through Copilot.vim. is using lsp.

14

I’m super down for a kakoune copilot plugin!
Would love to try it on my favorite editor

15

Reading the first POC commit of LSP-copilot helps understand how to communicate with it copilot-node-server used by copilot.vim and LSP-copilot

1 Like
16

There might be an easier way to go about it. At least for now.

Copilot is powered by Openai’s Codex. Openai also offers a playground and an API that both give access to Codex. So it is possible to write a simple commandline client that calls Codex directly and integrate that in Kakoune, simply sidestepping GitHub.

The API to Codex is what they call in “Limited beta” so it is not clear if they will keep offering it. It is also not free, but neither is Copilot.

Codex: OpenAI API
API: OpenAI API

17

I found a go CLI client for ChatGPT that works pretty well:

Then, if you install it, you can just pipe to it. For writing code, the -c models seem to be overloaded a lot, but maybe if it’s not you can use it. Normal chatgpt3.5 works pretty well. I have leader-c mapped to replace the code, leader-q to open a clippy with some prompt engineering to form it as a question, and leader-r to resample the text.

map global user -docstring "Replace selection with chatgpt's answer" c '<a-|>tee /tmp/chatgpt.txt<ret>| cat /tmp/chatgpt.txt | chatgpt -x<ret>'
map global user -docstring "Resample the last question with chatgpt" r '|cat /tmp/chatgpt.txt | chatgpt -x<ret>'
map global user -docstring "Ask chatgpt about the selection!" q '<a-|>(tee /tmp/chatgpt.txt; echo "\nWhat is this?" >> /tmp/chatgpt.txt)<ret>:info -title "chatgpt" "%sh{cat /tmp/chatgpt.txt | chatgpt -x}"<ret>'
1 Like
18

I read this just on the day that I was going to attempt to write it myself. Now I don’t need to anymore. Thanks!

19

I’m testing GitHub - j178/chatgpt: Interactive CLI for ChatGPT with gpt-3.5 model, pretty cool I can just pipe text straight from buffer :smiley:

2 Likes
20

I’ve been using a nice combination of kakpipe and heygpt for this, here’s an example using cork.kak

cork kakpipe https://github.com/eburghar/kakpipe %{ require-module kakpipe }

define-command hey -docstring "
  hey <query>: heygpt utility wrapper
  Query ChatGPT and stream the response in a FIFO buffer
" -params 1.. %{
  kakpipe -w -n hey-response -- heygpt %arg{@};
}

this works nicely with expansions:

:hey explain this code: %val{selection}
:hey create jsdoc comments for this code: %val{selection}
:hey refactor this code using async/await: %val{selection}

I also have this block in my config to create a buffer for iterating and sending prompts:

define-command hey-buffer -docstring "
  opens a *hey-prompt* buffer for writing queries to pass to hey
" %{
  edit -scratch *hey-prompt*
  set-option buffer filetype hey-prompt
}
define-command hey-buffer-write -docstring "
  send the *hey-prompt* buffer to hey
" -hidden %[
  buffer *hey-prompt*
  execute-keys '%: hey %val{selection} <ret>'
]
hook global BufSetOption filetype=hey-prompt %{
  alias buffer write hey-buffer-write
  alias buffer w hey-buffer-write
}