"Unicode Hex Input" required for macOS kana entry

[peterjc]

Quoting the README:

A slide switch above the か key provides three user-selectable Unicode key sequences to support different computer platforms:

• Four-characer hexidecimal Unicode value, followed by Alt-X: Supports Microsoft Word and Wordpad, and LibreOffice Writer.
• Ctrl-Shift-u, followed by four-character hexidecimal Unicode value: Supports Linux applications like LibreOffice Writer and Firefox.
• Option key, followed by four-character hexidecimal Unicode value: Support MacOS applications (not yet tested).

Quoting your macOS code version:

      // MacOS Unicode entry sequence.
      Keyboard.press(KEY_LEFT_ALT);
      delay(20);
      Keyboard.write(n0);
      Keyboard.write(n1);
      Keyboard.write(n2);
      Keyboard.write(n3);
      Keyboard.releaseAll();
      delay(20);

However, there is a caveat you might want to mention. First the user must enable "Unicode Hex Input" as a input source within the macOS keyboard settings (along side where they likely already have "Japanese = Romaji" and/or "Japanese - Kana"). This is right at the end of the list by coutnry under "Other" in macOS Sequoia.

With that done this works:

1. If not already active, toggle to the "Unicode Hex Input" via the top right menu or a keyboard shortcut (in this mode my keyboard otherwise seems to remain in ABC mode, I can type English just fine).
2. Observe a blue "U+" icon appear briefly below the cursor
3. Press-and-hold KEY_LEFT_ALT aka "option"
4. Press "3" (top row or number pad fine)
5. Press "0"
6. Press "4"
7. Press "2"
8. Release KEY_LEFT_ALT
9. The hiragana あ appears
10. Optionally return to the original keyboard mode, again I see a blue icon just below the cursor.

I have not tested your code, just pressing buttons on a QWERTY keyboard.

[peterjc]

Digressing somewhat, but a proof of principle in-software approach to kana chording on macOS!

This is a custom rule for the macOS Karabiner Elements software turning simultaneous use of "a" and "k" into "あ" (assuming the current input mode is "Unicode Hex Input", which could be done via another custom key mapping?):

{
    "description": "Pressing the a and k simultaneously sends kana か (ka)",
    "manipulators": [
        {
            "from": {
                "modifiers": { "optional": ["any"] },
                "simultaneous": [
                    { "key_code": "a" },
                    { "key_code": "k" }
                ],
                "simultaneous_options": { "key_down_order": "insensitive" }
            },
            "parameters": { "basic.simultaneous_threshold_milliseconds": 500 },
            "to": [
                { "sticky_modifier": { "left_option": "on" } },
                {
                    "key_code": "3",
                    "modifiers": "left_option"
                },
                {
                    "key_code": "0",
                    "modifiers": "left_option"
                },
                {
                    "key_code": "4",
                    "modifiers": "left_option"
                },
                {
                    "key_code": "2",
                    "modifiers": "left_option"
                },
                { "sticky_modifier": { "left_option": "off" } }
            ],
            "type": "basic"
        }
    ]
}

See https://karabiner-elements.pqrs.org/docs/json/complex-modifications-manipulator-definition/ etc for their documentation. The verbosity of their rules is a known issue - we'd need almost 100 rules just for the basic hiragana and katakana, but generating those could be automated.

I wouldn't use this on a normal keyboard, the current timings make typing the everyday combination of "a" and "k" troublesome, e.g. getting "あna" rather than "kana" if you type too fast.

However, I think this approach would work in principle with a custom secondary keyboard (where you could probably avoid using AIUEO as the "shift" keys and/or configure the software remapping to only apply to that keyboard).

e.g. Something like this "Mini X Split Keyboard" currently being sold on Ali Express, which has 3 rows of 5 on the left, and another 3 rows of 5 on the right:

[peterjc]

I'm trying out some ideas based on this with the macOS Japanese input modes, and software remapping with Karabiner Elements.

Currently I am using an iOS flick-input like chording approach where any of the ASCII keys representing a row (like k for ka, ki, ku, ke, ko) can be pressed alone or in combination with one of four modifier keys (initially the four cursor keys) giving the five different vowel combinations:

https://github.com/peterjc/kana-chording-ke

Note that in macOS how to enter the kana depends on the current input mode - impossible in non-Japanese mode, by sending hex in "Unicode Hex Input" mode (as done by KanaChord), sending multiple key presses like k then a for か in "Japanese - Romaji" mode, and finally sending the matching key on the JIS layout in "Japanese - Kana" mode (か is on the t key). In either Japanese mode you then get kanji selection support 🤩

For the KanaChord project, I assume you emulate a HID keyboard. I think you would need a macOS language mode switch on the keyboard (just like how you currently switch between Linux, Windows, or macOS in hex mode), or assume the Mac computer is in the matching mode. There are macOS add-ons which will try to switch the language mode when a different physical keyboard is used, that might work here if for example using a USA layout laptop with an external KanaChord keyboard?