Hardcoded Ctrl/Cmd+Enter queue shortcut is invisible to keymap conflict detection, and its hint is inverted for the default queue_mode

[ianalitis]

Summary

jcode hardcodes Ctrl+Enter / Cmd+Enter as its "alternate enter" (queue) shortcut, but two defects make it unreliable and confusing:

1. It is silently swallowed by a terminal-level binding, and jcode's own keymap conflict detector does not know the chord exists. Ghostty's default config binds super+enter=toggle_fullscreen, so Cmd+Enter never reaches the TUI. crates/jcode-setup-hints/src/keymap/conflicts.rs enumerates the built-in prompt-jump fallbacks (cmd+k, cmd+j, cmd+[, cmd+], ctrl+[, ctrl+]) but not alternate_enter, so no conflict warning is ever produced.

2. The hotkey hint describes the opposite of the default behavior. crates/jcode-tui/src/tui/app/hotkey_feedback.rs labels Ctrl/Cmd+Enter as "send now, bypassing queue mode". But send_action (crates/jcode-tui/src/tui/app/input.rs:1313) with the default queue_mode = false makes alternate-enter queue the message, while plain Enter interleaves. The label is only correct when queue_mode = true.

Environment

• jcode 0.88.427-dev (3be93ab50), macOS (darwin), built from source
• Ghostty 1.3.1, TERM=xterm-ghostty
• Default config: [display] queue_mode = false

Repro (finding 1)

1. In Ghostty with its default keybindings, run jcode and start a turn (is_processing is true).
2. Type a follow-up message and press Cmd+Enter.
3. Expected: the message is queued (alternate enter). Observed: nothing happens to the message; Ghostty toggles fullscreen instead.

Evidence:

• ghostty +list-keybinds | grep enter reports the terminal owns the chord:

  keybind = super+enter=toggle_fullscreen
  keybind = super+shift+enter=toggle_fullscreen
  

• With keybind = super+enter=unbind added to the Ghostty config, Cmd/Ctrl+Enter reaches the TUI and the queue shortcut works.

The encoding pipeline itself is fine, so this is purely a terminal-claims-the-chord problem:

• With jcode's kitty flags pushed (DISAMBIGUATE_ESCAPE_CODES | REPORT_EVENT_TYPES | REPORT_ALTERNATE_KEYS = 1|2|4, exactly what keyboard_enhancement_flags() requests), a raw probe in Ghostty 1.3.1 received:

  ctrl+enter   -> ESC[13;5u
  shift+enter  -> ESC[13;2u
  plain enter  -> \r
  

  crossterm 0.29 decodes ESC[13;5u as Enter + CONTROL, so is_alternate_enter matches once the terminal stops eating the chord.

Repro (finding 2)

With the default queue_mode = false, during a running turn:

• plain Enter -> Interleave (sends immediately, interleaved with the running turn)
• Ctrl/Cmd+Enter -> Queue (deferred)

That is the opposite of the hint text "send now, bypassing queue mode". The label is accurate only when queue_mode = true.

Root cause

• is_alternate_enter (crates/jcode-tui/src/tui/app/input.rs:1110) accepts Enter with CONTROL | SUPER | META, but the chord is not a KeybindingsConfig field and is absent from the hardcoded-chord list in crates/jcode-setup-hints/src/keymap/conflicts.rs, so conflict detection cannot see it.
• hotkey_feedback.rs hardcodes a single label for both queue_mode values.

Proposed fix

1. Add alternate_enter (ctrl+enter, cmd+enter) to the built-in chord list in conflicts.rs, so a terminal or macOS binding claiming it produces a conflict warning just like the prompt-jump fallbacks do.
2. Make the alternate-enter hint text depend on queue_mode (e.g. "queue this message" when queue_mode = false, "send now, bypassing queue mode" when queue_mode = true).
3. Optionally, make alternate_enter configurable so a terminal that legitimately wants Cmd+Enter can be routed around without losing the feature.

[1jehuang]

Thanks for the thorough report! Fixed in 85b7105:

1. ctrl+enter / cmd+enter are now enumerated as built-in alternate_enter chords in keymap conflict detection, so Ghostty's default super+enter=toggle_fullscreen produces a conflict warning (new test detects_terminal_claiming_alternate_enter).
2. The hotkey hint now follows queue_mode: "queue this message until the turn ends" when off, "send now, bypassing queue mode" when on (test alternate_enter_description_follows_queue_mode).

Your optional item 3 (making alternate_enter configurable) is a config-surface decision and is left for the maintainer.

---

Jcode agent (automated triage), on behalf of @1jehuang