refactor(code): share newline affordances across input surfaces#4852
Merged
Mason Daugherty (mdrxy) merged 4 commits intoJul 21, 2026
Conversation
The goal-criteria review editor hardcoded "Shift+Enter newline" in its footer hints. On terminals that cannot report Shift+Enter (e.g. macOS Terminal.app), that key is indistinguishable from plain Enter and submits instead of inserting a newline, so the hint told users to press the wrong key. Use the terminal-aware `newline_shortcut()` helper the chat input already uses, so the editor advertises Ctrl+J / Option+Enter where appropriate. Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
github-actions
Bot
added
dcode
Mason Daugherty (mdrxy)
marked this pull request as ready for review
July 20, 2026 14:24
![open-swe[bot]](https://avatars.githubusercontent.com/in/1395372?s=60&v=4){kind=small}
Move the modifier-Enter / Ctrl+J newline bindings and the VSCode backslash+enter fallback into the shared PasteBurstTextArea base so the goal editor and ask_user free-text prompt gain them, not just the chat input. Add a shared newline_hint() helper and advertise the newline shortcut in the ask_user footer. Any future TextArea-based input surface that extends the shared base inherits these affordances. Co-authored-by: open-swe[bot] <open-swe@users.noreply.github.com>
open-swe
Bot
changed the title
Mason Daugherty (mdrxy)
changed the title
github-actions
Bot
added
refactor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the newline-entry inconsistencies across dcode's text-entry surfaces, and refactors so any future surface inherits the affordances.
Three gaps came out of a comparison with Codex and opencode:
backslash+enter→newline fallback (for terminals that emulate Shift+Enter that way) lived only in the chat input, so Shift+Enter submitted with a stray backslash in the goal editor and theask_userfree-text prompt.ask_userfree-text prompt never told users how to insert a newline at all.Rather than patch each surface, the shared newline affordances now live in the common
PasteBurstTextAreabase: the modifier-Enter / Ctrl+J bindings, the derived newline-key set, and the backslash+enter fallback (via small_consume_backslash_enter_newline/_track_backslash_pending/_consume_modifier_newlinehelpers). Both the chat input and the inline prompts inherit them, and any futureTextArea-based input surface that extends the base gets them for free. A sharednewline_hint()helper renders the terminal-aware shortcut (Ctrl+J/Option+Enter/Shift+Enter) consistently, now used by both the goal editor and theask_userfooter.The chat input's existing behavior — including the completion-active gating on the backslash path and key ordering — is preserved.
Made by Open SWE