fix(keybind): match by baseCode for non-Latin layouts

[simonklee]

Keyboard shortcuts like Ctrl+C fail on non-Latin input layouts because the terminal reports the layout-specific character name instead of the Latin one. Fall back to the baseCode field from the Kitty keyboard protocol to identify the physical key when names differ. Consolidate inline modifier checks in TUI components behind the new matchParsedKey helper.

Closes #21163
Closes #21177

waiting for next opentui release

[github-actions]

This PR doesn't fully meet our contributing guidelines and PR template.

What needs to be fixed:

• PR description is missing required template sections. Please use the PR template.

Please edit this PR description to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Hey! Your PR title keybind: match by baseCode for non-Latin layouts doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential duplicate found:

• PR fix(tui): resolve keyboard shortcuts failing with non-English IME #21177: "fix(tui): resolve keyboard shortcuts failing with non-English IME"
  • fix(tui): resolve keyboard shortcuts failing with non-English IME #21177

Why it's related: Both PRs address the same core issue - keyboard shortcuts failing on non-Latin/non-English input layouts. PR #21177 likely attempted to fix the same problem that PR #22170 is addressing with the baseCode approach from the Kitty keyboard protocol. This suggests #21177 may be a previous/incomplete attempt at solving issue #21163, or they may overlap in scope.

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[MinseongS]

@simonklee I worked on the same issue in #21177 and ran into a problem with the baseCode approach.

When I debugged key events with Korean IME on VSCode's integrated terminal and macOS Terminal, baseCode was always undefined:
name="ㅊ" ctrl=true baseCode=undefined raw="\x1b[12618;5u" source=kitty

Most terminals implement Kitty keyboard protocol partially and don't include the baseCode field. So getBaseCodeName() will return undefined, and match() will just compare "c" === "ㅊ" which is false.

This means the fix won't actually work on VSCode terminal, macOS Terminal, and likely most other terminals that don't send baseCode. That's why I added a character-to-QWERTY mapping table as a fallback in my PR.

Also, a minor note on the test — "x" is paired with "ㅊ" (baseCode 99), but on Korean 2-Set layout, the x key produces "ㅌ", not "ㅊ". "ㅊ" is the c key.

Might be worth combining both approaches — use baseCode when available, fall back to a mapping table when it's not.

[simonklee]

@simonklee I worked on the same issue in #21177 and ran into a problem with the baseCode approach.

When I debugged key events with Korean IME on VSCode's integrated terminal and macOS Terminal, baseCode was always undefined: name="ㅊ" ctrl=true baseCode=undefined raw="\x1b[12618;5u" source=kitty

Most terminals implement Kitty keyboard protocol partially and don't include the baseCode field. So getBaseCodeName() will return undefined, and match() will just compare "c" === "ㅊ" which is false.

This means the fix won't actually work on VSCode terminal, macOS Terminal, and likely most other terminals that don't send baseCode. That's why I added a character-to-QWERTY mapping table as a fallback in my PR.

Also, a minor note on the test — "x" is paired with "ㅊ" (baseCode 99), but on Korean 2-Set layout, the x key produces "ㅌ", not "ㅊ". "ㅊ" is the c key.

Might be worth combining both approaches — use baseCode when available, fall back to a mapping table when it's not.

Thanks — that was actually helpful. We'll keep on iterating on this.

[MinseongS]

Sounds great! Looking forward to seeing the update. Let me know if you need any more specific cases for Korean layouts.