feature: option for provider.cmd to be a table

[dyamon]

Did you check the docs?

• I have read all the docs

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

The configuration option provider.cmd is a string, so if I want to provide a more complex startup command (e.g., opencode --continue) I should write it as a single string.
The problem is that providers like kitty use a table to build up the command to launch (and rightly so), but then this line would cause the following error

opencode --continue failed to start with error: exec: "opencode --continue": executable file not found in $PATH

meaning that opencode --continue is considered a single command and not a command + args.

Describe the solution you'd like

It would be probably a good solution to have provider.cmd either a string or a table so that providers like kitty can append instead of adding to the table. Clearly this will possibly influence other providers as well.

Describe alternatives you've considered

The alternative would be to change the code in the kitty provider by splitting the provider.cmd config on and adding each "word" as a separate element to the table.
This solution is probably simpler but other providers that have the same problem (if any, I haven't checked) won't benefit from it.

Additional context

I might be able to work on this myself if the solution sounds reasonable.

[NickvanDyke]

ahh that's why I had that kitty error a while ago!

Your proposition makes sense. I looked at the other provider impls and they generally already accept tables, or convert the string to a table themselves.

I think making opencode.provider.Opts.cmd string|string[] makes sense! It'd be simpler if we made it only string[] but users may not like that.

Then we just have to convert string to string[] in the providers that only accept the latter. And handle this where we auto-append --port <port>.

Or if this is only an issue with kitty (?), perhaps we keep it simple and just split self.cmd in it?