send prompts across multiple files

[cachebag]

problem

prompts are scoped to the buffer you are in

goal

we should be able to tag files in a workspace (i.e. "take the methods in @foo.c and move them to this file")

this is actually a bit more involved. we need to recursively search files and maybe even resolve a root. i don't think both though. i think we can start at the cwd of the buffer we prompt in and step backwards or we can just resolve a root upon loading of the plugin and cache/populate active files to the session. but idk how we would resolve a root for a project that isnt a git repo... @LOTaher any ideas?

design

i dunno im at work just thought it was important to note before #12

refs

PR #12

[cachebag]

wait im stupid the problem is not at all how we find files. we can just git rev-parse --show-toplevel for git repos and vim.fn.getcwd() for everything else.

the real issue here is how do you pack referenced file contents into the LLM context without blowing the token window? do we send full files or just relevant snippets (the latter sounds so cool to have in jumpy)?

also if the LLM returns changes spanning multiple files, how does the diff/patch layer handle that? the current hunk system is buffer-scoped...

but basically, once we can let a prompt edit multiple files, then #12 becomes a tad bit more trivial

[LOTaher]

Looked at the leaked cl*ude c*de source code to see how they handle this. Though, maybe not the best place to look tbh lol. Regarding referencing file content via @ there is a hard limit of 256 KB on disk, 2000 lines, or 25,000 tokens. whatever gets hit first.

I agree though, multiple file diffs would segway us nicely to #12. qf functionality allows us to completely dodge cross-buffer navigation as a required feature.

[LOTaher]

Regarding LLM changes returning across multiple files, we can maybe add a state.tagged_files = {...} where ... should be the path, the buffer number to draw in (if this doesn't exist, then we'd need to open a buffer to the path), the file content which can be retrieved by nvim_buf_get_lines(buffer number, ...). This state will all be parsed and added from the @[path] within the prompt.

These tagged files would be used to build the prompt to something like:

  --- FILE: lua/jumpy/foo.lua ---
  <contents>
  --- END FILE ---

  --- FILE: lua/jumpy/bar.lua ---
  <contents>
  --- END FILE ---

and then the system prompt should also include a line to go with
"return ONLY the changed sections as SEARCH/REPLACE blocks."

perhaps something like:
"Every SEARCH/REPLACE block must start with <<<<< SEARCH path/to/file"

Kinda freeballing here since prompt and llm are areas I haven't explored much but I think this can be a good start. Thoughts?

[cachebag]

@LOTaher was working on something today, PR should be open soon. basically just starting from the parsing/patch layer first. this was good:

we can maybe add a state.tagged_files = {...} where ... should be the path, the buffer number to draw in (if this doesn't exist, then we'd need to open a buffer to the path)

im not yet on prompt state yet, and buffer creation on apply is still left but I think I can finish by tn.

I like this idea a lot re tagged files.

[LOTaher]

@cachebag sounds good! Yeah will take a look when open. Currently working on file search autocomplete within the prompt (the parsing part) so you're welcome to not implement that in this PR. Need to still figure out how to add highlight groups for multiple @'s. Will prob open a PR once I finish the new module and we can work from there.