Ollama and #buffers

[fredrikaverpil]

Hey 👋 @olimorris and thanks for this nice plugin!

I'm trying it out with ollama and I can chat just fine with llama3.1, and both #buffer and #editor works as expected:

return {
  {
    "olimorris/codecompanion.nvim",
    dependencies = {
      "nvim-lua/plenary.nvim",
      "nvim-treesitter/nvim-treesitter",
      "nvim-telescope/telescope.nvim",
      {
        "stevearc/dressing.nvim",
      },
    },

    config = function()
      local ollama_fn = function()
        return require("codecompanion.adapters").use("ollama", { schema = { model = { default = "llama3.1" } } })
      end

      require("codecompanion").setup({
        adapters = {
          ollama = ollama_fn,
        },
        strategies = {
          chat = {
            adapter = "ollama",
          },
          inline = {
            adapter = "ollama",
          },
          agent = {
            adapter = "ollama",
          },
        },
      })
    end,
  },
}

However, I can't quite get #buffers (with an s) to work. Codecompanion only always sees the currently opened buffer. I was expecting that any buffer I have created would be used. Is this the intention?

If you do a bunch of gd (gotodef's) and therefore create up few different buffers and then go CodeCompanionChat followed by #buffers, should code companion be aware of all those buffers?

[olimorris]

Hey @fredrikaverpil. Thanks for your kind words.

There may be a few nuances with #buffers I should have made users aware of. It will only share buffers that are of the same filetype as the buffer you originated the chat from. My logic was it stops things like large markdown being sent over to the LLM when I only care about fellow Lua or Python files for example. Also, it uses nvim_buf_is_valid to check that a buffer exists and has not been unloaded or deleted. Just because a buffer is listed may not mean it's loaded.

Are these constraints stopping it from working for you?

[fredrikaverpil]

A workspace sounds nice. I took a quick stab at this, see here.

I'm not sure why, but I have to provide a dummy message first. Then the LLM picks up on after that.

However, it does seem like the LLM really just remembers the last file provided when there are multiple files in the folder.

[olimorris]

That seems odd. I'd advise setting:

opts = {
  log_level = "DEBUG",
},

and running checkhealth codecompanion to get the location of the log file. In here you should see what is being sent as part of the request. I'm guessing something isn't being sent as part of the payload.

[fredrikaverpil]

Is this require("codecompanion").setup({ log_level = "DEBUG" } you mean?

codecompanion: require("codecompanion.health").check()

codecompanion.nvim report ~
- Log file: /Users/fredrik/.local/state/fredrik/codecompanion.log
- OK plenary.nvim installed
- OK nvim-treesitter installed
- OK telescope.nvim installed
- OK dressing.nvim installed
- OK curl installed

The log file is empty.

[fredrikaverpil]

Ok, I moved stuff around and it now seems to work better: https://github.com/fredrikaverpil/dotfiles/blob/main/nvim-fredrik/lua/plugins/codecompanion.lua 😄

Doesn't really work on large projects as ollama will get really, really slow!

[olimorris]

I believe a cool solution to this would be to use the LSP server to determine which files to look for and open via a go to definition. That could reduce the context that's sent over to the LLM.