client-core: a chord with an uppercase ASCII letter parses but never fires #386
Labels
No labels
priority/P0
priority/P1
priority/P2
release/v0.1.0
status/blocked
status/planned
type/bug
type/design
type/test-gap
type/tracker
No milestone
No project
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
natsukium/felis#386
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A keymap chord written with an uppercase ASCII letter (e.g.
"shift+A") parses without a warning but can never match.crates/felis-client-core/src/keymap/chord.rsstoresAasCharacter("A")with no normalization.crates/felis-client/src/keymap_adapter.rs(lift_uppercase_letter) lowercases every uppercase ASCII letter from winit and adds SHIFT, so the runtime chord is alwaysshift+a.keymap/default.rsalready stores letter chords lowercase.docs/reference/keybindings.mdnow documents the current behavior (ASCII letters match lowercase with Shift as a modifier). Decide which of these the parser should do:Either way, update the keybindings.md chord grammar to match.
Decision: option 1. The parser folds an uppercase ASCII letter to its lowercase letter plus SHIFT (
"A"and"shift+A"both parse asshift+a), the same rulelift_uppercase_letteralready applies to winit's events at runtime, so the written and the pressed chord follow one rule and configs that parse today start firing. Update the keybindings.md chord grammar to state the fold.