Windows: AltGr+Q on Brazilian ABNT2 layout opens help overlay instead of typing "/"

[nicolassmotta]

Description

On Windows, typing / with a Portuguese (Brazil ABNT2) keyboard layout requires
AltGr+Q. Windows reports this to applications as Ctrl+Alt+Q (standard Windows
behavior for layouts flagged with the AltGr modifier — confirmed for the ABNT2
driver, KBDBR.DLL: "This layout treats right Alt key as Control+Alt"). CodeWhale's
composer matches this against the global Ctrl-/ binding
(docs/KEYBINDINGS.md → "Toggle the help overlay") instead of inserting the literal
/ character, so the help overlay pops open every time I try to type a slash.

For comparison, AltGr+W (produces ? on the same layout) works fine — there's no
Ctrl-? binding in KEYBINDINGS.md, so it isn't intercepted. This isolates the bug
specifically to the Ctrl-/ global chord. Same bug class as the AZERTY AltGr fix in
#2863 / #2867, but that fix was scoped to the sidebar-focus shortcuts (Alt-!,
Alt-@, Alt-#, etc.), not Ctrl-/. #3758's QA matrix already calls out
"Verify AltGr and non-US keyboard layouts do not break normal text entry," but
scoped to Hotbar (Alt-1..Alt-8), not this chord. Global chords aren't
user-configurable yet (#436, #437), so there's no settings-based workaround —
only clipboard paste (Ctrl-V) as a stopgap.

Steps to reproduce

1. Set Windows keyboard layout to Portuguese (Brazil ABNT2)
2. Open the CodeWhale TUI (codewhale), focus the composer
3. Press AltGr+Q (physically Right Alt + Q)

Expected behavior

/ is inserted into the composer like any other character.

Actual behavior

The help overlay opens (same as pressing F1 or Ctrl-/) and / is never typed
into the composer.

Impact

Happens every single time I need to type / — a real workflow blocker for regular
DeepSeek dev work on this layout, not an edge case. Only workaround right now is
typing / elsewhere and pasting it in with Ctrl-V.

Environment

• OS: Windows (via Git Bash / MINGW64)
• codewhale version: 0.9.0 (d167c07)
• Install method: npm install -g codewhale
• codewhale doctor summary:

[github-actions]

Thanks @nicolassmotta for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[yyyCode]

Opened #4977 to fix this.

Root cause is exactly as you isolated it. On Windows, AltGr arrives as Ctrl+Alt, so AltGr+Q (/ on ABNT2) comes through as Ctrl+Alt+Q and matched the global Ctrl-/ help chord in is_help_shortcut (crates/tui/src/tui/shell_key_routing.rs). AltGr+W (?) was fine only because there's no Ctrl-? binding to intercept it — which is what pinned it to the Ctrl-/ chord.

The fix makes is_help_shortcut treat AltGr chords as text and fall through to the composer, reusing the same platform-gated key_hint::is_altgr helper the composer's is_plain_char guard already uses (the same primitive introduced by the #2863/#2867 sidebar fix — this just extends it to the one global chord it didn't cover). Plain Ctrl-/ and F1 still open help, and off-Windows a real Ctrl+Alt+/ chord is unchanged.

One heads-up for review: I don't have an MSVC toolchain on this machine, so I couldn't run the workspace cargo gates locally. I verified the logic with a standalone harness across both platform paths and confirmed formatting, but I'm leaning on CI for the added regression tests and a real build. Thanks for the precise report — the AltGr+W vs AltGr+Q comparison made this quick to pin down.