Context search improvements/reliability

[m7medVision]

I am experiencing an issue where the file input in CopilotChat.nvim is not functioning as expected. Could someone provide guidance on how to verify if the file input is working correctly?

[jellydn]

Could you try to use pin tag/version: v3.9.1? If that works for you just in case the latest on main is broken for some reason. cc @deathbeam

[deathbeam]

This definitely needs more info, what exactly is not working? Maybe the issue is this? https://github.com/CopilotC-Nvim/CopilotChat.nvim?tab=readme-ov-file#requirements (e.g autocomplete config not set properly)

[deathbeam]

So was it the issue I mentioned or can you provide some steps to reproduce the issue or info about what the issue even is?

[peruginiandrea]

This definitely needs more info, what exactly is not working? Maybe the issue is this? https://github.com/CopilotC-Nvim/CopilotChat.nvim?tab=readme-ov-file#requirements (e.g autocomplete config not set properly)

I've also experienced a related issue recently where sometimes after adding files in the context it would just add a filemap (?) and the LLM would tell me it can't see the content, but just the names (and that's also what I see after pressing gc). I'm not using the filenames context option btw.

[deathbeam]

Until recently the #files context included also filenames but I removed it so now you need to explicitely also use #filenames so that should not be an issue anymore. Or alternatively only use #buffers and #filenames, I also made the ai aware of contexts so when its missing some context it should be able to generate #file that gets auto inserted to your next prompt from #filenames.

Rest is mostly just filtering issue, #buffers have score adjusted so they get prioritzed in search, but if your context is too big the plugin will automatically try to limit it to some reasonable amount and sometimes that can fail if your prompt do not includes any relevant keywords that are in the file

[peruginiandrea]

@deathbeam i'm on commit 1e5640b (from 15 min ago). can you confirm that this is intended behavior (i have custom instructions so right now it doesn't auto-generate #file to add it in my next prompt yet until i change it)? there are many more files than those and i don't understand why it's seeing those specifically:

can you list all the files whose content you can see? #files #filenames

#   Copilot 

# Files Whose Content I Can Currently See

1. **Neo-tree File Explorer View**:
   `/Users/andreaperugini/neo-tree filesystem [1]` - Shows your project's directory structure in the Neo-tree file explorer

2. **Ruby Module for Test Filtering**:
   `unity/auto/test_file_filter.rb` - Contains a Ruby class `TestFileFilter` that handles test file filtering functionality for Unity testing framework

3. **Clang Compiler Configuration**:
   `unity/test/targets/clang_file.yml` - YAML configuration file for running Unity tests with the Clang compiler, including compiler flags and settings

The other contexts (`file_map`, `file_map1`, and `file_map2`) aren't actual file contents but rather listings of available files in your project directory structure.

If you'd like me to examine the content of any specific file from those listings, you can use the `#file:` command followed by the file path.

💡 **Tip**: To quickly navigate between files in Neovim with AstroNvim, you can use Telescope with `<leader>ff` (find files) or `<leader>fb` (find buffers).

**`References`**:
[neo-tree filesystem [1]](/Users/andreaperugini/neo-tree filesystem [1])
[file_map](file_map)
[test_file_filter.rb](unity/auto/test_file_filter.rb)
[file_map1](file_map1)
[file_map2](file_map2)
[clang_file.yml](unity/test/targets/clang_file.yml)

if i press gc, i can see other files (with content) in src/ but the LLM claims there's no content. furthermore, gc doesn't show me anything in src/include/ but apparently it finds files in other subdirectories. thank you in advance!

[deathbeam]

@deathbeam i'm on commit 1e5640b (from 15 min ago). can you confirm that this is intended behavior (i have custom instructions so right now it doesn't auto-generate #file to add it in my next prompt yet until i change it)? there are many more files than those and i don't understand why it's seeing those specifically:

can you list all the files whose content you can see? #files #filenames

#   Copilot 

# Files Whose Content I Can Currently See

1. **Neo-tree File Explorer View**:
   `/Users/andreaperugini/neo-tree filesystem [1]` - Shows your project's directory structure in the Neo-tree file explorer

2. **Ruby Module for Test Filtering**:
   `unity/auto/test_file_filter.rb` - Contains a Ruby class `TestFileFilter` that handles test file filtering functionality for Unity testing framework

3. **Clang Compiler Configuration**:
   `unity/test/targets/clang_file.yml` - YAML configuration file for running Unity tests with the Clang compiler, including compiler flags and settings

The other contexts (`file_map`, `file_map1`, and `file_map2`) aren't actual file contents but rather listings of available files in your project directory structure.

If you'd like me to examine the content of any specific file from those listings, you can use the `#file:` command followed by the file path.

💡 **Tip**: To quickly navigate between files in Neovim with AstroNvim, you can use Telescope with `<leader>ff` (find files) or `<leader>fb` (find buffers).

**`References`**:
[neo-tree filesystem [1]](/Users/andreaperugini/neo-tree filesystem [1])
[file_map](file_map)
[test_file_filter.rb](unity/auto/test_file_filter.rb)
[file_map1](file_map1)
[file_map2](file_map2)
[clang_file.yml](unity/test/targets/clang_file.yml)

if i press gc, i can see other files (with content) in src/ but the LLM claims there's no content. furthermore, gc doesn't show me anything in src/include/ but apparently it finds files in other subdirectories. thank you in advance!

yea that is somewhat intended behaviour. how the filtering works is that it grabs your prompt + all prompts from history and filters the result of #files based on that. gc will still show other stuff because it is showing context before filtering (as filtering uses embeddings so I did not wanted gc to try and use embedding api every time it was used).

which means that for generic description of the project and very generic queries on big repositories it is not very helpful (in ideal scenario it will try to grab stuff like README etc if you have one), but if you somewhat know what you are looking for (keywords etc) then the results are better.

The context description for generating the ># commands is auto included after all system prompts, so its there but as the AI doesnt even know what you are looking for it cant even generate specific context command so it only mentions it i guess.

Also the file/filenames contexts have limit of 2500 files and also respect gitignore so if src/include is in gitignore or there are too many files it skips

[deathbeam]

I think this might be better as discussion as stuff like this is something that will gradually have to improve as the filtering is best effort at best (stuff like VectorCode and vectorspace also partially helps) so gonna move it to discussion. I also just did some improvements on agressive filtering out of binary files in advance for slightly better results

[deathbeam]

I did some improvements to sorting and filtering. Before I had min threshold for similarity, now I changed it to cutoff point instead that is dynamically calculated so if there is bunch of slightly matching results that are very similar and there is nothing better it will try to grab them

[Stanton-B]

Hey there, thanks for all your work on this.

This is definitely trying some new stuff!

I'm getting an error when it says preparing embedding outline

   Error  09:01:01 PM msg_show.lua_error Error executing callback:
...r/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:506: E5560: nvim_get_option_value must not be called in a fast event context
stack traceback:
	[C]: in function '__index'
	...r/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:506: in function 'parse'
	...are/nvim/lazy/CopilotChat.nvim/lua/CopilotChat/utils.lua:682: in function 'returned_function'
	...share/nvim/lazy/plenary.nvim/lua/plenary/async/async.lua:31: in function 'callback_or_next'
	...share/nvim/lazy/plenary.nvim/lua/plenary/async/async.lua:45: in function 'saved_callback'
	...are/nvim/lazy/plenary.nvim/lua/plenary/async/control.lua:126: in function 'on_exit'
	...nt_nvimCpOjOO/usr/share/nvim/runtime/lua/vim/_system.lua:309: in function <...nt_nvimCpOjOO/usr/share/nvim/runtime/lua/vim/_system.lua:279>

I'm on pop!os(ubuntu) using nvim 0.11.0-dev and just updated copilotchat in lazyvim.

[deathbeam]

Hey there, thanks for all your work on this.

This is definitely trying some new stuff!

I'm getting an error when it says preparing embedding outline

   Error  09:01:01 PM msg_show.lua_error Error executing callback:
...r/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:506: E5560: nvim_get_option_value must not be called in a fast event context
stack traceback:
	[C]: in function '__index'
	...r/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:506: in function 'parse'
	...are/nvim/lazy/CopilotChat.nvim/lua/CopilotChat/utils.lua:682: in function 'returned_function'
	...share/nvim/lazy/plenary.nvim/lua/plenary/async/async.lua:31: in function 'callback_or_next'
	...share/nvim/lazy/plenary.nvim/lua/plenary/async/async.lua:45: in function 'saved_callback'
	...are/nvim/lazy/plenary.nvim/lua/plenary/async/control.lua:126: in function 'on_exit'
	...nt_nvimCpOjOO/usr/share/nvim/runtime/lua/vim/_system.lua:309: in function <...nt_nvimCpOjOO/usr/share/nvim/runtime/lua/vim/_system.lua:279>

I'm on pop!os(ubuntu) using nvim 0.11.0-dev and just updated copilotchat in lazyvim.

hmm that looks like you are on neovim dev but not on one that is up to date enough, can you try to update to latest master? the async treesitter features are fairly recent afaik

[deathbeam]

actually i can reproduce this, hmm its a bug i guess

[Stanton-B]

Yeah I upgraded to latest nightly and it is producing the same error.

   Error  09:38:53 PM msg_show.lua_error Error executing callback:
...r/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:506: E5560: nvim_get_option_value must not be called in a fast event context
stack traceback:
	[C]: in function '__index'
	...r/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:506: in function 'parse'
	...are/nvim/lazy/CopilotChat.nvim/lua/CopilotChat/utils.lua:682: in function 'returned_function'
	...share/nvim/lazy/plenary.nvim/lua/plenary/async/async.lua:31: in function 'callback_or_next'
	...share/nvim/lazy/plenary.nvim/lua/plenary/async/async.lua:45: in function 'on_exit'
	...nt_nvimKMhMHb/usr/share/nvim/runtime/lua/vim/_system.lua:309: in function <...nt_nvimKMhMHb/usr/share/nvim/runtime/lua/vim/_system.lua:279>
09:38:51 PM msg_showcmd :
09:40:18 PM msg_show   version NVIM v0.11.0-dev-1999+ge7627db35f
09:40:18 PM msg_show   version Build type: RelWithDebInfo
09:40:18 PM msg_show   version LuaJIT 2.1.1741730670
Run ":verbose version" for more info

[deathbeam]

Yea just fixed it. the initial logic in treesitter async parsing logic is not thread safe (which is well..). Anyway if you update the plugin now it will work

[Stanton-B]

One idea I have is maybe there should be something like an #allfiles context to just include everything indiscriminately with no filtering. Obviously this would be a mistake with large codebases, but in many cases you want to just make sure it sees everything, right? Like if I am learning something from a cloned tutorial or starting a project with a minimal skeleton I just want it to look at everything in the workspace without sophisticated filters cutting anything out.

Or maybe I am misunderstanding how it works..thanks!

[deathbeam]

You can technically make your own context for listing files and just bump up the score in the response. But I am currently reworking how contexts works so after that will be done I will probs start thinking about more improvements

[omarabid]

The new updates completely messed up the plugin. Now it no longer recognize #buffer and copilot keeps asking for files (it must be a new prompt?)

[deathbeam]

The new updates completely messed up the plugin. Now it no longer recognize #buffer and copilot keeps asking for files (it must be a new prompt?)

what neovim version are you on? and are you seeing any errors? because buffer should def be still recognized and i was testing it earlier and it was working for me

EDIT: also how big is the file?

[omarabid]

It recognizes it sometimes and sometimes not. It also now include the errors (LSP info) by default. My preference is to have full control over the prompt/data that is fed. How to change/set that?

[deathbeam]

In what cases? when you are sending too many files? as under 5 files there is no filtering, and buffers get score bonus when there is above 5. And for diagnostics, im most likely going to make new #diagnostics context in #1029

[deathbeam]

Keeping this open mostly for visibility as the filtering issue isnt fully solved and im making some imrpovements to it in the tools PR