@cameronr

This is a whole new feature to be able to ask opencode for quick inline edits. It is not perfect, and will probably never will be.

The format used for communication and replacement is largely inspired by Aider chat.

I tried to control the LLM emit JSON for this but it was to error prone and not precise enough.

The LLM will respond with a format like so

    <<<<<<< SEARCH
    function hello() {
     console.log("hello")
    }
    =======
    function hello() {
      console.log("hello");
    }
    >>>>>>> REPLACE

Where SEARCH is the original code and REPLACE is the new one. See this as a really streamlined version of a diff with no reliance on line number.

But I find myself using it quite often for quick tasks

Examples:

• Transform to a lua array
• Add lua annotations
• Write a conventional commit message for my changes #diff
• Fix this warnings #warn
• complete this function

Where the #diff #warn etc. are a new way of adding context to prompts they should work also with Opencode run

You can also use Opencode quick_chat my message or '<'>Opencode quick_chat my message or the keymal <leader>o/

Code is still a bit rough but I figured it was time to ask feedback.

Let me know your toughts on this

Interesting! I will take a look today or tomorrow.

I've played around it with it and, I agree, it's surprisingly convenient and works surprisingly well. I only had one time where it left a codefence in after the replacement. Given that it'll likely never be perfect, I wonder if would make sense to have a way to view the "raw" results from opencode? That might help with bug reports / help refine prompts for different models to make sure it's returning data in the required form.

We could also mark it as experimental initially until we get more feedback.

@cameronr yes there is a way

You can set both quick chat settings to true. so you can inspect the session in the opencode panel

There is still some issues with the wrong context being sent. The context code is quite messy for this PR I am in the process of cleaning that up.

Good idea for the experimental , I will add notes in the README about it

This seems like pretty significant architectural shift for this plugin, where instead of using the ACP protocol to allow the backend to handle core ACP tool implementation, we're shifting those responsibilities to the frontend. Are we sure we want to move in this direction?

It might be worth considering implementations that rely on Opencode's implementation of the ACP protocol to do the actual edits. One way for example I think this can achieved (inspired also by aider's comment prompts) is to write the user's prompt at the cursor position as a comment like # AI! <USER PROMPT>. Then send a prompt stating to read the current file and follow any instructions in the AI comments while also removing the comment prompt once complete. I've tried in a plugin I wrote a while ago and it worked really well for inline edits while also avoiding the need to do the edits on the plugin UI side

@aweis89 This is a fair point.

I looked at the ACP protocol and it seemed pretty limited compared to the opencode http server. But I only reviewed it in the perspective of the chat window. It does not support all slash commands, does not support session listing etc.

I didn't know ACP could do inline edits. The main issue I had is that the inline edits is that it could be performed in an unsaved buffer, where opencode tools read the files via his own tools so it was not aware of onsaved changes.

As per the # AI! as comments, it is interesting, but it would not work to edit a visual selection like this PR did.

I will have to look again at ACP.

I didn't know ACP could do inline edits. The main issue I had is that the inline edits is that it could be performed in an unsaved buffer, where opencode tools read the files via his own tools so it was not aware of onsaved changes.

Tbh this is a problem for none-inline edits as well (albeit to less of an extent). Because ideally any open buffer file would display the changes made by the AI agent as well without the user having to manually reload the file. The sidekick plugin for example handles this by using file watches and then auto reloading files on external edits. It would probably be ideal to find a solution for file reloading that works both for inline edits and for regular file modifications as well.

As per the # AI! as comments, it is interesting, but it would not work to edit a visual selection like this PR did.

Personally I think "edit visual selection" where the user only wants the LLM to modify the highlighted portion, is very niche feature which I haven't seen in any other plugins, and I'd question if it's worth the complexity this introduces. Generally, when a user highlights text, it's more that they want that to be sent as part of the context so it knows what the prompt pertains to. But we can allow the LLM to decide what to edit based on the prompt imho. This is how text selection works in sidekick and other plugins I've played with as well. I think if a user highlights text with an inline prompt, we should just add the highlighted text, metadata like filename and line number and cursor position to the prompt, and then let the LLM decide what to do based on the prompt

The main idea of the # AI! <PROMPT comment is really just so the LLM knowns that this prompts pertains to this specific line. But this isn't really needed when the user is highlighting text since we can just send the highlighted text and its metadata to the LLM. (Just sending the cursor position line-number and filename is often not sufficient as LLMs are often lacking when it comes to line counting).

Of course this all just one user's opinion so take it with a grain of salt obviously!

I didn't know ACP could do inline edits. The main issue I had is that the inline edits is that it could be performed in an unsaved buffer, where opencode tools read the files via his own tools so it was not aware of onsaved changes.

Tbh this is a problem for none-inline edits as well (albeit to less of an extent). Because ideally any open buffer file would display the changes made by the AI agent as well without the user having to manually reload the file. The sidekick plugin for example handles this by using file watches and then auto reloading files on external edits. It would probably be ideal to find a solution for file reloading that works both for inline edits and for regular file modifications as well.

For this part the plugin already knows when file are edited since the opencode server sends an event, so we reload the file. Inline edits are done at the buffer level so we don't need to reload the file.

As per the other stuff, I see your point and will consider in future versions of the idea.

The behavoir of this is not set in stone and will be released as an experimental thing to gather users input on it. Once you get the hang of it quick edits on cursor or selection is really useful even with it's flaws. It was a feature I used all the time in avante.nvim and wanted to replicate.

Thanks for the feedback though

@cameronr

I greatly simplified the process and implemented a much simpller way of doing the replacement.

It is inspired on Codecompanion. It now simply ask for raw code and replace either the current line or the selection. Instead of trying to tell the LLM to respect a specific format.

Nice! I'm traveling for the next few weeks but will look at it in early January.