Fix handle_shortcut_overlay_key for cross-platform consistency
#7583
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.
Summary
?inhandle_shortcut_overlay_keyfails to trigger on some platforms (notably Windows). Current match requiresKeyCode::Char('?')withKeyModifiers::NONE. Some terminals setSHIFTwhen producing?(since it is typicallyShift + /), so the strictNONEcheck prevents toggling.Impact
?with an empty composer often does nothing, leading to inconsistent UX compared to macOS/Linux.Root Cause
?may includeSHIFT. The code enforcesmodifiers == NONE, so valid?presses withSHIFTare ignored. AltGr keyboards may also surface asALT.Repro Steps
?.Fix Options
Option 1 (preferred): Accept
?regardless ofSHIFT, but rejectCONTROLandALT.KeyModifiers::NONEonly.SHIFT, disallowCONTROL | ALT.Option 2: Platform-specific handling (Windows vs non-Windows).
#[cfg(target_os = "windows")].?withSHIFT; on other platforms, retain current behavior.close #5495