On macOS, Rio does not handle several common IME interactions correctly when
using input methods such as macSKK / AquaSKK (and similar IMEs that rely on
Ctrl+key shortcuts or mode switching). wezterm and other terminal emulators
handle the same scenarios as expected, so the gap is Rio-specific.

Reproduction

Set macSKK (or AquaSKK) as the active input source and launch Rio.

1. Hiragana/Katakana mode does not commit converted text

• Switch macSKK to hiragana mode
• Type a (or ka, i, etc.)

Expected: あ (or か, い) is inserted in the terminal.
Actual: raw a (ka, i) is inserted; the kana commit is lost.

2. Ctrl+J switches IME mode but also inserts a newline

• Switch macSKK to ASCII mode
• Press Ctrl+J

Expected: macSKK switches to hiragana mode; the terminal does not receive
a newline.
Actual: mode switches to hiragana and a newline (\n) is inserted at
the prompt.

3. q switches IME mode but also types q

• In hiragana mode, press q

Expected: macSKK toggles to katakana mode silently.
Actual: mode switches and the literal character q is inserted.

4. No way to keep terminal shortcuts when forwarding modifiers to the IME

There is currently no way to tell Rio "send Ctrl+key to the IME but keep
Cmd+key for the terminal" (or any other granular policy). Either every
modifier combination flows through the IME, or none do, depending on default
behavior.

This makes it hard to use IMEs that need Ctrl+J, Ctrl+G, Shift+letter,
etc., without sacrificing terminal shortcuts.

Comparison

wezterm exposes macos_forward_to_ime_modifier_mask for case 4, and handles
cases 1–3 correctly out of the box. Rio could provide an equivalent.

Environment

• OS: macOS 26.4.1
• IME: macSKK, AquaSKK (and likely other SKK-derived input methods)
• Rio: 0.4.0 (f589a44)

Notes

Same code paths likely affect other IMEs that rely on Ctrl+key shortcuts
(Google Japanese Input / Mozc, ATOK, some Chinese/Korean IMEs), though the
most visible breakage is with SKK.