Report alternate keys for shifted keyboard symbols

[1jehuang]

Summary

• request alternate key reporting from the Kitty keyboard protocol
• preserve the existing decision not to report every key as an escape code
• cover both flags in the focused unit test

Verification

• cargo test -p jcode-tui --lib tui::tests::keyboard_enhancement_flags_avoid_report_all_keys_escape_mode -- --exact

Fixes #870

---

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

[1jehuang]

CI follow-up: the formatting gate now passes. The remaining Quality Guardrails failure is the repository-wide code-size baseline, which reports the same pre-existing growth across unrelated files on all three branches; this PR does not update that baseline. Platform build/test jobs are still queued.

---

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

[greptile-apps]

Greptile Summary

The TUI now requests Kitty alternate-key reporting, but this changes AltGr input delivery in a way the current input fallback cannot handle. On affected layouts, ordinary symbols such as @ are dropped instead of inserted.

Confidence Score: 4/5

Not safe to merge until alternate-key reporting preserves layout-produced Ctrl+Alt/AltGr characters.

One verified user-input failure remains: the enabled protocol mode can turn a layout-produced printable symbol into an alphanumeric base key with Ctrl+Alt modifiers, which the TUI intentionally declines to insert.

Files Needing Attention: crates/jcode-tui/src/tui/mod.rs; crates/jcode-tui/src/tui/app/input.rs

T-Rex Logs

What T-Rex did

• T-Rex posted a P1 finding and produced a proof for it.
• T-Rex performed general-contract-validation to show that alternate-key handling routes None results and does not insert characters for Ctrl+Alt base keys.
• T-Rex reviewed the keyboard-event harness sources and Jcode input policy reproduction scripts to validate the reported findings.
• T-Rex inspected regression and alternate-key flow logs to confirm consistent behavior across legacy and alternate-key paths.

_{Ran code and verified through T-Rex}

Comments Outside Diff (1)

1. General comment

   Kitty AltGr printable characters are dropped after REPORT_ALTERNATE_KEYS is enabled

   • Bug
     • A Kitty CSI-u event representing Ctrl+Alt+2 with layout-produced/associated text @ is delivered by Crossterm 0.29 as KeyCode::Char('2') with CONTROL | ALT. Jcode consequently declines to insert text, so users on layouts that require AltGr can lose ordinary printable input such as @.
   • Cause
     • Crossterm’s current parser only substitutes the alternate-key codepoint when SHIFT is present; it does not expose Kitty associated text on KeyEvent. Jcode’s fallback at crates/jcode-tui/src/tui/app/input.rs:1310-1342 accepts Ctrl+Alt only when Crossterm already supplied a non-alphanumeric final symbol. With the base key 2, is_layout_modified_text_char('2') is false. crates/jcode-tui/src/tui/app/remote.rs:1984-1985 then receives no text and does not call input insertion.
   • Fix
     • Do not enable REPORT_ALTERNATE_KEYS until Crossterm exposes associated text/alternate key data for Ctrl+Alt layout text, or update to a Crossterm version/API that does and pass that terminal-delivered associated text through text_input_for_key_event. Do not synthesize @ from 2 because it is layout-specific.

   _{Ran code and verified through T-Rex}

Prompt To Fix All With AI

### Issue 1
crates/jcode-tui/src/tui/mod.rs:97
**Kitty AltGr characters are discarded**

Enabling `REPORT_ALTERNATE_KEYS` makes Kitty send layout-produced AltGr input such as `@` as a base key plus Ctrl+Alt. Crossterm 0.29 delivers the Ctrl+Alt+2 sequence as `Char('2') + CONTROL | ALT`; the current fallback rejects that alphanumeric base key and inserts nothing. Users on AltGr-based layouts therefore cannot enter ordinary printable characters. Leave this mode disabled until terminal-associated text can be consumed, or upgrade and route an API that exposes it.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (2): Last reviewed commit: "ci: validate integrated branch" | Re-trigger Greptile}

[1jehuang]

Ubuntu follow-up: the suite reached 2,170 passing TUI tests and failed only pinned_todos_payload_stays_empty_when_config_off, the independently reproduced cache-isolation defect fixed by #880. The focused tests for this PR pass, as do macOS, Windows, formatting, cross-target, SDK, installer, PowerShell, release, linked-issue, and Greptile checks.

---

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

[1jehuang]

CI dependency update: this PR is now stacked on #880 so Ubuntu validates this change with the independently verified pinned-todos isolation fix present. After #880 merges, the base can return to master without changing this PR’s issue-specific commit.

---

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

[1jehuang]

Integration validation update: the base is temporarily set to master so the repository’s CI workflow runs against the head containing both this fix and prerequisite #880. After terminal results are captured, the PR will be restored to the stacked base so its review diff remains issue-specific.

---

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

[greptile-apps]

Kitty AltGr characters are discarded

Enabling REPORT_ALTERNATE_KEYS makes Kitty send layout-produced AltGr input such as @ as a base key plus Ctrl+Alt. Crossterm 0.29 delivers the Ctrl+Alt+2 sequence as Char('2') + CONTROL | ALT; the current fallback rejects that alphanumeric base key and inserts nothing. Users on AltGr-based layouts therefore cannot enter ordinary printable characters. Leave this mode disabled until terminal-associated text can be consumed, or upgrade and route an API that exposes it.

Artifacts

Crossterm PTY keyboard-event harness source

• Rust source reads three real Crossterm keyboard events under raw mode from the PTY driver, with the takeaway that library delivery is measured rather than inferred.

Kitty and legacy keyboard-event PTY driver source

• Python source injects legacy printable bytes and Kitty CSI-u alternate-key sequences into the harness, with the takeaway that both conditions use the same runnable event reader.

Keyboard harness capture command source

• Shell source runs the PTY driver and writes command, working directory, output, and exit code into paired captures, with the takeaway that the comparison is traceable.

Legacy printable keyboard delivery before alternate-key reporting

• Executed `python3 trex-artifacts/keyboard-alternate-keys-driver.py before` in `/home/user/repo` and captured `a`, `(`, and `@` as printable Crossterm events, with the takeaway that legacy delivery preserves final layout text.

Kitty alternate-key keyboard delivery after alternate-key reporting

• Executed `python3 trex-artifacts/keyboard-alternate-keys-driver.py after` in `/home/user/repo` and captured `Char('2') + CONTROL | ALT` for the Kitty AltGr sequence whose layout text is `@`, with the takeaway that the printable text is absent from the delivered event.

Executable Jcode Ctrl+Alt printable-input policy reproduction source

• Python source consumes the real PTY event and executes a literal translation of Jcode’s current `input.rs:1310-1342` policy, with the takeaway that the observed Crossterm event is tested against the actual Jcode decision.

Jcode Ctrl+Alt printable-input reproduction command source

• Shell source executes the Jcode policy reproduction and records command, working directory, exit code, and output, with the takeaway that the loss is reproducible in one command.

Jcode Ctrl+Alt AltGr printable-input loss reproduction

• Executed `python3 trex-artifacts/jcode-altgr-printable-repro.py` in `/home/user/repo`; it reports `Char('2') + CONTROL | ALT`, `JCODE_text_input_for_key(...)=None`, and no insertion instead of expected `@`, with the takeaway that the failure is reproduced.

Existing Jcode Ctrl+Alt final-symbol regression test

• Executed `cargo test -p jcode-tui test_disconnected_control_alt_symbol_inserts_layout_translated_text --lib -- --nocapture` in `/home/user/repo`, which passes when the final symbol `@` is already delivered, with the takeaway that the failure is specifically the base-key event shape produced by Kitty/Crossterm.

Existing Jcode shifted-symbol regression test

• Executed `cargo test -p jcode-tui test_disconnected_key_event_shift_slash_preserves_layout_translated_slash --lib -- --nocapture` in `/home/user/repo`, which passed, with the takeaway that shifted terminal-delivered symbols remain handled.

Jcode shifted printable fallback regression suite

• Executed `cargo test -p jcode-tui shifted_printable_fallback --lib -- --nocapture` in `/home/user/repo`, with all three fallback tests passing, with the takeaway that only the Ctrl+Alt base-key case remains unsafe.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/jcode-tui/src/tui/mod.rs
Line: 97

Comment:
**Kitty AltGr characters are discarded**

Enabling `REPORT_ALTERNATE_KEYS` makes Kitty send layout-produced AltGr input such as `@` as a base key plus Ctrl+Alt. Crossterm 0.29 delivers the Ctrl+Alt+2 sequence as `Char('2') + CONTROL | ALT`; the current fallback rejects that alphanumeric base key and inserts nothing. Users on AltGr-based layouts therefore cannot enter ordinary printable characters. Leave this mode disabled until terminal-associated text can be consumed, or upgrade and route an API that exposes it.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.