feature: Support custom diff providers (e.g., mini.diff)

[Norhua]

Did you check the docs?

• I have read all the docs

Is your feature request related to a problem? Please describe.

I'm always frustrated when reviewing code changes because the native diffpatch behavior opens two separate windows. This side-by-side approach is quite clunky and much less practical to read compared to a Unified Diff view.

Describe the solution you'd like

I would like a configuration option that allows users to set a custom diff provider, such as the mini.diff plugin, to render the diffs instead of the default behavior.

Describe alternatives you've considered

I actually used AI to modify the code locally and managed to get this working. However, since the code is entirely AI-generated and I don't have the expertise to judge its quality or potential edge cases, I decided to open this issue rather than submitting a Pull Request. I am happy to share the AI-generated code snippet if it helps as a reference!

Additional context

No response

[nickjvandyke]

I'm always frustrated when reviewing code changes because the native diffpatch behavior opens two separate windows. This side-by-side approach is quite clunky and much less practical to read compared to a Unified Diff view.

I agree, it's not ideal. I wanted to open the "new" buffer to the side, in the same tab, but that had edge cases that I couldn't resolve. A new tab was the most reliable.

I don't want to support specific integrations in plugin code - previously that quickly exploded in maintenance and just isn't practical in solo FOSS unfortunately. So between all the options, Neovim's native difftool made the most sense.

However I am open to making it easier for users to integrate themselves! And maaaybe a "Recipes" section.

What's the high-level of your code? Atm I imagine it's something like:

vim.api.nvim_create_autocmd("User", {
  group = vim.api.nvim_create_augroup("OpencodeEdits", { clear = true }),
  pattern = { "OpencodeEvent:permission.asked", "OpencodeEvent:permission.replied" },
  callback = function(args)
    ---@type opencode.server.Event
    local event = args.data.event
    ---@type number
    local port = args.data.port

    local opts = require("opencode.config").opts.events.permissions or {}
    if not opts.enabled or not opts.edits.enabled then
      return
    end

    if event.type == "permission.asked" and event.properties.permission == "edit" then
      local diff = event.properties.metadata.diff
      local filepath = event.properties.metadata.filepath
      local patch_filepath = vim.fn.tempname() .. ".patch"
      if vim.fn.writefile(vim.split(diff, "\n"), patch_filepath) ~= 0 then
        vim.notify(
          "Failed to write patch file to diff opencode edit request",
          vim.log.levels.ERROR,
          { title = "opencode" }
        )
        return
      end

      -- The plugin then uses `:diffpatch` here, but could theoretically pass it to any diff method
    end
  end
})

Copied from plugin/events/permissions/edits.lua, just doing something else with the diff.

Things I can think of to handle more of this for users:

1. Add opts.events.permissions.edits.diff with type fun(diff, reply_cb). Simpler, but I'm hesitant to circumvent the vim-y autocmd way.
2. In addition to 1. above, a configurable callback for when event.type == "permission.replied" and current_edit_request_id == event.properties.requestID. i.e. the permission has been accepted, possibly in opencode, thus we should close the request in Neovim.
3. Better event typing to make the autocmd easier to set up and use. Most fields are just string or table atm.
4. ?

[nickjvandyke]

Still thinking about this. I'm open to a flexible config option. But I need to check the API for other diff plugins. i.e. is it simple enough that users would reasonably wire it up themselves, given the option?