CopilotC-Nvim / CopilotChat.nvim

Chat with GitHub Copilot in Neovim
https://copilotc-nvim.github.io/CopilotChat.nvim/
GNU General Public License v3.0
1.5k stars 69 forks source link

Why isn't a prompt buffer used? #379

Closed tmillr closed 1 week ago

tmillr commented 1 month ago

One thing I find annoying is that after I scroll up to view the history, entering insert mode then allows me to edit the current line (e.g. history) instead of taking me back to the prompting line/area. It'd be nice if entering insert mode took me back to the current prompt automatically (and IIRC, this is precisely how prompt buffers work in neovim).

Here's my temporary workaround, although there may be a better way to implement this internally (using a prompt buffer (see :help prompt-buffer), or, extmarks, etc.):

vim.api.nvim_create_autocmd('FileType', {
  group = augroup,
  -- pattern = 'copilot-*',
  pattern = 'copilot-chat',
  callback = function(info)
    vim.api.nvim_create_autocmd('InsertEnter', {
      group = augroup,
      buffer = info.buf,
      desc = 'Move to last line',
      -- nested = true,
      callback = function()
        vim.cmd 'normal! 0'

        if vim.fn.search([[\m^##\s\+\S]], 'cnW') > 0 then
          vim.cmd 'normal! G$'
          vim.v.char = 'x'
        end
      end,
    })
  end,
})
deathbeam commented 1 month ago

This is first time I hear something like prompt-buffer exists :d Sounds like good idea tho because this is precisely what we want to achieve anyway with otu current implementation.

xlucn commented 2 weeks ago

I tried to directly set buftype=prompt, and that works in a degree. But, there are some issues.

  1. I can use Enter to write a multiple-line question, but I can't edit all previous lines except the current one.

  2. When I quit neovim, it prevents me with the error

    E37: No write since last change
    E162: No write since last change for buffer "copilot-chat"

The default buftype for ft=copilot-chat is nofile, which will allow quitting neovim without taking care of it. Anyone knows a more proper practice of using buftype=prompt?

deathbeam commented 2 weeks ago

So I experimented with prompt buffer a bit and my thoughts are:

It simplifies a lot of the prompt handling code but being able to only edit 1 line is basically no-go. It makes asking complex questions basically impossible. I was able to solve the quitting issue rather easily tho so thats solvable for sure.

I would be for closing this issue as I think the prompt buffer behaviour even though its kinda nice the 1 line thingy is just so bad.

EDIT:

But when entering insert mode, going to last line is probably fine I guess? As that behaviour is rly nice for sure. But its also probably replicable without prompt buffer

tmillr commented 2 weeks ago

But when entering insert mode, going to last line is probably fine I guess? As that behaviour is rly nice for sure. But its also probably replicable without prompt buffer

Yeah it can be replicated. IMO there's no reason to be editing/inserting anywhere but within the current (i.e. bottommost) prompt. So I'd make it so that it takes you there automatically if you are above that section and enter insert mode. You probably don't want to do it if you are already in current prompt section however, as you may be trying to edit earlier lines (not the last one) within the current prompt.

But yeah, I think the last column of the last line is the most logical place to put it in this case (you could also get fancy and do other stuff too, but that's the gist).