Sure, ping away.
I’m not 100% sure but I think implementing what Windows has in layouts for Mac/Linux sounds like the easiest option then providing a simple layout installer for both Operating Systems.
Yep. The major OSes have a way to enter unicode symbols this way, they are just different across all three. 
Yes, which is why I designed a scancode layout which works with the largest number of pc-105 OS keymaps (see the dvorak thread). It turns out like this for German-QWERTZ:
http://www.keyboard-layout-editor.com/#/gists/460b2858a4795cb02f4df890a6bb6be4
As you can see, ÄÖÜ end up in their usual positions.
1 Like
That is why a diacritics key that is pressed after the letter you want to decorate is so appealing. To get different diacritics you press the key more then once. The only thing is that you have to have an order of diacritics based on the usage.
“e” + 1x “diacritcs-key” = é
“e” + 2x “diacritcs-key” = è
“e” + 3x “diacritcs-key” = ê
…
I’m glad to hear that that layout works good for you.
Currently I’m using a similar layout on the ErgoDox with the addition of layer 3 and 4 from the neo-layout. But I’m really unhappy with äü and especially ß.
Researching on alternative keyboard layouts I first stumbled over dvorak and then onto neo that lead me further to adnw. What I do want to implement and learn is PUQ. That is the source of the idea of a “diacritics-key”.
A couple of things that come to mind with the diacritic key:
To just cover latin based languages you need at least 12 diacritics plus all the other symbols/special characters.
In reality cycling through anything more than 4 is probably too much so you would probably need 3-4 diacritic keys plus then AltGr plus Char for special symbols.
Special care would have to be made for mode like editors (such as vi/vim) seeing as backspace might not have the same meaning on those platforms and if one leaves a mode and then accidentally presses the diacritic key some very bad things could happen.
I think browsers might also be very confused since backspace usually has special meaning.
There are certainly more edge cases (such as consoles, VMWare/Virtualbox and Remote Screen Sharing) that would have to be taken into consideration.
2 Likes
I don’t use it for typing German, if that’s what you mean. I’m trying to reach a scancode layout for the model 01 (and other similar keyboards such as kinesis, ergodox etc.) that works with the existing keymaps in your OS to produce effective layouts that differ minimally from the layout on a standard pc105 keyboard.
If you want to use a novel keymap, then I strongly believe the place to do it is in the OS. Firstly, if you want to type characters that aren’t in US-QWERTY you need to select a localised OS keymap anyway, because there is no OS keymap that has entries for all characters. If you need to change the OS keymap, then why not keep it simple and do everything in the keymap? Installing new OS keymaps is easier than reflashing the firmware on a keyboard. Secondly, OS keymaps apply to all keyboards. Dvorak, neo, adnw, puq have already been implemented in OSes. Why duplicate effort?
Input methods like dead keys, compose keys, kanji, etc. are not specific to keyboard hardware, and therefore the place to improve them is not in hardware.
1 Like
I just played with a few different options on my ErgoDox, and so far, my experience is as follows, based on inputting some Hungarian text, with a number of different diacritics: áóöőéúüűí are what we have.
OS-side Compose key
This is the old and tried way, where I press Compose (bound to a thumb key for the sake of the experiment), select the diacritic: ', ", or = in case of Hungarian, and then the base symbol. To enter ö, the sequence is AltGr, Shift+' (for "), and o. For ő, it is similar, but the diacritic is a simple =. This is three keys for a single symbol. Reasonably flexible, but results in slow typing.
Dedicated Hungarian symbols on a one-shot layer
This is what I currently use, and with which I’m the most familiar with. I use a one-shot layer with the Hungarian accented chars, in positions near the base symbol. For example, ó is on the same key o is on the base layer, ő is the key above, ö is the one below, and so on.
To enter a single symbol, I only need two keys, and I put the layer key on the right hand, while the vowels are on the left (I’m using a Dvorak layout).
This takes some practice to get used to, but I can type Hungarian almost at the same speed as I type English (70WPM English average, 60-62 Hungarian).
The big downside of this is that this is not flexible, if you need more than three variants of a single base symbol, that’s hard to place well, nor is it easy to place an æ key, for example.
Diacritics key
I tried the diacritic idea briefly, and must say it is interesting. My main issue is that I have to remember how many times to tap a key to get to a specific diacritic, and I’m terrible at remembering these things. Position: sure, no problem! More than two taps? Brain goes “yeah, no, how about we accidentally press it a few more times? Ok? No? Doesn’t matter, I like THIS rhythm better, screw you!”, and all hell breaks loose.
But that’s just me, the idea is still interesting, and something that has been used on old cellphones of the past, and in other peripherals too, to great success.
The main issue is the backspace:
Just ran into this, and my Emacs was making funny faces, and I became very confused, trying to figure out what just happened. Turns out that I instinctly pressed ESC to cancel the diacritic input, but forgot to wire up my ESC key to cancel it, so it sent an ESC, Emacs got out into command mode, and bad things happened after. Could be solved by wiring up my ESC to cancel this too, but even then, backspacing can confuse software.
However, there’s a way around that!
Diacritic without a dedicated key
May not be an option for all languages, but for Hungarian, I was able to make the o key a tap-dance key: press once, get o, tap twice, get ó, tap three times, ö, four times ő. This avoids the backspacing, but lacks visual indication about where you are at. On the ErgoDox, I could use the status LEDs, on the Model 01, the color of the key could indicate the state, which would be much more helpful.
But there are too many taps involved to get to ő, even more than with a Compose-key, and that breaks the flow of typing for me. But that may be because I’m not used to tapping a single key multiple times… I mean, I saw people on the tram, a decade ago, who were typing on those 3x3 cellphone keypads faster than I could type on a regular keyboard at the time.
Chording
I also tried a quick hack that made it possible for me to hold o, Shift and ' to get ö, and so far, this was the second best after the one-shot layer thing for me, even though I’m not a big fan of chording. I liked this, because it was reasonably easy to implement, did not require much of a dictionary to convert the held keys to a sequence the OS needs to enter the symbol. The order didn’t matter, either, which is great, because with a Compose key, I always mix up which one I should enter first: diacritic or base key? With chords, it doesn’t matter.
This does not involve backspacing, either, so yay!
Summary
There is no summary. These are just quick tests and hacks, to get a feeling of both implementation complexity, and a feeling of use, and perhaps to discover side-effects.
1 Like
You only need a localised keymap, if you are not using some kind of composition, or unicode input method or somesuch. Most OSes support both, and you can get away with not having a custom OS-side keymap. There are quite a number of reasons why would want to avoid custom keymaps on the OS-side, but that’s a different topic, for another day 
1 Like
How about using dead-keys, they avoid some of the discomfort of chording, confusion of multiple presses on a single key and IMHO offer the second best usability and probably the best compromise on space vs. usability.
2 Likes
I don’t often type accented characters, but the “diacritics key” method mentioned seems like it could be confusing in practice: If I’m used to thinking I can type a letter, have the letter appear, then the diacritics key to change it, I would expect that, for instance, I could type a word, then go back into the middle of the word and use the diacritics key to alter the letter next to the cursor. Obviously that wouldn’t work, but as a user that is a annoying abstraction leakage.
3 Likes
Can you describe an example of what you mean by using dead keys? I’m having trouble imagining how that would differ in practice from the OS-provided Compose key, except that it may be implemented in firmware.
That depends on your prior experience. On a lot of virtual keyboards, common on phones, you have the ability to long-press a letter, and have a small popup to select variants from, or tap it multiple times to cycle through them, much like with the diacritic key. On these virtual keyboards, this works only after you type a letter, going back and tapping the letter again won’t cycle or bring up the popup.
If one’s familiar with this type of input, the expectation may be different, and they’d just delete the base letter too, and input it again.
1 Like
Rather than pressing the compose key, then a symbol like for example ’ or " you just have a key that is a dead key for ’ " and possibly more.
Example: Press dead ’ followed by the key “a” the result is á, one less keypress, when implemented in firmware the dead key is actually not sent to the OS until the following key is also interpreted and the whole thing is sent in Unicode.
A dead key can then have up to 4 accents or modifiers, one without shift, one with shift plus the Alt or possibly Ctrl.
2 Likes
wow. you are moving fast
btw. there is a solution for windows using autohotkey for the diacritics key with the PUQ layout.
For diacritics that you use seldom it might be a problem to remember how many times you would have to type. I imagine that would only slow me down a little since I would only have to type carefully until I see the right one.
In most cases I’ll only use the first available diacritic anyway (for me that would be s->ß, a->ä, u->ü, o->ö, e->é, n->ñ). For other languages like french it would be almost always the same rythm (e->é->è->ê, a->á->à->â). So it boils down to the diacritics you use very seldom that are going to be slow. That is probably the same situation as it is today.
I can vividly imagine how you must have felt with that 
. The bad thing is that I don’t see a way around the occasional glitch apart from going down the road of implementing it directly in the OS. Are you using diacritics frequently with emacs or vi or the like?
I just discovered another problem on windows: Trying to use the “universal” method of unicode-input, which is holding down alt and pressing numpad plus followed by the hex code, I triggered a menu in chrome because it seems to intercept alt+f 
That is an interesting idea too. For the most used diacritics I think I would be fine with that solution (tho I think I would still prefer a dedicated key in order to use two different fingers for typing instead of repeating one). For the seldom used ones I would probably be lost. Do I get the idea right in that it would time out or just use the next pressed key to actually send the sequence to the host?
Maybe the solution would be to have a diacritics key with a known number of times for the mostly used diacritics for speedy input in the most common cases plus a dead-key layer for seldomly used diacritics?
1 Like
Hm. Interesting. I could get away with a single such key for Hungarian then, that seems doable. Will try a quick test on my ErgoDox next time I have a few spare minutes. In theory, it sounds more convenient than my current solution…
TRIGGER, o => ó, Shift, TRIGGER, o => ö, Ctrl, TRIGGER, o => ő. Not bad. The last two are one more key than with my current solution, but has the symbol on the same position as the base letter, which may make up for the extra key.
Thanks!
1 Like
Yeah, I practically live in Emacs, pretty much 90% of all keys I press ends up in Emacs.
Ah, yeah. This is not consistent on Windows at all, not even within Microsoft’s own applications: I seem to remember a QMK issue where someone discovered that Office does not support unicode input, but Notepad for example does. They ended up using WinCompose, that worked across the board.
Yes, that is correct.
1 Like
I notice the one solution you didn’t try was a localised Hungarian keymap…
Of course there are ways to use input methods (such as compose-key, my personal favourite) to input arbitrary characters. But the majority of native-language speakers prefer to use localised keymaps – or only know how to use a localised keymap – partly because of familiarity and partly for the reasons you enumerated in your tests above…
I wasn’t yet aware of the hungarian layout. Is your point that this layout exists on all major OSes as a standard and would allow to send “normal” scancodes in order to get all the possible diacritics instead of using weird altgr+various keys combinations?