-
Notifications
You must be signed in to change notification settings - Fork 946
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
on MacOS, Fix not sending ReceivedCharacter event for some key combination #1347
on MacOS, Fix not sending ReceivedCharacter event for some key combination #1347
Conversation
22a8f6f
to
da3cfcf
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On PR branch combinations of cmd
, option
& ctrl
with any symbol keys return KeyboardInput
events.
@chrisduerr @jayache80, does this PR resolve your issue?
I was not able to reproduce, but @jeremydr2 was able to share an event log with the missing events. Maybe he can create another log by running |
I hit C-q once. Here are the logs:
@vbogaevsky , Looks to me like it works on Mac! |
Thanks a lot for testing, looks like this should be good to go then! |
…y combination (rust-windowing#1347)" This reverts commit 9daa073. This commit introduced other bug rust-windowing#1453 with likely much more common bindings, so reverting it for now. Fixes rust-windowing#1453.
cargo fmt
has been run on this branchcargo doc
builds successfullyCHANGELOG.md
if knowledge of this change could be valuable to usersThis PR fixes #1267
It seems that Ctrl+Q is some prefix key when
hasMarkedText
returnsNO
.For example, it emits '\u{1e}' when input Ctrl+Q and Arrow-up key.
So I modified
hasMarkedText
to returns YES always.I'm not 100% sure about the mean of this change, but I think it's OK because
hasMarkedText
returns alwaysYES
after inputting Option+N in previous implementation.A key with Command no longer emits ReceivedCharacter event by this change.