feat: add wezterm integration

[chuan2984]

Integration with wezterm leveraging wezterm cli for pane management.

Wezterm does not offer a covenient focus/hide api, so kill/restart is the best we can do without complex custom window management logic
All options closely mimic the options provided by wezterm cli split-pane

[NickvanDyke]

Ty! The implementation LGTM so far. Just a couple questions regarding wezterm:

1. Is the "check if pane still exists" flow in get_pane_id necessary? Seems to me we could simplify it by just finding it every time, if that's sufficiently performant. I presume you just referenced the other providers, so I may reconsider it there too.
2. Does wezterm allow proper toggling? That is, keep opencode running and just hide/show it. Rather than start/stop it. In the tmux provider we took the latter approach only because tmux doesn't offer a proper hide/show API. May warrant adding hide() to the provider API.

[chuan2984]

1. Is the "check if pane still exists" flow in get_pane_id necessary? Seems to me we could simplify it by just finding it every time, if that's sufficiently performant. I presume you just referenced the other providers, so I may reconsider it there too.

Yes, you got me, I mostly just refererenced the other provider implementations, namely tmux and kitty. Now thinking about it, thats an interesting question, With the current approach, I guess there are two problems:

1. that the pane can be still open, but opencode could be closed, since the cli cmd doesnt check that the tile still is opencode.
2. that if the memorized pane is closed, but another pane with opencode is open, The current approach would try to create another pane with opencode, resulting in two pane with opencode?

Now with the always trying to find it approach, it works more like what you advertised in the readme that if theres one opencode thats open in the cwd, this plugin will find it. Effectively, turning the get_pane_id function into a always find the id of the pane that has one opencode running.

2. Does wezterm allow proper toggling? That is, keep opencode running and just hide/show it. Rather than start/stop it. In the tmux provider we took the latter approach only because tmux doesn't offer a proper hide/show API. May warrant adding hide() to the provider API.

Sadly, wezterm does not have a show/hide API. The only thing that is the closest to it would be trying to maximize. So the toggle would effectively become maximize neovim if opencode pane is visible otherwise un-maximize then focus the pane that has opencode, which was what I actually was thinking about when trying to implement this. The kill() function in this case might be cleaner.
As for the hide(), i think this is more preferrable. We could have another toggle function thats just show vs hide

[NickvanDyke]

Yes, you got me, I mostly just refererenced the other provider implementations, namely tmux and kitty

No worries that's totally reasonable, and it's on me for not catching this suggestion earlier in those providers!

Now with the always trying to find it approach, it works more like what you advertised in the readme that if theres one opencode thats open in the cwd, this plugin will find it. Effectively, turning the get_pane_id function into a always find the id of the pane that has one opencode running.

Nice, let's go with always-find then!

Sadly, wezterm does not have a show/hide API. The only thing that is the closest to it would be trying to maximize.

Ah gotcha, thanks for explaining. Jerry-rigging minimize/maximize for show/hide would mess with additional windows right? And I suppose DIYing show/hide could confuse wezterm users anyway because they don't expect that behavior in wezterm. So let's stick with killing the window (if I understand you correctly) in toggle().

[chuan2984]

Hey @NickvanDyke, the kill/start toggle is quite fast - this is probably the best we can
get in wezterm without some sophisticated custom window management.

I have a question about the focus behavior. With show() implemented, I get the following focusing behavior:

1. ask('@this: ') with no opencode running, spawns opencode pane then focuses the new opencode pane
2. ask('@this:') with existing opencode, no focus switch
3. toggle() with no opencode running, spawns opencode pane then focuses the new opencode pane
4. page up/down focuses the new opencode pane

Without show() being implemented,

1. same
2. same
3. same
4. page up/down does not switch focus

• I couldnt find where show() was being called by the command() function, but im guessing it gets called. If this is the case, could you clarify if that was intended?
• for focusing when opencode just spawns, i can add a pane_id of the current Neovim window, and switch it back when no existing opencode is running. see this commit

Please advise~

[NickvanDyke]

Ah good points! command() does call show() because the original snacks provider easily shows w/o focusing. But that's less feasible with these new providers.

I like your described behavior w/o show() implemented and the workaround to switch focus back to Neovim when opencode is spawned. Let's do that!

Separately I'll reconsider my provider abstraction with these new provider behaviors in mind. You don't have to worry about them for this PR, but I'm thinking:

1. Rather than require the provider to implement toggle, we abstract provider.is_started and provider.is_shown (if supported), and then call provider.start/stop/show/hide depending on availability.
2. Launch opencode with --continue to resume the last session. This makes start/stop function similarly to show/hide for providers that only support the former.

[chuan2984]

It is ready for review, thanks for your time

[NickvanDyke]

Thank you for iterating and the insightful discussion! 😀