anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 10:15:31 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Input Composer Program #871

New Issue
Closed
opened 2026-02-16 17:28:37 -05:00 by yindo · 2 comments
yindo commented 2026-02-16 17:28:37 -05:00
Owner
Copy Link
Copy Source

Originally created by @samholmes on GitHub (Jul 22, 2025).

Originally assigned to: @thdxr on GitHub.

I love that you can use /editor to open your $EDITOR to write out some prompt for the input (I use Neovim btw). Though, there is one subtle issue to this: you leave the opencode UI.

Why might this be an issue? You may have information within the context/chat buffer which you want to reference. Or, perhaps there is some other feature of opencode which you can want access (e.g. @ file mentions, drag-n-drop images, etc).

It would be nice if I can just pick an embedded program that runs within the input area. What if $COMPOSER env could tell opencode what program that is?

Why would this be any good? The program can be just a text editing program which can interact with its host (opencode). Opencode can ship with a default input composer program, but the community can write their own to their own preference. I imagine modal composers (vim-inspired), but also new creative ideas.

How would this work? All the program would need to do is accept input and write output. Perhaps it reads stdin, writes stderr (which opencode displays), and writes to stdout (which opencode will use as the next prompt). If the program exits (code 0) it is run again. Opencode passes its stdin to the composer program, but if you press the leader keybind (I use ctrl+space btw), then open code will of course capture the next key for one of the defined keybinds.

Is this possible? I don't see why not. Tmux already runs sub-programs (interactive shells) within its TUI, and it also follows the a leader-key pattern for its keybind featues. The trick will be to dynamically change the height of the rendered input composer area as the output of the program requires it.

Note on Leader Key

Can I make the quick argument that the leader key should be a mode? Motions are great, but modes along with an immediate feedback that you've entered a mode is way better UX. I'll accept the tmux-style leader-key escape-hatch design, but I'd much prefer that the leader key activated a mode where other keys can be defined to run opencode commands. Commands to navigate the context area block-by-block, opening a block for details, searching the buffer, etc. can all be bound to keys within that mode. I get this might get complicated cause you'd need a mode state-machine as the complexity grows. But can't we just vibe-code complex things now? I digress, but I wanted to get my thoughts out there.

Originally created by @samholmes on GitHub (Jul 22, 2025). Originally assigned to: @thdxr on GitHub. I love that you can use /editor to open your $EDITOR to write out some prompt for the input (<ins>_I use Neovim btw_</ins>). Though, there is one subtle issue to this: you leave the opencode UI. Why might this be an issue? You may have information within the context/chat buffer which you want to reference. Or, perhaps there is some other feature of opencode which you can want access (e.g. @ file mentions, drag-n-drop images, etc). It would be nice if I can just pick an embedded program that runs within the input area. What if $COMPOSER env could tell opencode what program that is? Why would this be any good? The program can be just a text editing program which can interact with its host (opencode). Opencode can ship with a default input composer program, but the community can write their own to their own preference. I imagine modal composers (vim-inspired), but also new creative ideas. How would this work? All the program would need to do is accept input and write output. Perhaps it reads stdin, writes stderr (which opencode displays), and writes to stdout (which opencode will use as the next prompt). If the program exits (code 0) it is run again. Opencode passes its stdin to the composer program, but if you press the leader keybind (I use ctrl+space btw), then open code will of course capture the next key for one of the defined keybinds. Is this possible? I don't see why not. Tmux already runs sub-programs (interactive shells) within its TUI, and it also follows the a leader-key pattern for its keybind featues. The trick will be to dynamically change the height of the rendered input composer area as the output of the program requires it. # Note on Leader Key Can I make the quick argument that the leader key should be a mode? Motions are great, but modes along with an immediate feedback that you've entered a mode is way better UX. I'll accept the tmux-style leader-key escape-hatch design, but I'd much prefer that the leader key activated a mode where other keys can be defined to run opencode commands. Commands to navigate the context area block-by-block, opening a block for details, searching the buffer, etc. can all be bound to keys within that mode. I get this might get complicated cause you'd need a mode state-machine as the complexity grows. But can't we just vibe-code complex things now? I digress, but I wanted to get my thoughts out there.
yindo closed this issue 2026-02-16 17:28:37 -05:00
yindo commented 2026-02-16 17:28:38 -05:00
Author
Owner
Copy Link
Copy Source

@thdxr commented on GitHub (Jul 23, 2025):

this requires terminal multiplexing which i do have a bunch of experience with from doing sst dev

we can eventually support it but we have plans to rework the underlying system powering all our terminal stuff - we'll visit this after

@thdxr commented on GitHub (Jul 23, 2025): this requires terminal multiplexing which i do have a bunch of experience with from doing sst dev<br><br>we can eventually support it but we have plans to rework the underlying system powering all our terminal stuff - we'll visit this after
yindo commented 2026-02-16 17:28:38 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 27, 2025):

[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!

@rekram1-node commented on GitHub (Dec 27, 2025): [automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#871
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?