HaoboGu
Unicode support like QMK's UCIS
Does RMK have any support for sending unicode characters, or is anything planned? According to https://docs.qmk.fm/features/unicode, this is non-trivial and not consistent across OSs.
Similar to Linux's compose key feature, I'd like to use 2, 3 or even longer character sequences to send unicode characters. eg. --. would output – (en dash), :) would send 😊. To be clear, I want to implement this in the keyboard rather than sending a keycode for compose as that isn't supported on Windows.
I envision either:
- Press a "compose" key, type a sequence, then have these replaced by a unicode character.
- Type the sequence, then press "compose" and have the keyboard replace what I typed with a unicode character.
The second approach has to send the characters to the host, but keep a history in a buffer, in case the compose key is pressed. If it is, it backspaces the sequence and sends the unicode (in an OS specific way). The first approach can be implemented similarly (as is done in QMK, or can handle the whole thing in the keyboard before sending anything. I personally favour 2, I think, but either would be fine. I realise this is limited to text editing contexts, but that is a perfectly reasonable limitation.
Any thoughts?
Currently this feature is not planned. PRs are welcome!
Personally I prefer the first solution since it seems to be a "leader key" feature and more easily to implement.
Thanks @HaoboGu, I think you are probably right as it is more similar to other mechanisms.
Reading the QMK doc further, it seems Windows support for unicode input is limited and not considered reliable, so additional software on the host is needed. If that's the case, then I I'll just go with the standard compose key on Linux and use WinCompose to get the same functionality on Windows.
I may have a look at implementing it in RMK once I get a bit more familiar with the code.
I'm looking for this functionality too since I like to use US layout for coding because all brackets and operators are easy to accces and I use English in work anyway. I hate when I have to switch to HUN layout when rarely I have to type hungarian properly with this nice set of extra letters: "áéíóöőúüű" and their capital versions so 9 keys wasted for these and all symbols are accesible with AltGr+... combinations. So I ASAP switch back to the US layout.
So my idea is to use a separate script for each letter, which may either:
- Type Alt+160 on Numpad to get "á" - unfortunately this will not work for "ő,ű", which were forgotten by the standardization comitee back then so they need unicode.
- Type Alt+hexaunicode - but this needs enabling this function in windows beforehand
- Switch input layout by sending alt+shift, send the keycode on the HUN layout, then send again alt+shift to switch back to ENG, but there is no feedback from the OS if it is succesfully switched layout, so this may go out of control... (also, language switching is not standardized, so alt+shift may not work if the one set it up differently)
And a modifier morph behavior is also needed to send the á / Á based on the shift/capslock state - if the alt+numpad technique is used then the numlock state may be important, i'm not sure... also the keyboard could have an OS select switch so on Mac different scripst may be needed.
That looks indeed quite complicated and not uniform across OS's. This article describes how unicode can be printed with different OSs.
When it comes to programmable keyboard they suggest using macros (#308). Having these, I think having a layer for each OS and creating a keymap with all desired unicode characters.
Because of the OS differences I don't think a uniform way with or without a leader key can be implemented. Of course, the same key sequence of a traditional keyboard can be entered with a programmable keyboard to output unicode.
I just saw another way to enter a unicode character (including Umlauts) on a Mac: There is a Unicode-enter-hex keyboard, which looks like a standard US keyboard. But holding option and entering a hex code outputs a unicode character. This could be done with a Macro once we implement it (#308).