bug: When write is called on a file that does not exist yet, opencode.nvim is not able to pull up the diff in nvim.

[r0ckHopper]

Prerequisites

• I searched the docs
• I searched existing issues

:checkhealth opencode output

==============================================================================
opencode: 1 ⚠️

opencode.nvim ~

• OS: Linux 6.19.11-200.fc43.x86_64 (x86_64)
• nvim version: 0.12.1+v0.12.1.
• opencode.nvim git commit hash: 615634114c93335a4e7f76d943b4ba787ab364dd.
• vim.g.opencode_opts: {
  events = {
  permissions = {
  floating = true
  }
  },
  lsp = {
  enabled = true
  }
  }

opencode.nvim [binaries] ~

• ✅ OK opencode available with version 1.17.11.
• ✅ OK curl available.
• ✅ OK pgrep available.
• ✅ OK lsof available.

opencode.nvim [snacks] ~

• ✅ OK snacks.input enabled: ask() enhanced.
• ⚠️ WARNING snacks.picker disabled: select() enhanced.

Describe the bug

When you ask opencode to make an edit on a file that does not exist you get the following error
Cannot resolve OpenCode edit target file: /location/file.txt

Steps To Reproduce

1. Ask opencode to make an edit to a nonexistent file using write tool
2. get error in nvim messages

Expected Behavior

Should pull up a diff against an empty file which user can accept or reject from within nvim using da/dr

[r0ckHopper]

Actually, this was intended design based on the following in lua/opencode/events/permissions/edits.lua

    if vim.fn.filereadable(filepath) ~= 1 then
      vim.notify("Cannot resolve OpenCode edit target file: " .. filepath, vim.log.levels.ERROR, { title = "opencode" })
      return
    end

Maybe this was implemented when opencode did not handle file checking for its edit tool which it does now.
I would propose removing this cause when the file does not exist nvim compares to an empty buffer, which would be intended use.

I can put up a PR after more indepth testing.

[nickjvandyke]

Ah good catch! Thanks for digging a bit too.

Hmm, that check was added because OpenCode apparently sometimes sends a malformed filepath (i.e. neither absolute nor stable-y relative) #287

I wonder if some check could handle both cases?

Maybe this was implemented when opencode did not handle file checking for its edit tool which it does now.

If you mean that the edited filepath is reliable now and we can remove the check entirely, that'd be great!

[r0ckHopper]

If you mean that the edited filepath is reliable now and we can remove the check entirely, that'd be great!

It is speculation on my part, I don't know for sure. But I didn't see this double path issue in my testing (where I just deleted that filereadable check).

I found a similar issue on opencode's side which has been closed and the comments say it was fixed somewhere else.
anomalyco/opencode#4967

But there is no guarantee that without concrete repro steps.
@zawedcvg Do you have repro steps for your original issue so we can confirm if this has been fixed in new opencode releases?

[zawedcvg]

I don't think this issue is fixed in the latest ones, as I was testing on 1.17.x. If you ever faced an malformed issue with opencode.nvim, it was because of the different paths. I don't have a way to exactly reproduce the issue with opencode tbh. However, one thing you can try is to revert back to a commit of this plugin before #287 was merged. Its been a while so I don't remember exactly what it was, but basically the idea was to go to a repository, and test a couple of things:
toggle opencode from the base of the repo and test changes in a file couple of subdirectories down.
toggle opencode from some subdirectory and try out the same thing. One of these should lead you to have the malformed issue. One more thing you can do is just add logging to the path that opencode.nvim receives before the if statements. You will see that it is not always uniform.

Though yeah, my fix isn't perfect. I ran into the same issue you did. But I think you can parse the header of the diff to see if it is creating a new file or now. I could possibly take a look at doing that in a week or so when I have the time, but it should be doable.

Also, slight followup to what I mentioned it in my previous PR, the patch received by the plugin isn't exactly correct, because opencode sends a processed diff for pretty print, so you will probably run into some issues when using the edit buffer feature. I raised an issue in opencode anomalyco/opencode#31625, and someone made a PR for it anomalyco/opencode#33476, but it hasn't gotten attention from the maintainers yet, probably because of the large amount of PRs.