Open schorrm opened 4 years ago
Thanks for the report! That's certainly curious - probably an artifact of us looking up the string from the OS for the key that's been bound. It must be the case that the ,
doesn't roundtrip on that keyboard. @schorrm are you using an actual physical Hebrew keyboard, or another keyboard with the Hebrew keyboard layout installed?
I'm marking this Help-Wanted if someone's passionate about this bug and wants to give us a hand with it ☺️
Just shift+alt on my normal (American) laptop keyboard
Yeah, this is caused by us asking Windows to map the VK
back to the character on the keyboard that is set as the user's default keyboard. It's not great... but maybe we need to consider how to deal with keybindings in a way that lets us separate VKs from characters?
Hebrew is not my default keyboard, which explains why I haven't been able to reproduce
I'm a fan of how Terminal handles shortcuts like this, btw:
I have the numbers and shift-numbers switched on my keyboard (with MSKLC) and Windows Terminal was one of the only programs that picked up on this and switched the keyboard shortcuts without me having to change anything.
Strange how it displays like that when Hebrew isn't the default keyboard though.
A quick note:
First off, loving v. 0.7. Secondly, this is a ridiculously minor bug that I haven't been able to even reproduce on my own machine. Don't really bother fixing it, I guess. But it's still undefined behavior, and I thought you might want to know that something like this can happen.
Environment
Steps to reproduce
Not sure, haven't been able to reproduce it myself.
Expected behavior
Should be Ctrl+comma displayed, IIRC.
Actual behavior
A quick note: the character here, the hebrew letter taf - ת, is comma on the hebrew keyboard