Stronger edit buffer integration

[zawedcvg]

I really like the edit diff patch/permissions integration, and was wondering if there are plans to extend it a bit. Here are some things I had in mind:

1. Not making these take away control from the user. What I mean is that whenever these pop up, it forces the user the respond to them, which takes me out of whatever I am doing. Would be nice to have an option so that it is say in the topright as a notification and I can switch to it at any point.
2. Another thing is similar to the partial diff, but instead, if one could add lines/make changes to the new diff and then accept the entire thing. This would probably need some changes to how accept/reject works but should be doable.
3. Allow edit integration with any of the popular diff plugins. So that anyone of them can be used to view the diffs/accept changes, allowing much more fine-grained control on the diffs.

Let me know if these are inline with the direction of the plugin or not. If it is, I would be happy to help integrate these.

[nickjvandyke]

I like 1 for edits, seems reasonable and simple. I presume we can open the new :diffpatch tab without switching to it, or instantly switch to the previous tab. And maybe notify the user if it's not obvious.

For permission requests though I'm not sure. I agree it's disruptive. But I like leaning on vim.ui.select rather than manage a non-standard floating window with keybinds etc. However a different approach could resolve the issue that we can't close the select dialog when the user responds to the request in the OpenCode TUI, which I'd like.

2 depends mostly on Neovim's :diffpatch. I'd expect it to "just work"? The plugin would just need to respond to the edit request after. Probably with a rejection, but maybe acceptance would work? I'm actually not sure whether OpenCode writing the diff, or Neovim applying the patch (with user edits) takes priority.

3: See #224. As best I could tell, other diff plugins are only meant to work with git directly - not patches. I'd be glad to be wrong though! But even then, at most I'm willing to expose a hook for users to wire up their diff provider of choice. Officially supporting integrations in plugin code is a huge maintenance burden.

[zawedcvg]

1. Sounds good. I don't completely understand the different approach part for edit. Could you reexplain that?

2 and 3. Sounds good as well. i am willing to take a look into them. I was hoping for just a hook as well, so that works out

[nickjvandyke]

For 1, I assume you feel it's disruptive because it immediately opens and focuses the diff tab right? So we could open the difftab w/o focusing it; then the user views it at their leisure. Or if Neovim must focus the new tab when opening, we quickly change focus back to the previous tab.

For 2, I'd prefer acceptance if possible; rejecting the request but applying the changes might confuse the LLM.

Let me know what you find with 3! The first question is whether other diff plugins work with patches, and what we'd need to expose. Then second question is whether to expose a config callback, or an autocmd example.

[zawedcvg]

for 1, I mistyped, I mean the permissions part

[nickjvandyke]

Ah gotcha. I meant if we were to show say a floating window in the bottom corner and listen for certain keys to respond to the generic (non-edit) permission request. Rather than the current blocking vim.ui.select. Not sure if you were even talking about generic permission requests though, or just edits.

[zawedcvg]

yea I meant both edit and non edit perms. basically anything that doesn't block while letting me know that approval is pending would be the ideal

[nickjvandyke]

I see, thanks for elaborating!

For edits I think background the diff tab is ideal. The keymaps should live in its buffers for consistency with the native :diffpatch.

For generic permission requests, I don't see an obvious solution. I want something standard and simple (for both my and users' sake), which would be vim.ui.select, but it's blocking. And is impossible to dismiss programmatically if the user responds to the permission request in OpenCode's TUI. vim.ui.select seems to block Neovim too, so we don't run subsequent SSE autocmds (i.e. permission.replied), and even if it did, I can't manage to programmatically close vim.ui.select, whether native or the snacks.picker.

Imo supporting generic permission requests adds little value anyway, and I was already considering removing it. But I'd prefer to find a good solution instead.

[r0ckHopper]

Hey, regarding non-intrusive permissions, I implemented a floating buffer locally that shows the permissions.
I can clean it up and share after work.

[zawedcvg]

i really like this!

[r0ckHopper]

i really like this!

I had to zip it because can't upload .lua file

opencode-permissions.zip

[r0ckHopper]

Sorry for taking so long, needed to do fix up

The way you use this is by adding the file in zip to ur config then copying the following after your opencode.nvim plugin is loaded
Be sure to replace exp.opencode-permissions with the file's relative path from lua/ folder, e.g. mine is in lua/exp/opencode-permissions.lua which equals exp.opencode-permissions

vim.schedule(function()
	local perm = require("opencode.events.permissions")
	local orig = perm.request
	perm.request = function(event, server)
		require("exp.opencode-permissions").handle(event, server)
		if not (event.type == "permission.asked" and event.properties.permission ~= "edit") then
			orig(event, server)
		end
	end
end)

for some custom keybinds you can do the following

vim.keymap.set("n", "<C-h>", function() require("exp.opencode-permissions").move_left() end, { desc = "Permission: select left" })
vim.keymap.set("n", "<C-l>", function() require("exp.opencode-permissions").move_right() end, { desc = "Permission: select right" })
vim.keymap.set("n", "<leader><CR>", function() require("exp.opencode-permissions").confirm() end, { desc = "Permission: confirm" })
vim.keymap.set("n", "<C-n>", function() require("exp.opencode-permissions").next_permission() end, { desc = "Permission: next request" })
vim.keymap.set("n", "<C-p>", function() require("exp.opencode-permissions").prev_permission() end, { desc = "Permission: prev request" })
vim.keymap.set("n", "<leader>op", function() require("exp.opencode-permissions").toggle() end, { desc = "Toggle permission window" })

feel free to reach out if its not working out.

[r0ckHopper]

Added this in a PR #304 (comment) into opencode.nvim as well. if it gets merged then will ping you here and then you don't need this patch for it

[nickjvandyke]

Thanks for giving it a shot! I'm hesitant to merge that much code for a small use case though. I'd also prefer to keep the solution somewhat standard.

What if we cached permission request IDs and added entries to the select() menu for always/accept/reject when present? Then users can call that at will when a permission is requested, rather than be interrupted. It's not perfect, but it's simple and fits the existing UX.

[nickjvandyke]

Not making these take away control from the user. What I mean is that whenever these pop up, it forces the user the respond to them, which takes me out of whatever I am doing. Would be nice to have an option so that it is say in the topright as a notification and I can switch to it at any point.

I considered the plugin's philosophy a bit more. It's designed for focused pairing with a single OpenCode instance. Hence the server auto-connecting and blocking permission/edit requests. So async support isn't a priority. I've clarified that philosophy in the docs.

This is in addition to the existing desire to not re-implement OpenCode TUI functionality (detailed permission review + reply).

However I just added better workarounds in the last few commits: you can now disable auto-connect, and manually disconnect from servers. That way you can make requests to various OpenCode servers without getting blocking events from them all the time, and easily jump between servers. I hope that helps!