[chore/feature] : Tell OpenCode what to do differently

[jensenojs]

Currently, in the TUI, if we reject a patch, it prompts us to enter a reason; however, in this plugin, it simply interrupts the process. It would be great if we could have a similar experience here

---

[sudo-tee]

Good idea.

I would like to do one QoL refactrore before this. Where you can have an inline input when selecting the "Other" option.

This would fit well in this workflow.

I will have a jab at it and sede if it's possible

[disrupted]

sorry for the low effort comment, but I do actually prefer our current behavior. I was recently quite bummed when I used the TUI and didn't find an obvious way to halt the execution completely (circumventing this dialog). is there even a functional difference to cancelling and submitting a new prompt?

[jensenojs]

Aha, glad to see you again. However, I'm still curious why this interaction method isn't always present in TUI. It doesn't seem to trigger very stably. But we should always be able to make it optional, right?

[sudo-tee]

sorry for the low effort comment, but I do actually prefer our current behavior. I was recently quite bummed when I used the TUI and didn't find an obvious way to halt the execution completely (circumventing this dialog). is there even a functional difference to cancelling and submitting a new prompt?

You can have a look, it is still "floating window" and work just like snacks input or any other plugin that overrides vim.ui.input, it's just inline.

there is an option to opt-out of it.

#455

[sudo-tee]

@disrupted
I think I misunderstood your comment.

But yes if we add this interaction we can add an option. We could also support sending an empty reason or even add a Deny and stop option

[disrupted]

did you find which API method that would be? I can only see session.abort({ path }) (https://opencode.ai/docs/sdk/#sessions) which doesn't take any extra arguments. if the abort reason would be sent as a followup session.prompt() anyways, then our current behavior is actually more clear imo. and it allows instantly aborting

edit: found it 🤦🏻 postSessionByIdPermissionsByPermissionId({ path, body }). it takes an optional message string https://github.com/anomalyco/opencode/blob/77429f59823c8c6df9cfee95d4c663043b017f46/packages/sdk/openapi.json#L4952

[jensenojs]

origin comment now move to diffview issue

[sudo-tee]

@jensenojs I think this comment should go in the #318 Better Diffview thread. I have a couple of comments to add to it, but let's keep this thread focused

I don't want to deviate to much, as I am working on the Tell opencode differently feature

I digged a little bit because I was not able to reproduce the behavior at first.

It turns out it's only when answering a permission for a subagent that it would prompt for details about the rejection.

Should we keep the same behavior as the TUI for that specific case ?

Calling the api @disrupted provided works also on the main agent.

Maybe we can have something like this

The reject will just be the regular Reject tha stops the flow in both main agent and subagents.

[jensenojs]

Better Diffview thread. I have a couple of comments to add to it, but let's keep this thread focused

agree and ok, done

I digged a little bit because I was not able to reproduce the behavior at first.
It turns out it's only when answering a permission for a subagent that it would prompt for details about the rejection.

Yes, I did trigger that feature in Subagent at the time; I was a bit puzzled before as to why it wasn't triggering very often

Should we keep the same behavior as the TUI for that specific case ?

Keeping the default behavior consistent with tui is always the least bad choice, but personally I might configure it so that the main agent can also enjoy it, and using sth like double-press of Esc to explicitly interrupt it, Opencode's restraint on the subagent leaves me feeling a bit helpless and annoyed, even though I understand the reasoning behind it.

@sudo-tee

[sudo-tee]

I like the double escape idea instead of 2 Reject option.

[sudo-tee]

@jensenojs @disrupted

#471

you can play with the PR and see if this new workflow works for you :)

[jensenojs]

I'm feeling a little under the weather, I'll test this feature tomorrow (｡･ω･｡)ﾉ♡