How important is programmability to you?

[apastuszak]

I used to use AutoHotKey at work do all sorts of cool things with my keyboard. Then work took AHK away, and I thought I could get some of the same funtionality from using a hardware programmable keyboard. I tried a Model M with a Soarer's Converter and a few other keyboards with QMK/VIA and QMK/VIAL.

The fascination wore off pretty quickly. Even though I configured certain key combination to type things like 'Thank You!' and 'You're Welcome!', I found I wasn't using them at all. I preferred pattern substitution, which hardware programming can't do. So, I type something like :yw and software substitutes 'You're Welcome!'

I did configure some macros to launch apps by pressing Windows, releasing Windows, typing the name of the app, and pressing the Enter/Return key. But some of those macros became very finicky with timing, and I found it better to just press Windows, type a few letters of an application and press the Enter key.

The one thing I find very useful is entering the password to my password manager. Now I can make my password manager password very complicated and I can enter it with one keyboard combination on my keyboard. But that's about it.

I'm curious if anyone out there has something they use a programmable keyboard for that was a "game changer" for them?

[kbdfr]

[…] I'm curious if anyone out there has something they use a programmable keyboard for that was a "game changer" for them?

You bet!
Tipro keyboards are entirely programmable. You can reprogram any key (on 4 levels each) with characters (even not present on a keyboard) or complicated macros.

Spoiler:

And of course you do not need such a giant thing
.

Tipro configuration 2022-10-17.jpg (123.84 KiB) Viewed 5598 times

The one thing I find very useful is entering the password to my password manager.

That's precisely the one thing I would never do - there never has been a password programed in my keyboard, which years ago certainly proved to be a good idea when burglars stole one of my previous keyboards, a programmable Cherry G80-2100, together with my computer.

[depletedvespene]

On a "custom" keyboard is a must, for the obvious reason.

On a regular keyboard I used to find it to be "quite useful" instead of "unavoidably vital", as most key assignments were already there, and one just needed to make a few adjustments (move AltGr into its proper spot in "modern bottom row" keyboards, add volume controls in actually useful places, map Win-Shift-S to Shift-PrtSc, etc.). This has changed into the "vital" category lately, as I decided to test out moving the Esc key onto the Caps Lock position, and that has proved to be so useful for me, that now I need all my keyboards with this feature, making programmability an absolute must (whether on the keyboard itself or on an external converter).

For me, generally speaking, programmability applies mostly to modifier keys (see the examples above), while "macro sequences" (for phrases, passwords and whatnot) is something I very rarely need, and alpha keys should be left alone. Mapping out what alphanumerical characters should be produced is better left to the design of national layouts (of which I can talk about a lot, too, but it's truly a different subject).

[Muirium]

This is a deep and revealing question. Well, for some of us.

Programmability became absolutely vital to me right back when I got my first mechanical keyboard: a Model F XT.



A glorious beast, but just look at that layout. What can you do with it? How do I get from that to my many-more-modifier keyed Mac? By reprogramming it in Soarer's Converter of course. A few days later I had it running like this:



Soarer magic: an inherently awkward layout is transformed into something much more useable to me. Programmability lets you fix annoyances and mistakes in the keyboard's design. I moved things around, wholesale!

For me, generally speaking, programmability applies mostly to modifier keys

This is very true. Rearranging and even hijacking modifier keys—as I did on the XT—is the very first thing I do when adapting vintage boards to modern use. The XT is quite extreme, but very often I need to create an extra modifier when using Winkeyless keyboards, which I do with my general purpose Soarer rule.

Code: Select all

layer 0
	caps_lock	lctrl
	lctrl		lalt
	lalt		lgui
	ralt		rgui
	rctrl		ralt

Other tricks I play in Soarer include my Shift + Shift → Caps Lock macro and a soft Num Lock layer to bring numpad / nav functionality to the Mac, which has no such mode. Layers and macros are must have! Especially on compact keyboards like my Kishsaver, which I gave an HHKB navigation layer for its all important missing arrow keys. I originally learned those before I even had an HHKB, back on that remapped XT!

Now, once upon, I did all of my mods keyboard-side, right on my Soarer Converter or Xwhatsit controller. I still do some things there, including even my TMK powered HHKB here. But since 2020 I've split the work with the host, by getting pretty deeply into Karabiner, which can do things host-side that keyboards can't. That thread has many examples, including scripts which work on the clipboard, and keyboard shortcuts which dynamically act when certain apps are active. Host side programmability is indeed very powerful.

I've also tried to make my mods consistent, so I can always rely on them, whatever the keyboard. The way I do this is to make simple changes at the keyboard level—making sure all their keys are visible and their tricks are consistent—then more complex stuff host-side, relying on the keyboard's own modifications. Some things can only be done host-side, especially when the host computer is a laptop and you use its integrated keyboard often enough to notice when things don't work! Keyboard modifications only really work when you can always rely on them, then they truly become second nature.

So, in all, yes I reprogram my keyboards extensively. Love it! They're powerful stuff, and when you make them work for you, you fly like a wizard.

Now I wonder what exactly Kbdfr is doing with all those extra keys of his…

[vvp]

I have a custom keyboard so I do not use remapping much. I already defined the base layout the way I want it.
I use macros somewhat: e.g. MacroShift-G does vim-grep on the word under cursor, MacroShift-R repeats the rename of the next tree item in my CAD, etc. Not an absolute necessity but very useful.

[apastuszak]

Today I discovered I can program one of the slots in my Yubikey with a static password. So, I made a 6 word diceware password. I memorized the first word, and put all the others in my Yubikey. Now I just type the first word and hold the button down to type in the rest of the password.

With that set up, and Espanso installed, i really don't need much more.

Now if I had an M122 or an XT keyboard, or some other "non-standard" layout, I'd probably want to program something.

[engr]

I think some level of programmability is a must when dealing with boards smaller than TKL, because using layers and deciding which keys are more or less necessary is a personal preference. For a full-size board, it's less important (unless you just can't stand having Ctrl, Alt, and CapsLock in the usual places I suppose), but where programmability would really be useful is in battleships. The question is, why are so few modern keyboards fully user-reprogrammable? Why can I program macros on a Focus, Ortek, Northgate, etc. from 25 years ago with just a couple of key strokes, but to do anything with a modern board, I have to either install some bloatware or screw around with reflashing firmware and such?

Here, here, see this thing here? This is a Focus 20-key mechanical macro pad from 1990... something. Know how much software I need to program anything on it? None! Know how many things it prompts me to install when I plug it in? None! Know how much corporate crap it throws at me when I try to use it? None!

By the way, if you want a more modern macro pad that doesn't require bloatware, you may want to check out X-keys PS/2 macro pads. The programmability is similar to the Focus macro pad. Unfortunately, they come with Cherry MX Brown switches, but you can always solder in something better.

[Dingster]

Not at all, keyboards being different and having to get used to a new layout when swapping around is half the fun

[Hak Foo]

I ended up using a handful of canned macros. As a lark, I was considering trying to develop a macro which generated dynamic content (i. e. a random number fitting certain range constraints) but the use case suggests I'd be better off with a fixed constant.

[AndyJ]

I used to use AutoHotKey at work do all sorts of cool things with my keyboard. Then work took AHK away

I haven't run Windows in a very long time, but Windows Scripting Host used to be a way to feed keystrokes to applications. It was part of the basic Windows install, but you had to find and enable it to use it.

[apastuszak]

I think some level of programmability is a must when dealing with boards smaller than TKL, because using layers and deciding which keys are more or less necessary is a personal preference. For a full-size board, it's less important (unless you just can't stand having Ctrl, Alt, and CapsLock in the usual places I suppose), but where programmability would really be useful is in battleships. The question is, why are so few modern keyboards fully user-reprogrammable? Why can I program macros on a Focus, Ortek, Northgate, etc. from 25 years ago with just a couple of key strokes, but to do anything with a modern board, I have to either install some bloatware or screw around with reflashing firmware and such?

Here, here, see this thing here? This is a Focus 20-key mechanical macro pad from 1990... something. Know how much software I need to program anything on it? None! Know how many things it prompts me to install when I plug it in? None! Know how much corporate crap it throws at me when I try to use it? None!

By the way, if you want a more modern macro pad that doesn't require bloatware, you may want to check out X-keys PS/2 macro pads. The programmability is similar to the Focus macro pad. Unfortunately, they come with Cherry MX Brown switches, but you can always solder in something better.

I think that any innovation in keyboard programmability ended with QMK. Vendors just throw QMK onto their keyboard and leave it up to the end-user to figure out how to use QMK to configure a keyboard. Some of them even use a custom fork of QMK and they never merge their changes back into mainline QMK.

[Reimu64]

As a 60% user, programmability is vital. I otherwise wouldn’t be using a 60% in the first place. One of my favourite key combinations is Fn + |\ which opens the calculator. I otherwise don’t use that key.

But I also haven’t found any “game changing” aspects about programmability. Usually, the smaller the board, the more important it is to have programmability.

[davkol]

It's worth pointing out that "programmability" means a couple of very different things.

programming

1. the process of writing and testing programs for computers
2. the planning of which television or radio programmes to broadcast

Sooo…

Tipro keyboards are entirely programmable.

Only in one interpretation of the word. That's not to say that some scancode combinatorics aren't useful. They are. But I doubt you can easily make Tipro keyboards run custom code.

You can reprogram any key (on 4 levels each) with characters (even not present on a keyboard) or complicated macros.

Nope, you can't program the Tipro with "characters" either. It's still limited to scancodes and it's up to the host system to interpret them however it likes, as users of various operating systems (local, remote or virtualized) and application toolkits in a multilingual environment may have experienced.

With all that out of the way, I'm fine with only basic remapping at firmware level, because KMonad is relatively close to QMK in terms of feature-parity, even though I'm not committed to anything like Hands Down or Miryoku. And I prefer do the rest (such as more complex dealing with characters and macros) in user space.

[vvp]

Tipro keyboards are entirely programmable.

Only in one interpretation of the word.

Some keyboards are truly programmable in all senses of the word. Here is a sample program running in a keyboard: https://github.com/chrisandreae/keyboar ... s/mouse.kc
There are not many use cases for it though. Most of the time people do not need precise timing between mouse movements, clicks and keyboard key presses.

[davkol]

There are plenty of use cases, although many of them are niche.

What scancodes are actually available? Let's say I stick with a Tipro; I have a couple but not the "programming" setup currently, so I can't check for myself. Does it support scancodes for, say, Japanese input or the entire range of "multimedia" keys?

What layer-switching mechanisms are supported?

How about dual-role (tap/hold) keys? Multi-tap input? More complex firmware-level chording, e.g., for steno? Options to choose *KRO implementation (also for compatibility)?

Mouse emulation is a quite advanced firmware feature as well, with lots of variables.

I don't even care about things like backlight, wireless, on-the-fly configuration, and I don't know what else.

It's not like I'm one of those "QMK or bust" people either. I'm okay with Kinesis SmartSet, fairly happy with EasyAVR, and still haven't dived into Kaleidoscope.

[kbdfr]

[…] Let's say I stick with a Tipro; I have a couple but not the "programming" setup currently, so I can't check for myself. Does it support scancodes for, say, Japanese input or the entire range of "multimedia" keys?

In any case I have been able to program (and widely use) the complete set of Latin transcriptions characters for Arabic, allowing me to type such nice things as al-Faraǧ, al-Farāʾiḍ or Āḏarbayǧān with a dedicated key for each character. Japanese? No idea, I would have to try.

As for multimedia keys, I simply programmed the keyboard with the shortcuts of my transcription software (the only media application I use when typing).

What layer-switching mechanisms are supported?

Each of these:
-Shift to layer 1
-Shift to layer 2
-Shift to layer 3
-Shift to layer 4
-Lock to layer 1
-Lock to layer 2
-Lock to layer 3
-Lock to layer 4
-Lock layer up
-Lock layer down

How about dual-role (tap/hold) keys? Multi-tap input? More complex firmware-level chording, e.g., for steno? Options to choose *KRO implementation (also for compatibility)?

No idea, to be honest, even if I rather doubt such stuff can be programmed on a Tipro. I never even remotely needed any of that anyway, as you don't need multi-tap input or chording or KRO when what you want is precisely one-key action for almost everything.

[DMA]

The problem with `:yw` is that if `:yx` is not mapped, what would you do? Retroactively type `:y`?

But even single-key macros are a huge can of pretty nasty worms.
Take that QMK's moronic "one-key modifiers" for example: they are utterly, batshit insane, and the reason is simple: a lot of what you think of as "keyboard" is on the host side. Just connect two USB keyboards to your computer and experiment!
* When you press Shift on keyboard 1 and f on keyboard 2 - you'll still get F.
* This gets even funnier - if you have 4 keyboards, you can press Ctrl on first, Shift on second, Alt on third and Esc on fourth - and still get Ctrl-Alt-Shift-Esc.
* On-screen keyboard is a real keyboard, too (except it shows modifier state from The System Keyboard in real time - something that physical keyboard has literally NO way of knowing.)
* when you press Caps - LED goes on/off on both keyboards. Simultaneously. Why? Because your keyboard doesn't know anything about what "caps lock" is - it sends a scancode to host, and host sends LED status back. Remember people tapping caps to check if their computer has frozen? Yeah, it's a real test for OS being alive.

Remember Ergodox? There's virtually no* point having dedicated link between halves - should've just been two USB cables. "The keyboard" is an illusion.
*) yeah, remember that "NO way of knowing"? Yeah, that includes layer modifiers - so there's _some_ point of OOB link between halves, but it's not huge.

Upd: Akchually.. there's LED for Shift, and MAY BE some creative use of "usage indicators" might allow for Ctrl, Alt and Win reporting. Need to run some experiments (don't count on it, I'll likely forgot about all of it tomorrow). But even if there's no reporting possible - nothing prevents us from writing a small background application which tell the keyboard via custom OUT report about the state of The Great Keyboard In The Sky, allowing for less clowny macros implementation.

[depletedvespene]

The problem with `:yw` is that if `:yx` is not mapped, what would you do? Retroactively type `:y`?

But even single-key macros are a huge can of pretty nasty worms.
[...]

Much of the problem comes from the fact that people tend to think about "how to get [character] from the keyboard to the screen", while this thing works on two distinct levels — scan codes and the translation from those to characters and whatnot (i.e.: the national layout). Then come the compounded problems of QMK pseudo-scan codes like KC_QUES, which mix those two levels, and are therefore national-layout dependent: KC_QUES is meant to produce the character '?' by sending 0x2A-0xDB... but in most layouts other than en-US and en-UK, it produces '_' instead. Indeed, the most asked question on the Spanish-language mechanical keyboards Telegram group is "How do I get the Ñ character now?" (the answer: just leave QMK's default of KC_SEMICOLON in the C10 key).

[Muirium]

Much of the problem comes from the fact that people tend to think about "how to get [character] from the keyboard to the screen"…

How awful that humans would think in such a humane way.

Whenever I find myself wishing "this key combo should do that", I go ahead and program it if it's sensible. For instance: Control + vowels to produce àèìòù as I’m typing Gaelic. I’m on the Mac, so Control is half vestigial—Command A is select all, etc.—though Control A is a handy home key in text fields, which I duly moved to a much expanded block of text selection macros so I can single keystroke select word and paragraph and the like. Those are super handy when editing, saving me a much-repeated dance of Shift, Command/Option and arrow keys.

To me, everything should be keyboard accessible, and as fluidly as possible. I’m a total keyboard shortcuts junkie in applications, so programming system-wide functions is second nature to me. I used to do it in the keyboards themselves but have moved to Karabiner for things simple USB HID keycodes can't achieve: running scripts and per-app rules.

Really, all that matters is what the user wants to achieve. Hurdles and abstractions are technical flaws to be implemented around.

[kbdfr]

[…] Really, all that matters is what the user wants to achieve. […]

That's something I think we can agree on.

[DMA]

"how to get [character] from the keyboard to the screen"

Where the screen even comes into picture? There are a lot of things that aren't even printable (volume up/down, PrtScr, etc)

KC_QUES is meant to produce the character '?' by sending 0x2A-0xDB...

See? QMK authors are insane. Nobody in their right mind should do that outside of macros. Normal keyboard will never send multiple scancodes for a single keypress.

The "N tilda" question is simply because users aren't paying any attention - I bet if they look at spanish keyboard (which they have laying around, no doubt) they'll see that key is marked "N/;"

[kbdfr]

[…] Indeed, the most asked question on the Spanish-language mechanical keyboards Telegram group is "How do I get the Ñ character now?" […]

[…] The "N tilda" question is simply because users aren't paying any attention - I bet if they look at spanish keyboard (which they have laying around, no doubt) they'll see that key is marked "N/;"

You are American, aren't you

[DMA]

[…] The "N tilda" question is simply because users aren't paying any attention - I bet if they look at spanish keyboard (which they have laying around, no doubt) they'll see that key is marked "N/;"

You are American, aren't you

Since October 28, 2022!

I've seen Russian keyboards a lot, and had to occasionally type on CN/JP/DE - god saved me from encountering FR ones.
All of those had dual legends - English + another. CN/JP aside, I can only remember one key proudly standing apart - and that's "ẞ" on a German keyboard. I still wonder what scancode that produces - because it's tucked somewhere to the right of the spacebar, "where no man has gone before".

Seriously though - what can be done to improve the life of the international layout users? I couldn't find any mappings of HID usages to national symbols. HID spec says "the scancodes are to represent matrix positions, not keycap labels - so if you're making an AZERTY keyboard, don't you fucking dare to send "A" scancode when user presses "A" - send "Q" instead".
Yes, one can reverse-engineer layouts from windows DLLs, but it's kinda BOOORING.
My current approach is not to complicate people's lives by lying to them (as in `KC_QUES` - seriously, what kind of drugs you must be on to even consider this abomination?)

[depletedvespene]

[…] The "N tilda" question is simply because users aren't paying any attention - I bet if they look at spanish keyboard (which they have laying around, no doubt) they'll see that key is marked "N/;"

You are American, aren't you

Since October 28, 2022!

I've seen Russian keyboards a lot, and had to occasionally type on CN/JP/DE - god saved me from encountering FR ones.
All of those had dual legends - English + another. CN/JP aside, I can only remember one key proudly standing apart - and that's "ẞ" on a German keyboard. I still wonder what scancode that produces - because it's tucked somewhere to the right of the spacebar, "where no man has gone before".

Seriously though - what can be done to improve the life of the international layout users? I couldn't find any mappings of HID usages to national symbols. HID spec says "the scancodes are to represent matrix positions, not keycap labels - so if you're making an AZERTY keyboard, don't you fucking dare to send "A" scancode when user presses "A" - send "Q" instead".

It's not the «"A" scancode instead of the "Q" scancode» — it's always 0x51. Let the OS decide whether that should mean 'a' or 'q'.

Yes, one can reverse-engineer layouts from windows DLLs, but it's kinda BOOORING.
My current approach is not to complicate people's lives by lying to them (as in `KC_QUES` - seriously, what kind of drugs you must be on to even consider this abomination?)

That's the point: the keyboard sends scan codes, THEN the OS translates them to different characters. With this layer of indirection, the keyboard doesn't need to know what characters may be available or not. This two-layered design is actually a GOOD thing, as otherwise you'd have to replace keyboards, or at least keyboards' controllers whenever a "new" language came in. Or imagine if you got the "wrong model" of a keyboard and you were stuck writing without, say, the accents and the eñe because "the keyboard is Danish". It just makes no sense.

And that could get worse: imagine if, say, the entire country of Romania had to replace their keyboards because Unicode finally stood up from its lazy ass, disunified the cedilla and comma diacritics, and now Romanians could type the letters Ș and Ț instead of the offensive Ş and Ţ imports. Instead of that, what was done was to simply update the national layout in the OS and be done with it. The keyboard doesn't need to know that there is now a comma diacritic.

As per reverse engineering? Why? We can simply read the published specs of each logical layout in the first place, which is exactly what I did as I wrote my visual guide to national layouts.

The two-layered design is better, more flexible and even has some degree of future-proofing (as the example above shows).

[DMA]

It's not the «"A" scancode instead of the "Q" scancode» — it's always 0x51. Let the OS decide whether that should mean 'a' or 'q'.

That's what I said - although it's 0x14. 0x51 is "down arrow". See, you made me to go look up HID usage tables which I wanted to avoid!

Yes, one can reverse-engineer layouts from windows DLLs, but it's kinda BOOORING.
My current approach is not to complicate people's lives by lying to them (as in `KC_QUES` - seriously, what kind of drugs you must be on to even consider this abomination?)

That's the point: the keyboard sends scan codes, THEN the OS translates them to different characters. With this layer of indirection, the keyboard doesn't need to know what characters may be available or not. This two-layered design is actually a GOOD thing, as otherwise you'd have to replace keyboards, or at least keyboards' controllers whenever a "new" language came in. Or imagine if you got the "wrong model" of a keyboard and you were stuck writing without, say, the accents and the eñe because "the keyboard is Danish". It just makes no sense.

And that could get worse: imagine if, say, the entire country of Romania had to replace their keyboards because Unicode finally stood up from its lazy ass, disunified the cedilla and comma diacritics, and now Romanians could type the letters Ș and Ț instead of the offensive Ş and Ţ imports. Instead of that, what was done was to simply update the national layout in the OS and be done with it. The keyboard doesn't need to know that there is now a comma diacritic.

You are preaching to the choir. I actually implemented an USB keyboard firmware
But yeah, this is exactly why `KC_QUES` is such a dank idea.

As per reverse engineering? Why? We can simply read the published specs of each logical layout in the first place, which is exactly what I did as I wrote my visual guide to national layouts.

In my experience, published specs contain subtle errors which bite later. Well, technically, the spec cannot contain any errors - it's The Spec after all - but inevitably some clown decides to interpret it differently, and all of a sudden we have differences between spec and the real OS behavior, and guess who will be blamed for things "not working properly" should you implement things as spec says.

The two-layered design is better, more flexible and even has some degree of future-proofing (as the example above shows).

You are preaching to the choir, again

PS: the guide to national layouts is awesome, but can you render those keyboards in one column? That picture doesn't fit my monitor horizontally - but more importantly, "stacked layout" will benefit from much shorter distance between same key in different layouts, making them easier to compare visually. I would've even gone as far as having a button to flip between variants in the same space - but short left shift and ISO enter could definitely make this an unpleasant visual experience.

PPS: and where are all the layouts with the big ass enter? Were those exclusive to the non-latin layouts which you don't cover? (what's that "obvious" reason, btw? I can't figure it out myself )

PPPS: is there an easy way for you to make a table of USB scancode vs the weirdest glyph for that key per language? I'll add that to the FlightController layout editor - relatively straightforward thing to do. Reverse-engineering of the layouts from DLL would give me that, of course - but it's a non-trivial amount of work.

[depletedvespene]

It's not the «"A" scancode instead of the "Q" scancode» — it's always 0x51. Let the OS decide whether that should mean 'a' or 'q'.

That's what I said - although it's 0x14. 0x51 is "down arrow". See, you made me to go look up HID usage tables which I wanted to avoid!

………

As per reverse engineering? Why? We can simply read the published specs of each logical layout in the first place, which is exactly what I did as I wrote my visual guide to national layouts.

In my experience, published specs contain subtle errors which bite later. Well, technically, the spec cannot contain any errors - it's The Spec after all - but inevitably some clown decides to interpret it differently, and all of a sudden we have differences between spec and the real OS behavior, and guess who will be blamed for things "not working properly" should you implement things as spec says.

A spec CAN have errors, if it's copying/adapting a previous one. Or it can have inexcusable omissions (like the lack of '«' and '»' in the Spanish and German layouts). OR it can implement inexcusably bad ideas, like placing 'é' in E02 (base) and '2' in E02 (shift) with no way of producing 'É' at all, despite other diacritics being implemented in the same dumb way PLUS a dead key.

Also, OS layouts DO have errors and changes in the way they implement each spec... some of which may be good, some of which aren't. Microsoft's implementation of several European layouts place the euro sign in AltGr-5 in addition to AltGr-E, which I freely acknowledge is much better than the original; OTOH, Microsoft's Swiss layouts both flip the vertical bar ('|') and the broken bar ('¦'), which is a horrible idea. And there's plenty more errors, up to and including omitting the letter W from a particular layout.

Not to say anything of the MacOS national layout implementations, most of which... are a master class on how NOT to do things.

……

PS: the guide to national layouts is awesome, but can you render those keyboards in one column? That picture doesn't fit my monitor horizontally - but more importantly, "stacked layout" will benefit from much shorter distance between same key in different layouts, making them easier to compare visually. I would've even gone as far as having a button to flip between variants in the same space - but short left shift and ISO enter could definitely make this an unpleasant visual experience.

At first I wanted to make a dynamically loaded table (like I did later in the interactive comparator), but went with static images for simplicity... which then turned out to have been a good choice, as they have gained a strong presence in Google Images.

It wouldn't be difficult to make "vertically stacked" versions of those images and make little buttons to switch between them.

PPS: and where are all the layouts with the big ass enter? Were those exclusive to the non-latin layouts which you don't cover? (what's that "obvious" reason, btw? I can't figure it out myself )

We don't talk about BAE in polite company.

Spoiler:

Ultimately, it's better to stick to ANSI and ISO Enter keys and avoid the complication of moving the 0x2B-producing alpha to a third place in E13 (above both D13 and C12)... or elsewhere. Because then taking care of all the BAE variations (vanilla, Focus, Monterey, BADBAE and ISBAE (which is NOT compatible with ISO-intended layouts, as 0xDB and 0xE2 clash)) is just plain nuts.

BAE should be in the dustbin of the bad memories pre-enhanced layout, instead of holding on in (mostly) some Asian companies that insist on producing keyboards with it. IMNAAHO.

PPPS: is there an easy way for you to make a table of USB scancode vs the weirdest glyph for that key per language? I'll add that to the FlightController layout editor - relatively straightforward thing to do. Reverse-engineering of the layouts from DLL would give me that, of course - but it's a non-trivial amount of work.

The visual guide has static images, but the interactive comparator loads the layouts on to the alpha blocks table from a bunch of array objects in a convenient JavaScript file. Open that page and look at namesAndLayouts.js — it shouldn't be difficult to read the array and count character occurences per key/key position.