windows: improve WIN32ungetch #388
Conversation
WIN32ungetch does serve the purpose it was added for - unget a zero value which is the first-of-two return values of a scan code. However, there were some cases which never worked, like ungetting any UTF-8 byte except the first (of a sequence of up to 4), where the next WIN32getch call simply ignores the ch argument to WIN32ungetch. Additionally, some other cases got broken at 6fd6739 , because the unget code was depending on buggy unicode behavior - which is now fixed. E.g. unget the second-of-two scan code return values is broken. Instead of trying to modify the quite-complex KB queue state (unicode state, x11 mouse state, scan code state) in a way which will restore the current state after the next WIN32getch call, this commit simply bypasses the KB queue state, and should ensure it always works.
|
Thanks for merging it. I noticed that the commit was merged with the author Did github change the author during the merge? I don't recall it happening in the past with PRs... Also, just noticed, for completeness, |
|
I don't know why the Author name is set like that. I just clicked "Squash and merge" like I always do to merge a PR. |
Hmm, I'll try to figure out why that happened.
Yeah, I noticed. Thanks. |
Right. I've been told it might have been the "squash" part. You could have also done "Rebase and Merge", which should be effectively the same as "rebase and squash" if there's only one commit - as was the case here, though possibly without github rewriting the author. If the PR has more than one commit then "rebase and merge" would also preserve the individual commits, if you want that. For what it's worth, In other projects when I merge a PR I typically use "rebase and merge" (and if it needs to be squashed first, then I'd typically ask the author to do that, if they know how). So just FYI, and maybe next time try "Rebase and merge" ;) |
WIN32ungetch does serve the purpose it was added for - unget a zero value which is the first-of-two return values of a scan code.
However, there were some cases which never worked, like ungetting any UTF-8 byte except the first (of a sequence of up to 4), where the next WIN32getch call simply ignores the ch argument to WIN32ungetch.
Additionally, some other cases got broken at 6fd6739 , because the unget code was depending on buggy unicode behavior - which is now fixed. E.g. unget the second-of-two scan code return values is broken.
Instead of trying to modify the quite-complex KB queue state (unicode state, x11 mouse state, scan code state) in a way which will restore the current state after the next WIN32getch call, this commit simply bypasses the KB queue state, and should ensure it always works.