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

[PR #8040] fix(tui): fix Shift+Enter newline on Windows #12601

New Issue
Closed
opened 2026-02-16 18:17:30 -05:00 by yindo · 0 comments
yindo commented 2026-02-16 18:17:30 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/anomalyco/opencode/pull/8040

State: closed
Merged: No

What does this PR do?

Video
Fixes #8038

Summary

Fixes Windows prompt behavior where Shift+Enter was treated like Enter (submitting) instead of inserting a newline, restoring the intended “newline vs submit” UX.

Details

  • Observed behavior (Windows Terminal/ConPTY): Shift+Enter can be delivered as an unmodified return key event, so it matches the textarea’s return → submit binding (same path as plain Enter).
  • Implementation: Add a Windows-only modifier fallback in packages/opencode/src/cli/cmd/tui/context/keybind.tsx:
    • Load user32.dll via bun:ffi and call GetAsyncKeyState(VK_SHIFT) (VK_SHIFT = 0x10).
    • When receiving an event with:
      • evt.name === "return"
      • evt.shift/ctrl/meta/super/hyper all false
      • GetAsyncKeyState indicates Shift is currently down (state & 0x8000)
      • then set evt.shift = true before matching keybinds.
  • Scope control (narrow by design): Only applies to return events with no other modifiers and only on process.platform === "win32", so the change is intentionally limited to the broken case.

How did you verify your code works?

  • The attached screen capture makes the corrected behavior evident end-to-end on Windows (newline insertion with Shift+Enter, submit with Enter).
  • Ran bun run typecheck (repo typecheck via the pre-push hook / turbo typecheck).
**Original Pull Request:** https://github.com/anomalyco/opencode/pull/8040 **State:** closed **Merged:** No --- ### What does this PR do? [Video](https://github.com/user-attachments/assets/35dff786-2811-474e-9a05-e9249734011b) Fixes #8038 ### Summary Fixes Windows prompt behavior where `Shift+Enter` was treated like `Enter` (submitting) instead of inserting a newline, restoring the intended “newline vs submit” UX. ### Details - **Observed behavior (Windows Terminal/ConPTY):** `Shift+Enter` can be delivered as an unmodified `return` key event, so it matches the textarea’s `return → submit` binding (same path as plain `Enter`). - **Implementation:** Add a Windows-only modifier fallback in `packages/opencode/src/cli/cmd/tui/context/keybind.tsx`: - Load `user32.dll` via `bun:ffi` and call `GetAsyncKeyState(VK_SHIFT)` (`VK_SHIFT = 0x10`). - When receiving an event with: - `evt.name === "return"` - `evt.shift/ctrl/meta/super/hyper` all false - `GetAsyncKeyState` indicates Shift is currently down (`state & 0x8000`) - then set `evt.shift = true` before matching keybinds. - **Scope control (narrow by design):** Only applies to `return` events with *no other modifiers* and only on `process.platform === "win32"`, so the change is intentionally limited to the broken case. ### How did you verify your code works? - The attached screen capture makes the corrected behavior evident end-to-end on Windows (newline insertion with `Shift+Enter`, submit with `Enter`). - Ran `bun run typecheck` (repo typecheck via the pre-push hook / `turbo typecheck`).
yindo added the pull-request label 2026-02-16 18:17:30 -05:00
yindo closed this issue 2026-02-16 18:17:30 -05:00
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 pull-request
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#12601
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?