avante.nvim icon indicating copy to clipboard operation
avante.nvim copied to clipboard

bug: @codebase not working

Open john-persson-polestar opened this issue 1 year ago • 12 comments

Describe the bug

I'm trying to chat with the codebase using @codebase, however Avante seams to have no context of file other than the on in my current buffer.

I.e. when asking about files that are imported in the current buffer, they are not in the context of Avante.


Avante: Would you like me to see the actual definition of FileName? Please share the context of Avante apps/products/app/routes/$locale.page-path/types/FileName.ts and I can provide more specific details.


and when I ask how to include them I will get the following answer:


Me: how do I share it with you? Avante: I can already see the code since you've shared it using the correct format with <filepath> and <code> tags. However, if you want me to see other files (like the SectionId type definition), you would need to share them in a similar way:

  1. First specify the filepath in <filepath> tags
  2. Then share the code content in <code> tags

For example, if you wanted to share the SectionId definition, you could share it like:

<filepath>apps/products/app/routes/$locale.page-path/types/FileName.ts</filepath>

<code>
// content of the SectionId file would go here
</code>

Would you like to share any additional files with me?


To reproduce

Ask a question to Avante with @codebase about files that are not part of the current buffer.

Expected behavior

For Avante to have the full project context when asking questions using @codebase.

Installation method

Use lazy.nvim:

{
  "yetone/avante.nvim",
  event = "VeryLazy",
  lazy = false,
  version = false, -- set this if you want to always pull the latest change
  opts = {
    -- add any opts here
  },
  -- if you want to build from source then do `make BUILD_FROM_SOURCE=true`
  build = "make",
  -- build = "powershell -ExecutionPolicy Bypass -File Build.ps1 -BuildFromSource false" -- for windows
  dependencies = {
    "nvim-treesitter/nvim-treesitter",
    "stevearc/dressing.nvim",
    "nvim-lua/plenary.nvim",
    "MunifTanjim/nui.nvim",
  },
}

Environment

NVIM v0.10.1
Build type: Release
LuaJIT 2.1.1725453128

Repro

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    -- add any other plugins here
  },
})

john-persson-polestar avatar Nov 20 '24 21:11 john-persson-polestar

I can also add that I'm getting this error when asking a questions when there is no open buffer:

   Error  23:05:08 msg_show.emsg E5108: Error executing lua: ...ocal/share/nvim/lazy/avante.nvim/lua/avante/repo_map.lua:77: attempt to concatenate local 'file_ext' (a nil value)
stack traceback:
	...ocal/share/nvim/lazy/avante.nvim/lua/avante/repo_map.lua:77: in function 'get_repo_map'
	...local/share/nvim/lazy/avante.nvim/lua/avante/sidebar.lua:1409: in function 'handle_submit'
	...local/share/nvim/lazy/avante.nvim/lua/avante/sidebar.lua:1488: in function <...local/share/nvim/lazy/avante.nvim/lua/avante/sidebar.lua:1478>
   Error  23:05:10 msg_show.lua_error Error executing vim.schedule lua callback: ...ender-markdown.nvim/lua/render-markdown/core/context.lua:85: attempt to index local 'node' (a number value)
stack traceback:
	...ender-markdown.nvim/lua/render-markdown/core/context.lua:85: in function 'get_checkbox'
	...r-markdown.nvim/lua/render-markdown/render/list_item.lua:33: in function 'setup'
	...r-markdown.nvim/lua/render-markdown/handler/markdown.lua:80: in function 'callback'
	...ender-markdown.nvim/lua/render-markdown/core/context.lua:190: in function 'query'
	...r-markdown.nvim/lua/render-markdown/handler/markdown.lua:76: in function 'parse'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:215: in function 'parse_tree'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:185: in function 'parse_buffer'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:122: in function 'run_update'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:88: in function <...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:87>
   Error  23:05:10 msg_show.lua_error Error executing vim.schedule lua callback: ...ender-markdown.nvim/lua/render-markdown/core/context.lua:85: attempt to index local 'node' (a number value)
stack traceback:
	...ender-markdown.nvim/lua/render-markdown/core/context.lua:85: in function 'get_checkbox'
	...r-markdown.nvim/lua/render-markdown/render/list_item.lua:33: in function 'setup'
	...r-markdown.nvim/lua/render-markdown/handler/markdown.lua:80: in function 'callback'
	...ender-markdown.nvim/lua/render-markdown/core/context.lua:190: in function 'query'
	...r-markdown.nvim/lua/render-markdown/handler/markdown.lua:76: in function 'parse'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:215: in function 'parse_tree'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:185: in function 'parse_buffer'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:122: in function 'run_update'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:88: in function <...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:87>
   Error  23:05:20 msg_show.lua_error    Error executing vim.schedule lua callback: ...ender-markdown.nvim/lua/render-markdown/core/context.lua:85: attempt to index local 'node' (a number value)
stack traceback:
	...ender-markdown.nvim/lua/render-markdown/core/context.lua:85: in function 'get_checkbox'
	...r-markdown.nvim/lua/render-markdown/render/list_item.lua:33: in function 'setup'
	...r-markdown.nvim/lua/render-markdown/handler/markdown.lua:80: in function 'callback'
	...ender-markdown.nvim/lua/render-markdown/core/context.lua:190: in function 'query'
	...r-markdown.nvim/lua/render-markdown/handler/markdown.lua:76: in function 'parse'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:215: in function 'parse_tree'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:185: in function 'parse_buffer'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:122: in function 'run_update'
	...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:88: in function <...azy/render-markdown.nvim/lua/render-markdown/core/ui.lua:87>

john-persson-polestar avatar Nov 20 '24 22:11 john-persson-polestar

@john-persson-polestar It seems that your Avante is not the latest version. Can you upgrade to the latest version and try again?

yetone avatar Nov 21 '24 03:11 yetone

@yetone thank you for the quick response. I'm on the latest version (SHA: 341ecd207348841403ee4c2473864ef5c74ab710).

john-persson-polestar avatar Nov 21 '24 09:11 john-persson-polestar

I'm getting the exact same issue, Avante has no context of any other files outside of my current buffer. Commit sha 934602b

lukeberry99 avatar Nov 22 '24 19:11 lukeberry99

I'm having the same issue. Looking at the code, I believe the codebase is only attaching current buffer files.

     local file_ext = api.nvim_buf_get_name(self.code.bufnr):match("^.+%.(.+)$")
     local project_context = mentions.enable_project_context and RepoMap.get_repo_map(file_ext) or nil

I believe I can fix it, but this repository doesn't allow pushing a proposed branch for non-authors. Please help us resolve this issue or grant me permission so I can assist in fixing it.

cuongkane avatar Dec 02 '24 03:12 cuongkane

I believe I can fix it, but this repository doesn't allow pushing a proposed branch for non-authors.

@lexuancuong, fork the repository and create a PR from the fork.

radwo avatar Dec 02 '24 09:12 radwo

feat. Today, @codebase only passes the repo_map (syntax tree populated via tree-sitter) as context which might be not very helpful imo. Instead, probly we should compute the embedding of files of the codebase, compare to the embedding of the query and select most similar top N files to pass as context. all above should be done locally if we use some embedding lib or local vector store to cache the file embeddings. @yetone what do you think?

czheo avatar Dec 12 '24 06:12 czheo

Out of curiosity. It sounds like an operation like this is going to expensive to run. I'd imagine that the price is going to scale by the size of your codebase? I.e. running the initial @codebase query with nothing cached could become very pricy depending on the size of your codebase.

john-persson-polestar avatar Dec 12 '24 07:12 john-persson-polestar

I'd imagine that the price is going to scale by the size of your codebase?

That's exactly why I'm proposing to pick top N most related files locally to pass as prompt context, instead of the entire codebase.

Even better if we can split files into smaller chunks (e.g. tree-sitter can parse to get blocks of code), so we can pass only highly related snippets instead of the entire files.

czheo avatar Dec 13 '24 02:12 czheo

Even better if we can split files into smaller chunks (e.g. tree-sitter can parse to get blocks of code), so we can pass only highly related snippets instead of the entire files.

I think that might be what the LSP support is partly aiming to solve. From the README:

LSP + Tree-sitter + LLM Integration: Integrate with LSP and Tree-sitter and LLM to provide more accurate and powerful code suggestions and analysis.

john-persson-polestar avatar Dec 13 '24 08:12 john-persson-polestar

Instead, probly we should compute the embedding of files of the codebase, compare to the embedding of the query and select most similar top N files to pass as context. all above should be done locally if we use some embedding lib or local vector store to cache the file embeddings.

This is what would need to happen for this feature to work effectively, and is what Cursor does today (except they store the embeddings remotely). I think the major challenge would be tracking when to re-embed files in the code as to keep the costs low, though embedding models are generally pretty cheap. There are some vector extensions for sqlite so that's one option for storage.

jadengis avatar Dec 19 '24 04:12 jadengis

Upvote, I'm waiting for a fix

huyhandes avatar Mar 13 '25 02:03 huyhandes

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

github-actions[bot] avatar Apr 13 '25 02:04 github-actions[bot]

This issue was closed because it has been stalled for 5 days with no activity.

github-actions[bot] avatar Apr 19 '25 02:04 github-actions[bot]