There is also a whole slew of issues with Polish characters. Polish keyboard setup relies on "right-alt" and a letter to get it's diacritics variation. Ie:
'ą' is 'right-alt'+a
Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
Many applications developers assign key combos with no negative checks. So 'ctrl-s', typically used for save gets triggered when user wants to type 'ś'. To repeat, "right-alt"+"s" is reported as "alt"+"control"+"s", which triggers crappy "control"+"s" checks.
Similar scenarios happen many places that check for 'alt'+'letter' without checking if control also is not pressed.
> Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
Interesting because on French AZERTY we also have an "altgr" key, and while Windows considers alt-control equivalent (ie. you cant type alt-control-à as well as altgr-à to get an @), typing altgr itself never triggers ctrl or alt shortcuts, it only goes the other way.
This is actually fascinating to me. I’ve dealt with keyboard input numerous times (not WinForms or browser either) and I always devised a way where control characters were a bitwise with the keycode. You would have to include this in any input mapping. I can totally see where this key combo issue would be a problem in a UI scenario in the browser or other shortcut-laden desktop app.
That also works the other way around -- you can use alt+control instead of right alt.
This may make sense to do with some of the more annoying key combinations, e.g. the German layout requires pressing AltGr+7 for '{'. Both keys individually are usually pressed by the right hand, but pressing the combination with the right hand alone is a very uncomfortable hand position.
As a Polish Linux user I think I'd switch between mappings in this case. One for typing źdźbłos and żółws, another to interact with shortcut-heavy apps.
I actually do this on two-alt keyboards too, because I like to use either alt for shortcuts.
The same applies for a bunch of other languages with a character that's "s" with diacritic modifier, and ctrl-s as save isn't as bad - the most horrible case of this that I had was an old version of outlook webmail that I had to use for one client rarely, where ctrl-s was bound to 'send'. With no option to re-bind or disable it. So about half of the time when I'd get to writing an email it got sent in the middle of the sentence right before where a letter ś would be... And since I had to use it rarely, I never got used to it enough to switch keybord layouts.
Really shows how useful macs having 4 modifier keys (versus PC’s 3) is. Also the better (though not perfect) matching of scopes and modkeys: on macs, command / control / option tend to affect different system areas entirely (with command taking precedence, then control, although control and option are rarely used together).
I personally find the Mac's use of command keys to be horrendous.
Taking a screenshot? Thats the claw handed Cmd+Shift+4 or maybe even Cmd+Ctrl+Shift+4. Why!? Triggering the emoji picker? Cmd+Ctrl+Space. Don't accidentally press Cmd+Option+Space or you get the world's most useless Finder window.
To make this worse, Apple sell a bunch of keyboards without the symbols printed on them. So often you have software telling you to press the ⌥, ^ and ⇧ keys when your keyboard doesn't even have labels for those symbols.
In contrast, Windows has the Windows key for interfacing with the OS and the Ctrl key for interfacing with apps. So much more logical.
I do like Cmd+c vs Ctrl+c on a mac. On linux I've changed my terminal to use Ctrl+Shift+c instead of Ctrl+c for ^C because I kept accidentally killing programs when trying to copy text with Ctrl+c which works in every app except terminals...
It goes way beyond that though: if command’s in a shortcut it pretty much guarantees that’s an application / system shortcut, which frees Ctrl to only deal with text control (and literal control codes in the shell).
And thus Option essentially only does alternate characters.
It’s not perfect, mind, for instance the number of keychords means emacs is annoying whether you leave meta on option or move it to command.
I configured my terminal to copy on mouse release. This allowed to keep Ctrl-C for killing processes while I use Ctrl-V to paste with Ctrl—Shift-V configured to send the original Ctrl-V.
I recently discover that if you remap Ctrl+C to Copy in a Linux terminal, you still get ^C when nothing is selected. It has made the experience so much better.
TL;DR. Don't use keypress, it's deprecated. Don't use 'keyCode', 'which', 'char' which are all deprecated. Do use 'key'
Another issue I run into is forms that dismiss via keydown and escape. I type in Japanese which means I'm using an IME. An IME, or at least the Japanese IME, you type characters and they appear with possible completions. They haven't actually been given to the app yet. Pressing Escape cancels the completions. But webpages that cancel some model form dialog via escape means that if I press ESC to cancel IME completion (which is common) I also cancel the dialog and lose all input had previously entered into the form.
I'd think this would been solved at the browser level, if the IME is active then don't pass keys to the app but for probably valid reasons that's not what happens.
TL;DR don't use escape to cancel a model form!
edit: apparently there's the 'isComposting' property on the KeyboardEvent to find out if the user is currently using the IME
Question then - what do you use functionally to replace "Escape" in your daily use? As a native English-speaking engineer, the escape button has a history of doing exactly what you're suggesting it not do going back to the beginning of computing.
First of all. Don’t put long forms (i.e. more then a couple of inputs; including checkboxes) in a single dialog modal. Second do listen for keypresses on the dialog it self (not window) so that hitting esc on e.g. the URL bar (or the developer console) has no effect on the dialog it self. And thirdly—as parent states—don’t use deprecated properties and listeners, i.e. use `keydown` and `event.key`.
If you follow these three rules feel free to use the esc to close the dialog. I just tested logging `event.key` with hiragana Mozc input device and every keydown while selecting the correct kanji registers as `Process` even cancelling the input with Esc just adds another Process keydown event. I admit it can be frustrating if you double tab Esc accidentally to close the input (second Esc will close the dialog), but that is where rule one comes in, and the accident will only cause the user a minor annoyance.
The standard behavior of Esc is to abort the current interaction - which is not the same as closing the dialog. For example, if you have a dialog with a drop-down list, and open that list, Esc should close it, not the whole dialog.
In this scenario, the "current interaction" is IME input. The bug is that the page intercepts Esc keypresses intended to be handled by it.
I haven't checked in a while, but I'm pretty sure the dialog has no idea that the IME is active or not. So the dialog can't handle that situation, and the browser isn't handling it either. The IME/browser should not send escape to the page when canceling an IME selection.
Not sure if I agree with this summary of my article. For most web apps with relatively few keyboard shortcuts, I would actually recommend to use keypress. keyCode/which/charCode work when used with keypress.
The article mentions an open-source example that does it this way and works fine on international layouts: Discourse
What works best is to use `keydown`[1] with `keyboardEvent.key`[2]. Chrome took a while to implement `keyboardEvent.key` and I’m guessing that delay hindered adoption, but for the past few years (since the 5 year old Chrome 51) it is objectively the best—and arguably the only robust—way to figure out which key the user typed.
As a kid, I remember being utterly confused, when most games with a console would have the key ` to open it. WTF is the key ` and where is it?
For a kid it wasn't that easy to understand that there are such things as different keyboard layouts. Turns out that ` is a single key press to the left of the '1', in English, while it is a bit obscure character to write in other languages. In mine, you have º and ª in that place... so no ` at sight.
But game devs assume that ` is just a keypress away in a confortable area of the keyboard, and it became the de facto way to open in-game consoles. Oh well.
Also programming languages used it as an alias for exec. Even if you have a ` key, on some layouts (such as the Irish keyboard layout) it can be a weird key to type due to dead key behaviour, often requiring multiple presses to respond and eating the next keypress.
yeah.. i never use js template strings because of that frigging unusable backtick character.
Ist so hard to type on my layout, that its just not worth it -_-
Last time I needed a new laptop (my old one died) I took a 8 hour train to travel to the Netherlands from Munich instead of back home to Berlin (where I live) just so I could visit a store that has laptops with a non German layout (US international). The only way to get a non German keyboard in Germany is to order them online and wait for a week+ (typically) for that to ship internationally (because they don't stock these locally). That was clearly unacceptable. So, 8 hour train ride it was because I needed a replacement in a hurry and I got to visit my parents. Win win.
The alternative would have been buying a laptop with literally every key I care about in the wrong place in some local store. It's great that alternate keyboard layouts are available to those that actually need/want them but it really sucks that you get locked into these choices just because of where you are. Local shop owners don't seem to have any commercial sense whatsoever. Here's a genius idea in a city full of expats (Berlin, Munich), you know, maybe stock a few laptops with international keyboards. Even the local Apple store doesn't do that. And any time you go there, a very meaningful percentage of the customers is clearly not German.
Every non German buying a German keyboard because they have to is basically an unhappy customer. I know loads of foreigners here moaning about German keyboards. I've never met a non German that actually prefers having keys in the wrong place. That's not a thing; it's bloody annoying. It's equally annoying in other countries where expats live. E.g. French keyboard layouts are worse, AZERTY instead of QWERTY. At least in Germany you get QWERTZ (Y and Z are swapped). I've actually met quite a few German programmers that remap their keyboards so they can program without having to use four fingers to produce a single key-press.
I moved to Iceland a year ago, and brought my PC and my laptop with me. I am confounded by icelandic (nordic in general) keyboards. I can understand their use for a non-technical person, but even keys such as @ are obscured behind "Alt Gr" which is a secondary right side only alt-key? And the position of braces, brackets, and parantheses is also clearly an afterthought. Obviously, years of muscle memory are hard to replace, so I've continued to use my US keyboards.
But there's a problem. I want to spell people and places' names correctly, and on my PC that means I have to swap input locales often in order to type proper icelandic characters like ð, ö, þ, æ, í etc. This is annoyingly hard on a keyboard that doesn't support them natively! I will give apple some credit here - it's incredibly easy and intuitive to type foreign characters on a US keyboard just by holding down 'i' for example, if you only occasionally need to use them. Windows requires you to either learn the old-school way of holding alt, and typing the ascii code on the number pad, or hot-swap input languages. I know German uses far fewer unique characters, but how do you cope with that problem when you need German characters like.. sharp S, oumlaut, etc?
I am a non German, but I spent more time using German layout than the US one.
The killer feature of German keyboard: it is so natural for vim (and IDEs with vim emulation)
- the registers "+, "*, "~ are on the same key
- `,` and `;` for backward and forward searching are on the same key
- the macro operations `q` and `@` are also on the same key
- `^` for the line beginning is the key left to `1`, which also makes sense for `Ctrl+^` to switch recent buffers.
I would guess that the amount of people who care about which keyboard layout
they use, don't use the local keyboard layout, and require appropriate labeling
of keys (i.e. don't touch type) at the same time isn't that high. I can imagine
how annoying it must be to be in that group, though.
There are few million people in Berlin. A couple of hundred of thousand of them are Turkish or Russian minorities. And another few hundred thousand expats are working in the tech industry from all over the world. Most coffee shops in my area don't even have German speaking staff; much to the annoyance of some of the locals.
Some, of those people buy locally and suffer the bad experience of dealing with a sub optimal keyboard. But a lot of them take their money abroad. Local businesses are missing out on that, which IMHO is kind of stupid.
I think this is an interesting cultural difference.
There is such a thing as a Dutch keyboard layout and keyboard, but almost no one in the Netherlands uses them, as well as configuring one's system to be in Dutch, because it leads to such problems as described.
My entire system is configured in U.S. English, though most of the spelling I use is closer to U.K. English, but I find that it leads to the least problems in practice.
If it were configured to be Dutch, then troubleshooting would be a mess. — this is a common mentality in the Netherlands to never have any electronics or website configured to be Dutch, even when the option allow itself.
Special characters are usually input using the U.S. International layout which which allows one to type, say, “schöne scheiße”. quite easily.
We all suffer from character blindness of some sort. For you: ` - that thing isn't formally defined in English either as far as I know.
In English we don't have any diacritics. We do have a few extra symbols, beyond the alphabet for certain situations. Quotations ... " ... meh should be 66 99 and that will be fixed up by DTP software. We use ' to denote a dropped letter - abbreviation. There are a few others. I won't dwell on "thorne" and ligatures and other oddities.
I do not know of any reason to write ` - it is not an apostrophe, which is: '. What is it?
ASCII has a limited number of characters, so they designed it so some do double-duty. The grave could be a grace accent if you backspaced over a letter, or it could be an opening quote mark. The apostrophe was the reverse: it could be the acute accent. The fonts were drawn so these characters were angled enough to be accents, but also looked like quote marks. The apostrophe wasn't a vertical prime sign. Angle brackets and greater/lesser-than also double-up.
It’s an ASCII approximation of the proper typography for single quotes (except when you’d use inverted quotes for some reason, not sure how common it is in English).
Similarly, LaTeX uses `` and ‘’ for double quotes because the opening and closing symbols are not the same in properly typeset texts.
Not sure if you meant this literally, but I've seen it refered to as a back tick. As to what it's for, I have no idea either. I can't recall ever seeing it outside of programming.
My mum had a mechanical typewriter and yes it would do that. However English has no formal diacritics. We do have shit loads of borrow words from French and others that do have them.
If the back tick on the en_GB keyboard is a sop for the grave accent, then why do we not have an acute accent available as well? or a cedilla for that matter?
A lot of programming resources I've seen have an explicit explanation that the backtick is a different character than the single quote. Better yet, some fonts make the two almost identical.
It's not just international keyboards that are affected by this. I'm a Dvorak user so I run into these issues from time to time.
As the article explains, there is a difference between the physical keyCode and character it corresponds to. Which to use really depends on what it is being used for, and there are situations for both. The article suggests checking the character typed, but this is not always the correct way to do it.
For instance, the most annoying are games which default to WASD based on the letter typed and not the physical keys (I've seen this both in web app and native games). Using WASD based on letters simply does not make sense because the whole purpose is to mimic arrow keys. If you base it off of letters typed, then on Dvorak it's like if you used ,A;H on Qwerty which makes absolutely no sense for directional navigation.
For shortcuts where the letter has a meaning, then you might want to look at the actual character. But beware that even alphanumeric keys are not always in the same place because of layouts such as Dvorak and Colemak.
No, `keyCode` can also change with layout. Since you mentioned WASD, ‘W’ on a US layout has `keyCode` 87. Select a French layout, and the same physical key now has `keyCode` 90.
If you're using `keyCode` for anything, you're doing it wrong. There's a reason it's marked ‘legacy’.
Physical key position is the UI Event ‘code’, which is in this example will be "KeyW" regardless of layout. This field is essentially 1:1 with hardware HID codes (as used by USB and Bluetooth keyboards).
I've used dvorak and now workman and I don't mind the shortcuts moving around.
The biggest annoyance for me is if you want to sometimes use hardware-level dvorak or another layout (which expects software-level qwerty) and sometimes use it in software. Like, if your keyboard runs QMK but you use it with a laptop and might want to use the laptop's built-in keyboard if you take it on the go.
GTK also has some weird issues if you have multiple layouts enabled where the shortcuts are in the wrong place and don't all work (happens in Dino and Gedit). So, I now have only qwerty enabled in Sway and I'll just edit the config if I ever need to change virtual layouts instead of doing it with a couple keypresses.
Does windows a way to simultaneously use different layouts for different connected devices? It's really annoying shifting between my Japanese USB keyboard and English laptop. In Ubuntu I had startup script to detect input devices IDs by name and force different layouts, but even that was a bit of a hack.
Judging by the comments here, looks like we’re globally a rare breed that want absolute priority for keytop labeling over software configuration items.
Another Dvorak typist here! Personal funny anecdote: I learned vim modal navigation after I learned Dvorak, and never bothered to remap the keys. Totally debilitating if I'm using a coworkers QWERTY keyboard for vim navigation, but at least I can still navigate on remote servers without reconfiguring anything!
Physical layout is mostly irrelevant, different keycap label arrangements use the same keycodes - the input system in your OS or application uses a keyboard layout to translate those into what you want to type.
Windows, macOS and the various input libraries on Linux provide ways to query the key map - and a number of games do use this to provide localized bindings (Ubisoft and Blizzard are notorious for doing this right, something I appreciate as a dvorak user who hates dealing with rebinding or constantly having to toggle layouts). As far as the browser there is coming support for reading the keyboard layout as well: https://developer.mozilla.org/en-US/docs/Web/API/Keyboard/ge...
Normally, keyboards report data to the computer which represents the location of a key on a standard keyboard. The OS translates to characters based on configured layout. The actual letters printed on the key caps are just decorative.
If you type WASD on a US layout USB keyboard, the computer will receive key codes 26, 4, 22, 7.
If you type ZQSD on a French keyboard you get exactly the same result.
So if you are writing a game, you might listen for codes 26, 4, 22, 7 and these will be in the sample place on the keyboard regardless of layout. You can ask the OS to translate these codes to letters for help text.
(Some of the details here are omitted—the codes above are USB HID codes, but those go through an additional OS-specific translation table before they are sent to your program.)
In X11 with the Xkb extension you can configure simplified vector drawings of your input devices, which any application can query. It is intended that applications use these drawings in their help systems and tutorials, as well as in their key binding editors. Few applications bother though.
A few games map based on the key codes. For example, SC2 will get grid layout right on Dvorak or Colemak without any remapping. It did take me directly emailing a designer, who passed it on to the developers, though. ;)
Yes, the UI Events ‘code’ field represents the physical key (essentially 1:1 with USB hardware codes). The key that's labelled ‘W’ on a US keyboard and ‘Z’ on a French keyboard and ‘Ц’ on a Russian keyboard and ‘て’ on a Japanese keyboard (and so on) will have code=="KeyW" in all cases.
Is there a programmatic way to figure out what letter corresponds to a given keycode without that key being pressed? Because you may have to display that info somewhere to give an indication what the user has to press.
Yes. You have to dig a bit to find these APIs, and they are OS-specific (and the scan codes reported by the OS are OS-specific too, even though most keyboards are USB HID these days).
Also, not that “alt-s” will produce an s character on a US keyboard on windows, but will not produce an s on MacOS with a US layout - alt-anything will produce all sorts of interesting characters on MacOS.
My memory is that if you press option E on a Mac, the translation function reports a non-zero state but no character output. You can detect this and call the translation function again with a space to get the diacritic by itself.
OS X's solution works perfectly: Dvorak + QWERTY shortcuts layout. It's brilliant and elegant, Windows needs to implement the same thing (revert to QWERTY when holding the ctrl or windows keys).
Can you find the [ and ] keys? If you’re having trouble, it’s because you have to use 2 (two!) modifier keys and activate the ( or ) keys, which themselves are clumsily placed. This cannot be typed one-handed in a comfortable way. Apple’s azerty layout is unique in this, as regular azerty puts those keys in a more sensible place. I keep wondering: why does apple make me do a Vulcan nerve pinch every time I want to index an array?
It's the other way around. The keyboard was the foundation for the programming languages and shortcuts, like moving with hjkl in vim. No German keyboard user would have created a language like C with curly braces, when you would break your fingers typing this (alt 8 is {, alt 9 is }, and alt+5 is [, alt+6 is ] ).
I reassign my Caps lock key as a third level modifier. That way I can type { with Caps Lock + 7. Caps lock is so large I can comfortably use my pinky and ring finger to press and hold it, while I use my right hand to press 7, 8, 9 or 0 for {, [, ], } respectively.
I think the answer is that their engineers overwhelmingly use the English layout keyboards and work in Cupertino. Most improvements to coding on a Mac I have seen have a design-for-self element where apple employees are eating their own dog food and want to improve the taste.
C was famously designed in Murray Hill on a system with Teletype 37s, which featured then-fairly-novel { and } keys (as it so happens, the shifted versions of [ and ]).
‘Happens’ is understating it. ‘[’ is ASCII 0x5B and ‘{’ is ASCII 0x7B, and the Teletype 37 was entirely electromechanical. For those unfamiliar, see https://en.wikipedia.org/wiki/Bit-paired_keyboard
Most keyboard-layouts predate programming-languages, because they were designed for typewrites decades before the first modern computers even existed. So there did gave much to usage of special chara back then. Additionally most languages were designed by americans, on US-layout, which had a great impact on usages of different char in our digital world. Like for example the usage of @, which AFAIK was only used for e-mail because there was no other free char on the developers keyboard available.
In American usage, it has had widespread use as shorthand for “at” in many different contexts, not just in terms of price per unit fir quite a while; some of them.may have been catalyzed by thr usage in email, but I think enough are older that email fits into an existing pattern rather than creating a new one.
Yes, in english language. Other languages have/had different names, if they even knew it at this point. There was of course a reason why the @ was on the english keyboard-layout, but it was a very different reason from the later usage as location/user-reference. Point is, if e-mail would have been invented in a different culture, there would be a good chance that the symbol wasn't even on their keyboard at the time and a different symbol would likely have been used.
Honestly that's one of the reasons I'm happy with the Logitech Craft: it lets me use a proper Azerty layout yet silent like the Apple keyboards (plus I can control both my computers from a single keyboard, but that's more an edge case).
> What baffles me is that the problem exists in apps used by millions of people every day, developed by gigantic corporations who pride themselves with having the best engineers in the world. Why is this baffling? Because the underlying technical issues are rather trivial!
> Hint for developers: Switch your computer’s keyboard layout to something other than US to debug your application’s shortcut handling on different layouts.
The problem with this and all the other X is broken and should be tested articles is that the testing burden is already enormous. Plenty of companies don’t even test with Firefox and/or Safari.
That’s really the problem that needs to be solved. How to reduce the testing burden.
For a 10-person startup, that's fair. For a company like Google , with offices in Germany and France and hundreds of engineers from any nationality, not so much. Other companies fall somewhere in between based on their headcount and global reach.
Plus it's all about profit margins. Investing in tons of testing for not enough return from users means they just won't do that.
I'd imagine you'd need multi-lingual testers to use the product too, not just a native speaker given a foreign keyboard. There's no way to find bugs an average user would face with normal use.
I don't think testing with a non-US region settings and a non-English language is a huge burden. As a regular user of “internationalised” software, it's really obvious when the people who wrote it do not speak more than one language, or only considered a single-country perspective.
Monolinguals, especially those living in the United States, are a minority globally. If you're going to develop all software in the United States, please at least make it work for the rest of us.
If there was a standard way to define hotkey bindings, a simple linter could take care of that. It just shows how far we still have to go in terms of good UI creation tooling.
This is the real solution. Providing a native API with i18n built in would quickly start resolving this issue.
It reminds me of developers who want to capture link clicks for internal navigation but acccidently block right or middle click as well because it is the easy thing to do.
If we provide APIs that make the right thing the easiest we will have more websites that do the right thing.
This is part of why I’d like to see more VSCode-as-an-OS (disclaimer work on VSCode)... imagine writing only the code to go from bytes on disk => view and back, and getting for free: version control, command palette, keybindings, Windows/Mac/Linux/Web support, file explorer, tabs, split views, hot exit, etc etc etc.
I agree to some extent. However, I have outlined a few very simple approaches. At the very least, developers could stop using special characters for their most important shortcut bindings.
On French keyboard, the numbers 0-9 and special chars (#$&@...) are swapped, so you need "shift+<num>" to type in a number. Effect on the web compat:
A phone number validator on French lowcost railway website was built/tested with French keyboard only; they were checking input codes in JS on each keypress and only allowing the presses of certain keys with shift enabled. Since you can't type a number on QWERTY with shift enabled, I was unable to complete the form until I realized what's up by reading the JS and switched to AZERTY layout.
(copy-pasting into the input didn't work either)
---
Unrelated aside: as I was raised in Poland which is based on US QWERTY and all programs using US shortcuts (with the only quirk being AltGr mentioned in other comments), I was mind blown than in other countries it's customary to localize shortcuts.
For example in Spain in notepad.exe, save is not CTRL-S but CTRL-G ("guardar").
In France, you don't bold in Excel with CTRL-B, you bold with CTRL-G ("grossir"). For some reason Excel online only lets me use the FR version despite settungs all possible locale settings to en and this drives me nuts.
> For example, on my German layout, / is produced via Shift+7.
This is my #1 annoyance with German keyboards as someone who learned a UK layout and who needs to do lots of programming and terminal hacking (#2 is the swapping of Y and Z). I take it this layout was invented before Unix and its heavy use of forward slashes, but it does show how shortcuts are rather discriminatory. I know more than a few Germans who use UK or US keyboards because they dislike this unhappy feature.
I used to switch between US and DK layouts, it's just so much easier to just have one layout. In my opinion, learning US Intl is worth it. Besides, it's pretty predictable for Spanish characters: á = altgr+a, é = altgr+e and so on.
Yeah it's great for Spanish. But I found that knowing (and using) native layout is more valuable to me because when I need to type on someone else's keyboard I'm not lost and can still touch type. If you never need to do this US international is indeed superior layout.
Trying to remember more than two layouts becomes confusing very fast. AZERTY and QWERZ are the two worst ones, fortunately I never need to use those.
These keys are present on the UK keyboard, but not the US: £¬
Compared to every other common ISO keyboard layout, ISO UK and ANSI are very similar. For non-programmers, ", @ and (nowadays) # are the ones that matter. For a programmer used to an ISO keyboard, the UK layout may well be a better choice than the US ANSI one. (US ISO would be a good choice, but the extra key seems to duplicate symbols already present on the layout).
In intellij this was a bit frustrating to me, you can do ctrl-shift-`/` to block-comment (in german keyboard: ctrl+shift+shift+7). How do I double-shift?
I know you can configure that in IJ but I'm too lazy to do that, especially if there are many keys to remap.
Same problem with latin american keyboards found just a few kilometers south the US. If I remember correctly, the default modifier key in VIM is next to imposible to press on a l-a keyboard. It was ` ?
I’ve gotten so used to switching between keyboard layouts when moving from e-mail to coding that I don’t think about this much, but it can be tremendously irritating when I’m on a new machine or just forget to switch.
(pt-PT keyboard, parenthesis and brackets are either an off-by-one or require Alt-Gr+Shift to type.)
Using a US keyboard layout for a while really drives home how much it influenced popular CLI character choices (like path separators, pipe characters, etc.), too.
I mostly write in English (plus Clojure, shell, and C#), but often also in Spanish, French and Finnish. I've found that a standard QWERTY/US layout with a Compose key is the best option. It gives you a decent layout for coding and shell related characters, and all diacritics (and plenty more) are a 3 keystroke chain away (with no chording). Even when writing French, which requires a lot of accents, I find it more fluid than needing to switch to (the completely awful) AZERTY layout.
I like the default Mac US/International English/British layouts (they're almost the same as each other). Mac users are graced by an OS that actually uses the Option (Alt) key on every letter to do something useful. You can type all manner of diacritics and such without using a non-standard layout! It works great for English, German, Swedish, Spanish, French, and perhaps more.
I only wish there was good support for it on Linux and Windows. I will eventually contribute a patch to xkb to fix its version of this.
I'm no longer using Macs for work, but while the option key does enable useful stuff, you can do even better with Karabiner elements and a Compose key there as well :)
Which azerty? French or Belgian? I find the Belgian one is actually very well suited to programming, with easy access to all common symbols. I can't speak to the French one, but from a quick search it does look insupportable.
Dead keys are particularly fun, as it takes two key presses to produce a result. Accessibility of keyboards/layout could indeed be improved. I switched to custom US layout, because of too many issues with a non-US layout. My custom layout uses AltGr combinations to add a few local characters. It is a bit clumsy, but at least keyboard shortcuts work most of the time.
Polish has a "traditional" (typewriter) and "programmer's" (US + AltGr) variants of the keyboard layout. Everyone uses the "programmer's" one, even people who don't know what programming is.
Honestly don't wait on all the web Dev to fix their app. Buy yourself a programmable keyboard that tells the computer they are a "normal US layout keyboard".
Now when you press "shift+7" on your keyboard it only sends "regular US keycode for /"
As a benefit you'll maybe also realize that Azerty or Qwertz are pretty bad layout for typing French/German, and you'll come up with something better.
If you do that you'll break anything that maps based on scancodes in order to have a consisten physical locations while the key label does not matter, like games with WASD for movement and nearby keys for shortcuts.
> For example if you have / as you shortcut for focusing the search field because your US users are accustomed to this behavior, just add alt+s as an alternative for international users.
And Alt+S already opens the browser's History menu, on Firefox, and I'm not sure that applications can override this binding, or if users will appreciate it.
----
Last year, I was working on a Qt app that needed to translate physical scancodes (not layout-dependent character codes) located in a piano layout, into music notes. I developed a library (https://github.com/nyanpasu64/qkeycode/) and submitted several Qt/QtWebEngine bugfixes.
Anyway, fuck KeyboardEvent.keyCode. It differs across OSes and browsers.
Fun fact: On QWERTY, + requires holding Shift. Some apps (Qt Creator, QtWebEngine) don't zoom in upon Ctrl-=, but only Ctrl-Shift-+. IIRC Firefox in English locales binds both Ctrl-+ and Ctrl-= to "zoom in"
I'm french canadian and the most satisfying solution I've found is to keep switching from one keyboard layout to another. I mostly use the american layout when I code, and the french canadian one to communicate. I got used to it in about a week.
Not sure it's comforting but after exposure to french and swiss keyboard layouts, the canadian one is for me a sweet spot. It's "almost standard qwerty" while allowing to write in french properly. "US International with dead keys" is workable but somehow weirder and less consistent between OSX and Linux.
I now exclusively use US-International No Dead Keys. I just use the right alt key + qpys to get äöüß. I hate having to switch layouts and switching layouts accidentally while typing. Those key combinations are not worse than []{}\ on the german layout.
I use a US keyboard with Caps Lock mapped to Compose (using WinCompose [0]), which lets me type any Unicode character I need. Totally agree that switching layouts is a pain.
The root of the problem is what this article correctly describes as the deprecated properties `keyCode` et al. These are essential raw Windows events that browsers in the '90s unwisely decided to expose. For any platform that is not Windows, these have to be emulated, which is not at all simple, since the details vary according to particular Windows keyboard layouts.
Nope. They're Windows ‘virtual key codes’, which are entirely unrelated to Windows ‘scan codes’, which are also not hardware codes (but are distantly descended from the original IBM PC).
For instance, consider ‘/’ (beside right shift). The normal hardware code (USB HID) is page 7 usage 0x38 (sometimes written 0x070038; in theory HID usage codes can exceed 16 bits, but in practice they don't). The PS/2 hardware code (for old keyboards) is 0x4A. The Windows ‘scan code’ is 0x35. And finally, the browser legacy ‘keyCode’ which you can see at https://w3c.github.io/uievents/tools/key-event-viewer.html is 191 (0xBF), which is the Windows virtual key ‘VK_OEM_2’.
It really surprised and disappointed me recently that native macOS apps have the same problem outlined here. For example, the standard system-wide ‘back’ shortcut (e.g. in Safari, Finder, Preview) is Cmd+[, but this is inoperable in many keyboard layouts that don’t have any key that produces [ without modifiers.
(For context: I was writing a simple mouse gestures utility that sends that keyboard shortcut to accomplish backward navigation for an appropriate gesture, but discovered this to be unreliable across keyboard layouts).
It‘s even worse on ISO keyboards (the ones with the large return key).
There‘s a physically different key arrangement on these, so even when switching to the US lay-out, some important system-wide shortcuts are still impossible to type (most notably the one for „switch to different window“).
Yeah Apple doesn't seem to even try to cater to non-US users with their shortcuts. That's the first I've heard of a system-wide back shortcut. You can't type that in my layout. The default switch between windows of a single app shortcut is also impossible, IIRC. One that I always have to reconfigure when I switch editors is the line comment shortcut which defaults usually to something like cmd-/.
I wonder if it's any better on iOS or are you just completely out of luck there when you can't reconfigure the shortcuts?
One favourite of mine in this genre is applications who use both command-[ and option-command-[. On a Swedish mac keyboard, [ is on option-8, so it is impossible to type just command-[ without the option key...
One of many reasons i switched from a Euro ISO layout to a QWERTY ANSI layout a while ago. It took me about 3 weeks to get comfortable with QWERTY ANSI, plus another 2 months to fully get back to my regular typing speed. 100% worth it tho if you need a bunch of special characters as you regularly do with most programming languages.
Some tips:
- switch out ALL you keyboards, at home, at work, on all devices
- use EurKey* for reaching special keys in your language (french, german, whatever...)
What kind of bothers me is that while many accented letters are available just by pressing AltGr/ShiftAltGr/etc, common Slavic ones (č, š, ž...) aren't. You have to use dead keys to type them, which defeats the purpose. You can already type them in a similar way on macOS by just holding down the original letter on a Mac Canadian/Australian/EngIntl layout, but that's a pain for pretty much anyone who types a lot. These letters are used often enough to have their own keys on many localized keyboard layouts.
I also switched to ANSI (with a custom software layout) after using ISO for most of my life. I prefer the wider/horizontal Enter key on ANSI. I'd sometimes accidentally hit the key above it (\), but over time it got better and now it's not a problem anymore.
So what to do about mnemonics? What about keyboard placement?
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
Really? The / is conveniently accessible on a US layout; shift+7 isn't. So this gains you the benefit that you don't have to change documentation (it is "/" however you type it), but much less usable on other layouts.
Alternatively, you could try to use the key in the same physical position, but - is already used for other shortcuts due to its meaning.
For Western European devs: do try the "USA International (AltGr dead keys)" layout.
It's great for programming and quite good for all the Western European languages (maybe not so much for Eastern European languages that are more creative with diacritics).
I wish I'd known about it before spending a lot of time creating my own custom layout for Linux and Windows, although since I went through the trouble that's what I still use.
I don't know which language you're using but for french I migrated from "US International with dead keys" to "canadian english". I fill that, among other things, simple quotes are easier to type and consistency between OSX and Linux is better. A matter of habits and workload balance I guess.
You are talking about a different layout, which I also dislike.
I'm talking about "AltGr dead keys", in which the quotes are available directly and the accents are entered using e.g. AltGr-'.
I'm using 6 european languages occasionally, of which 3 every day, including French. Of these, Canadian English would be only useful for French (e.g. it does not have a tilde dead key AFAIK) and is still different enough from US to be annoying for programming (e.g. the angle brackets are in the "wrong place"). Certainly a big upgrade from AZERTY though!
EDIT: My remark on the Canadian English layout above is based on the first layout that showed up when I googled it, but now I noticed that a lot of different variants come up in the search and I don't know which one you're using. In any event, they all seem to be weaker either for programming or for non-FR/EN languages or both.
I can't find any "AltGr dead keys" variant on the OSX I'm using at the moment, I'll check later on Linux. I don't have any keyboard with a key marked "AltGr" either btw :).
However, the canadian english variant I'm using definitely has a ~ key and accepts alt+n for ñ. Concerning angle brackets they are at the same position as on a standard US layout.
I assume that we are using different operating systems and that they use the same name for different layouts.
> I don't have any keyboard with a key marked "AltGr" either btw :).
That's the right alt (not to be confused with the alt right).
> the canadian english variant I'm using definitely has a ~ key
Can you type "ã" or "õ"?
I'm not saying it's the optimal solution, in fact my custom layout works slightly better for myself. However, learning how to build that custom layout in both Linux and Windows took me time that would have been better spent elsewhere.
All I'm saying is that people in the same situation I was in (programmer writing daily in multiple Western European languages), this obscure-niche-that-nobody-seems-to-know-about layout will serve you fine 100% of the times, whatever the language, without you spending ungodly hours coming up with your own.
> That's the right alt (not to be confused with the alt right).
I laughed, thanks for that.
> Can you type "ã" or "õ"?
on OSX' Canadian English yes, AltGr+n followed by a/o.
On the other hand, after paying closer attention to the behavior of the layout with the same name on Linux, there are annoying discrepancies and "English (intl. with AltGr dead keys)" is indeed pretty nice for me too. Thanks for the pointer, I may adopt it too.
It totally f—ks up handling of quotes though. I just cannot stand it, personally.
These days, on Windows, I use the Colemak layout, which has a alt-` meta-combo to type common accented letters - I assign that to caps-lock+A with AutoHotKey, and “Bob est ton oncle”.
Hah, yes, I’ve had lots of problems with keyboard layouts. I have a hobby requiring lots of unusual characters (e.g. ɛɔþʔəɬɑʒ), and I haven’t yet found a keyboard layout which allowed me to type all these characters with absolutely no problems. I started off using the Canadian Multilingual Standard [0], which worked well enough, but uses Ctrl rather than AltGr as a modifier, with all the conflicts that entails. Also, some frequent characters such as []/ were hard to get to, and I never did manage to retrain my muscle memory to get used to their positioning. I eventually switched to the Finnish Multilingual layout [1], which fixed the Ctrl problem but not my muscle memory. I think I used Keyman [2] for a while, but I don’t remember it working very well. At the moment, I’m using my own custom keyboard layout [3], which generally seems to work very well… except in Microsoft applications, which seem to inconsistently not recognise dead keys with AltGr. (Excel is a particular offender, which is particularly horrible since I often need to type characters like λση⁻¹ in it.) Not that they’re alone: out of the major GUI libraries I tested recently, only Qt and Electron worked correctly. Clearly, this is an area in need of improvement.
Another problem on international keyboards besides unexpected key-codes for symbols is that it is awkward to type them with extra AktGr or Shift. Even with Vi-based editors this an awkward problem.
So indeed avoid symbols. If the application needs more shortcuts, then use prefix keys for less frequently used shortcuts or allow the user to type commands.
> This means when the key combination is alt+/, the shortcut should be triggered when a german layout user presses alt+shift+7.
No way. I want to press alt+dash, which is in the same place as alt+/ on a US keyboard. Pressing alt+shift+7 is the equivalent of Lee-Harvey-Oswald-grade marksmanship on a keyboard.
The problem is, most people will not know that alt+dash is an alternative for alt+/ with their layout. Also, it does not actually work with all browsers and operating systems. Try to use dash as a replacement for / in Firefox and you will be disappointed.
However, developers defining and documenting alt+/ as an alternative for alt+/ when registering the binding would indeed be a fine solution.
MacOS is notoriously bad for handling international shortcuts. Eg, `Cmd+[` is back system-wide. To get [ on my keyboard I need to press `AltGr + F`. `Cmd + AltGr + F` doesn't work, of course.
Where the `[` character is on a US keyboard, I have `Š`. `Cmd + Š` also doesn't work. Manually recording a shortcut to rebind it to `Cmd + Š` also used to output `Cmd + Ctrl + Alt + F`, which seems to be fixed at some point in the last 3 years.
I raise you to MacOS + browser + Citrix + Linux + Other browser with Linux being a farm with different keyboard configurations so you never know what you face when you try to log in (requiring the '@' sign).
Also while we're at it...fix this for bitlocker. Makes special characters in passwords a nightmare and you need to memorize where that stupid character is...
Edit: 0: or at least a pass-multiple-words, depending on how picky your definition of "phrase" is about grammer. It shouldn't be "word", singular, is the point.
KeyCombiner looks very interesting.
I once worked on a keyboard visualizer for vscode (https://hediet.github.io/visual-keyboard), but I was never really happy with it.
It would be nice if keyboard shortcuts were a matter of the OS and applications would expose a list of all available commands with default shortcuts...
Absolutely, that would be a fine solution. It is also mentioned in the article. I really don't know why web application developers are not doing it. Especially when you could be the first to do it and have a real edge over your competitors.
I am using a French azerty keyboard, but since '[]' and '{}' are in wierd locations,i always remap them to US-alike. This breaks the diacritics, but oh well
I also like my ';' and '.' swapped, because dot is clearly more useful when typing in terminal
> Some US users might welcome this change as well, because alt+s can be typed with just the left hand while / reqiures people to take their hand of the mouse
Only an issue when your mouse on the right side of the keyboard
This is one thing that bothers me in Emacs. The shortcuts are not consistent between modes. It's a lot of mental overhead if you go with a config close to the defaults.
Same here. I use US International, which allows me to type the languages I speak. I even buy all my computers with US Keyboard layouts because I like when my keys match the OS configuration.
Windows for backwards compatibility reports 'right-alt' as 'alt+control'.
Many applications developers assign key combos with no negative checks. So 'ctrl-s', typically used for save gets triggered when user wants to type 'ś'. To repeat, "right-alt"+"s" is reported as "alt"+"control"+"s", which triggers crappy "control"+"s" checks.
Similar scenarios happen many places that check for 'alt'+'letter' without checking if control also is not pressed.
Microsoft thread for team user voice issues on this https://microsoftteams.uservoice.com/forums/555103-public/su...
or Medium's developer talking about 'ś' and 'ctrl'+'s'. https://medium.engineering/the-curious-case-of-disappearing-...