Best usecases for chatgpt in neovim

[AdrienLemaire]

I've been using github copilot until recently, and am looking at replacing it with chatgpt. gp.nvim seems like a very nice plugin for this.

Can ChatGPT recursively read code imported in a file ?
Would it be able to refactore code across multiple files ? Do these files need to be opened in buffers ?

I'm hoping that the community can build a documentation around the best practices to make the most out of gp.nvim :)

[Robitx]

@AdrienLemaire Hey, for direct copilot equivalent have you looked into codeium?

Can ChatGPT recursively read code imported in a file ?

Nope, because the gpt models are not there yet. The best most people can use is 16K token window with gpt3.5 (which is roughly 2K lines of code), with smarter gpt-4 8K it's half that. Recursively reading imports would quickly blow the token window.

If you use established libraries, import resolving is not necessary, just tell the GPT what libs/frameworks you want to use.

For private/less known code, you could just dump concise API reference for what you need into a .gp.md file in a root of a repo and all code operations would have it as a context. This could be mostly automated with a custom hook like

    -- example of adding command which writes concise API documentation for the selected code
    APIDoc = function(gp, params)
        local template = "I have the following code from {{filename}}:\n\n"
            .. "```{{filetype}}\n{{selection}}\n```\n\n"
            .. "Please respond by writing minimalistic markdown API documentation for the code above.\n\n"
            .. "Ignore private code, public only.\n\n"
            .. "Use minimum number of words and sentences.\n\n"
            .. "\n\nFor function and methods provide just declaration - no word description necessary."
        gp.Prompt(params, gp.Target.enew, nil, gp.config.command_model, template, gp.config.command_system_prompt)
    end,

so that hiting :%GpAPIDoc would generate a doc you could add to .gp.md. I've tested it on some adhoc code which is over 1.2K lines ~ 10K tokens and resulting doc had around 400 tokens (reduction by a factor of 25). For less commented code, it could still reduce it by a factor 5-10.

More manual surgically precise option would be to gather relevant pieces of code from multiple files into a chat buffer with :GpChatPaste and let the model to crunch it there. (Basically what would people do by using https://chat.openai.com/ website, but without the need to leave neovim and paste stuff to the browser and back).

Would it be able to refactor code across multiple files ? Do these files need to be opened in buffers ?

You're probably looking for something like sweep, these things are behemoths which put all your code base into vector database (which allows it to partially go around the token limit), spawn multiple interacting agents, which across multiple iteration edit your code and eventually produce result for specified task.

Editor plugins such as gp.nvim are bound by the need for real time interactivity. I doubt you want a vim plugin to spawn multiple docker containers so they can cook the code for unspecified amount of time, while you go for coffee (or tea). 🙂

I'm hoping that the community can build a documentation around the best practices to make the most out of gp.nvim :)

Yeah, I should work on that.

Gp can be great helper which saves a lot of time and if you provide instructions by speech you barely have to touch the keyboard, but it still works as a human would editing one file at a time. And by design (at least for foreseeable future) I don't let the models run loose without human interaction in the loop the way sweep or auto-gpt does.

[AdrienLemaire]

Thanks for the great answer.
I've been using codeium since my copilot membership expired, but the results aren't the same quality, it doesn't seem to understand comment prompts either. I get what I pay for, I suppose ^^

I'll be playing with all that in the following weeks :)

[Robitx]

@AdrienLemaire it's now possible to run gp.nvim instructions from terminal/script, so refactoring on multiple files can be automated (for example a lib has changed and all usage instances need to be updated).

It still doesn't solve refactor of code intertwined across multiple files, but it's a progress.

---

test file:

1
2
3
4
5

.gp.md file:

If user says hello, please respond with:

```
Ahoy there!
```

calling gp.nvim from terminal/script:

• register autocommand to save and quit nvim when Gp is done
• second jumps to occurrence of something I want to rewrite/append/prepend to (in this case number 3)
• selecting the line
• calling gp.nvim acction

$ nvim --headless -c "autocmd User GpDone wq" -c "/3" -c"normal V" -c "GpAppend hello there"  test

resulting test file:

1
2
3
Ahoy there!
4
5