idea
maybe we could implement async/parallel prompts. if im in one buffer, i can either scope my prompt to that buffer, or multiple. if i pick multiple, then ill just make the prompt, mention my files, let the llm work.
but if i scope it to one buffer (or perhaps if this is the default), i should be able to prompt one buffer, move to another, make another prompt, and they should both run independently of each other.
problem
right now jumpy is "single-flight". you prompt, wait, and then review. if you want edits in another buffer, you do it sequentially. also, a single prompt only really targets one buffer rn.
goal
two modes:
single-buffer scope (default)
prompt buffer A -> request starts -> move to buffer B -> prompt again -> second request runs in parallel. each finishes independently and drops hunks into its own buffer.
multi-buffer scope
one prompt explicitly targets several files. mention the files, let the llm work. one request returns patches for multiple files, hunks land in each buffer.
both should feed into the same review pipeline (quickfix + accept/reject across files).
notes
- parallel single-buffer prompts = workflow speed (fire and forget)
- multi-buffer scope = intentional cross-file edits from one prompt
- pairs naturally with quickfix as the unified review UI
out of scope
refs
idea
maybe we could implement async/parallel prompts. if im in one buffer, i can either scope my prompt to that buffer, or multiple. if i pick multiple, then ill just make the prompt, mention my files, let the llm work.
but if i scope it to one buffer (or perhaps if this is the default), i should be able to prompt one buffer, move to another, make another prompt, and they should both run independently of each other.
problem
right now jumpy is "single-flight". you prompt, wait, and then review. if you want edits in another buffer, you do it sequentially. also, a single prompt only really targets one buffer rn.
goal
two modes:
single-buffer scope (default)
prompt buffer A -> request starts -> move to buffer B -> prompt again -> second request runs in parallel. each finishes independently and drops hunks into its own buffer.
multi-buffer scope
one prompt explicitly targets several files. mention the files, let the llm work. one request returns patches for multiple files, hunks land in each buffer.
both should feed into the same review pipeline (quickfix + accept/reject across files).
notes
out of scope
refs