project context?

[unphased]

i think it makes sense to try to do a few low hanging fruit to augment the completer with better project context.

Currently we can easily tweak how much contextual code nearby the cursor is provided to LLM context

Let's talk about adding, and coming up with ways to enforce token size limits on, additional context:

• a project skeleton similar to aider's repository map so it has a few clues about project structure
• if LSP is enabled in buffer, getting useful info out of this somehow. For example (just an idea), getting the signature information of all functions that are referenced in the contextual code from the current buffer that is being used.
• working out 'related' files somehow to also include in context. Do we know what heuristics copilot uses? It's probably simple enough to copy.

Actually the sky's the limit and with neovim we should have both LSP and tree-sitter at our disposal which is pretty powerful.

I've been planning to make a tool that would hierarchically summarize code based on syntax tree structure to explore automated code understanding and it would be really suitable for sharing that data with LLM buffer completion.

[milanglacier]

Yes., sounds cool. Since the template system is flexible, you can tweak it and see if you can get any interesting result.

Beside, there is a project vectorcode which provides RAG enhancement and can be used with minuet.

Check out the project documentation and see if you are interested:

[unphased]

Nice thank you for the link, That's very helpful that that project has a config already for use with this one.

[Davidyz]

Hi author of VectorCode here! VectorCode currently implements basic RAG functionalities and it's possible to expand on top of that, such as using nvim LSP/treesitter API to generate query messages (Vectorcode use these to find relevant documents, similar to search keywords). This is a customisable option in the Vectorcode neovim interface: you can use LSP symbols, diagnostic messages, etc. to generate whatever query you want. I believe these should address your 3rd point (and maybe partially the 2nd). At the moment I want to keep vectorcode as a RAG provider, but I'm open to other possibilities and suggestions! Feel free to check out the repo https://GitHub.com/Davidyz/VectorCode and give it a try!

[unphased]

To be entirely honest, I see in-buffer completion as a secondary workflow today in comparison to prompt driven workflows (i like to use aider for that)

Both are really important to have though. Now what's interesting is how being embedded in neovim can give some superpowers via treesitter and any active LSPs. This kinda gets me thinking more about how to bring these to bear to better automate the selection of context files in that kind of workflow.

[milanglacier]

To be entirely honest, I see in-buffer completion as a secondary workflow today in comparison to prompt driven workflows (i like to use aider for that)

You are absolutely right, but this is out of the scope of this plugin (as a code completion only plugin). Aider is the best FOSS AI coding assistant, I use it love it, no doubt. But there's no need to mention it here as this statement makes no contribution to this project :).

Now what's interesting is how being embedded in neovim can give some superpowers via treesitter and any active LSPs. This kinda gets me thinking more about how to bring these to bear to better automate the selection of context files in that kind of workflow.

Your statement is absolutely makes sense and requires a detailed outline and in-hands implementation. I have defined a flexible template system and it is not hard to plugin treesitter enhanced prompt. If you are thinking it is "low-hanging fruit", then I will happy to see any progress in it. Beyond just statement of how useful those things would be (they are useful, of course), I would love to see any detailed progress / technical progress on this.

[Davidyz]

Both are really important to have though. Now what's interesting is how being embedded in neovim can give some superpowers via treesitter and any active LSPs. This kinda gets me thinking more about how to bring these to bear to better automate the selection of context files in that kind of workflow.

Hi if you're still interested in using treesitter and active LSPs to enhance the LLM, VectorCode now supports customising the query constructor, which controls what keywords to use when searching for repo files. There's a very basic implementation that uses lsp document symbols as query messages. You can try constructing the query from LSP, buffer, treesitter or diagnostics. There are also experimental integrations with codecompanion.nvim if you're looking for a chat-based workflow.

[ilan-schemoul]

I have defined a flexible template system and it is not hard to plugin treesitter enhanced prompt. If you are thinking it is "low-hanging fruit", then I will happy to see any progress in it. Beyond just statement of how useful those things would be (they are useful, of course), I would love to see any detailed progress / technical progress on this.

So just to be clear you'd be interested in how someone would implement use codevector to enrich the template of minuet so you could possibly add it as an example ?
Or you'd be open to some code that automatically handles the VectorCode<>Minuet interconnection to lower the burden of each user maintaining their config
Also do anyone has input has of how relevant adding LSP context is for autocompletion ? Is there any guidance as to what's useful, not useful for LLMs autocompletion cojntext ?

I want to add AI to nvim but I'm overwhelmed by all the possibilities of chat, context, autocompletion, all the many LLMs there is etc. (+ many people mention aider which I tried and is interesting but unsure how to fit in the workflow) etc. So I'm very open to guidance, and willing to contribute to simplify things once I get a grip

[Davidyz]

Also do anyone has input has of how relevant adding LSP context is for autocompletion ? Is there any guidance as to what's useful, not useful for LLMs autocompletion cojntext ?

I suppose it could be useful (and hopefully more time efficient) to use the workspace symbols request to obtain a list of functions/classes in the repo. This could very likely be faster than a synchronous vectorcode query (and if there's a cache/memoisation mechanism, this would offer a similar experience as the async cache in vectorcode). This would produce a context component that is similar to the repo map in aider. If the LLM is trained to handle repo files, we can ofc add whole files too, just need to take care of the number of files so that the context length is manageable.

[milanglacier]

how someone would implement use codevector to enrich the template of minuet so you could possibly add it as an example ?

If you read the README, you will notice that there is a section for integration with VectorCode.

RAG-experimental

I have included the required minuet configuration for making vectorcode working with minuet.

For configuration on the vectorcode side, like how many documents you want to query, how would you want to make the connection between the external vectorcode program and neovim. It is best to consult with vectorcode's documentation for the configuration. VectorCode is also a rapidly evolving project, I think it is best to keep on track with its development by following its instruction.

[milanglacier]

This would produce a context component that is similar to the repo map in aider.

I plan to extract the repo-map part of aider into a standalone package. The repo-map is primarily built based on treesitter. Once this is done, I will also include a integration section for making the repo-map external program working with minuet.

[ilan-schemoul]

I suppose it could be useful (and hopefully more time efficient) to use the workspace symbols request to obtain a list of functions/classes in the repo. This could very likely be faster than a synchronous vectorcode query (and if there's a cache/memoisation mechanism, this would offer a similar experience as the async cache in vectorcode). This would produce a context component that is similar to the repo map in aider. If the LLM is trained to handle repo files, we can ofc add whole files too, just need to take care of the number of files so that the context length is manageable.

It works wonder with aider. But with LLM completions plugins (the ones trained for FIM) they are hard to do anything not strictly in their training set.
At least I didn't get any luck with models such as Codestral to add a prompt with "Things after <user_edit> is recent modification made by user. use it if required" I tried with other such as qwen 2.5 7B coder etc. but I don't think we can do much.
It's really a shame because providing diagnostics, TS symbols, LSP symbols and recent edit history would do wonders if we could. I think Cursor successfully implemented it but I don't think their LLMs are public so can't do much here. I really wish open models will move forward to have FIM that let context be added (at least some like gemini allows you to provide related files' codes but it's limited, AFAIK it's just code from other files you can add not TS/LSP symbols etc.).