Resolve Latin keys through real keyboard layouts - #1965
Open
raphamorim wants to merge 1 commit into
Open
raphamorim wants to merge 1 commit into
raphamorim wants to merge 1 commit into
Conversation
This branch has not been deployed
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
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.
Stacked on #1964. That PR matches shortcuts on non-Latin layouts by mapping the physical key to its standard PC-101 position, which is kitty's model and works for any layout, but it cannot describe layouts whose Latin group is not PC-101 (Dvorak alongside Cyrillic, AZERTY alongside Arabic, Colemak, ...).
This PR adds the mechanism ghostty effectively relies on: resolving the key through the user's real keyboard layouts, at the window layer where the layout information lives.
rio-window
New
KeyEventExtModifierSupplement::base_layout_key()returning the key resolved against a Latin (ASCII-capable) layout, ignoring modifiers:TISCopyCurrentASCIICapableKeyboardLayoutInputSourcewithUCKeyTranslate, the same resolution AppKit applies to key equivalents. Skipped when the active layout already produced ASCII.Nonefor now. A follow-up can useToUnicodeExagainst a US HKL; until then the frontend falls back to the PC-101 table, which matches Windows scancode positions anyway.rioterm
base_layout_fallback_keynow prefers the platform's resolution and keeps the PC-101 table as the fallback (Windows, resolution failure). The kitty protocol's alternate-keys field intentionally stays on the PC-101 table, since the spec defines the base layout key as the key at that position in the standard PC-101 layout.All gating from #1964 is unchanged: command modifier required, layout-character bindings take precedence, Windows AltGr chords that typed text are never rewritten.
Testing