libuv
libuv copied to clipboard
libuv
Enable quirky ANSI keys on Windows.
Fixes #1958. I've checked these bindings in plain conhost, conhost/tmux, and Windows Terminal/tmux.
Could help for someone not on a US keyboard layout to try this in their normal workflow. I tried to cover those cases but I use a US keyboard layout so I can't say for sure if there's not some quirks I missed.
Other than that, I've been using this patch daily in neovim for months with no issues. I hope this is a small enough/well documented enough change, because doing automated tests for all the variations of regular console/conpty/conpty over WSL interop/keyboard layouts is a pretty daunting project that I probably couldn't take on for a while.
@libuv/windows This PR is in need of review. It looks okay to me but I'm not qualified to judge.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
So this is unfortunately more complicated than I'd thought (of course it is). At least for console apps, VkScanKey doesn't use the current keyboard layout, it uses whichever the app was started with, so you need to listen for WM_INPUTLANGCHANGE which requires a WndProc somewhere which libuv currently doesn't appear to have...
It seems to me like there are a couple of options here:
- Load the current keyboard layout on every key press. This option doesn't feel that great to me, but...?
- Do it the "right" way, creating a WndProc and caching the keyboard layout and/or the VK code for the
/key when the language changes. - Pull the VK code check into a global that's checked at startup, commit this with the caveat that it doesn't handle keyboard changes correctly (really only affects the
/key) and create a new issue for this.
Pull the VK code check into a global that's checked at startup, commit this with the caveat that it doesn't handle keyboard changes correctly (really only affects the / key) and create a new issue for
That one.
1 or 3 sounds good to me. We already can’t synchronize the stream exactly. I’d slightly lean towards doing 1 though and/or rereading it occasionally instead of at startup (eg whenever setting the mode to raw)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
@parkovski were you still working on making this functional (https://github.com/libuv/libuv/pull/2535#discussion_r371508163)?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hey, life has been hectic for a while. I do want to get this fixed, I'll look into it in the next couple weeks. Iirc there were lots different setups to test and I'll need to refamiliarize myself with them.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.
Did you get a chance to resolve https://github.com/libuv/libuv/pull/2535#issuecomment-580394201? (https://github.com/libuv/libuv/pull/2535#discussion_r369175125)