Use relative path w.r.t cwd for Context.format

[lungsin]

For some models, I got the following error because the model attempts to concatenate the absolute path with the cwd of the opencode:

I'm proposing to use relative path in conjuction with the native opencode file annotation: @<relative path>. So in above screenshot, it would be translated to @lua/klungs/plugins/opencode.lua since my cwd is ~/dotfiles/nvim.

EDIT: After a little bit of testing, it's not enough to just send @<relative path> in the prompt. We also need to specify file/directory attachments. I will investigate the opencode API later.

[nickjvandyke]

We also need to specify file/directory attachments. I will investigate the opencode API later.

opencode.nvim uses the TUI endpoints to leverage opencode's existing UI functionality, and those only support text 🙁 Even the message endpoints don't support explicit file refs. So we are at the mercy of the LLM interpreting the filepaths.

How many models have this issue? I haven't seen it but it seems like a pretty important issue on their end.

Regardless, I have been curious to write the path relative to the server's CWD for conciseness, now that we have that easily available at runtime. Just can't re-use vim.fn.fnamemodify (or whatever it's called) and need to DIY it.

[lungsin]

Even the message endpoints don't support explicit file refs.

Hmmm interesting, that seems like a pretty big hole on the opencode side. I'll investigate and open an issue on their side if the issue doesn't exist yet.

How many models have this issue? I haven't seen it but it seems like a pretty important issue on their end.

From my testing, it only happens on opus 4.7 and sonnet 4.6; although my setup is a bit peculiar. I'm proxying the query to claude SDK, so there might be misconfiguration from my part. This didn't happen for GPT models and OpenCode Go models (GLM, Kimi, etc).

Btw, the error is not a big deal since the model corrects itself and opens the correct file path. It's just a bit annoying that it happens haha. Please don't treat this as a P0/P1 bug.

Regardless, I have been curious to write the path relative to the server's CWD for conciseness, now that we have that easily available at runtime.

Actually, I've just realized that we need to handle the case where the user uses existing opencode instance that's not the same as the nvim cwd. Maybe we need to filter the opencode instances which have cwd that's an ancestor from nvim cwd. But yeah, we probably need to DIY this.

[nickjvandyke]

Maybe we need to filter the opencode instances which have cwd that's an ancestor from nvim cwd

opencode.nvim already prefers servers that overlap with Neovim's CWD 🙂 See lua/opencode/server/discovery/init.lua

Regardless, we have the server's CWD available at runtime, so Neovim's CWD doesn't matter when crafting a path relative to the server.