macOS: Some input method keybinds penetrates

[lonsagisawa]

Description

I'm using AquaSKK for Japanese input.
AquaSKK uses unusual keybindings, like Ctrl-j to turn on hiragana input, q to toggle hiragana and katakana, l to return to latin input.

In standard macOS applications, keybinds are not transferred to app.

2024-11-08.23.23.26.mp4

However, in Ghostty, IME and Ghostty both receive keybinds.

2024-11-08.23.25.17.mp4

[mitchellh]

Converted to Q&A until we can confirm the issue and verify its in Ghostty. We have many Japanese users and the native IME works fine, so this must be something related to AquaSKK. I'm not familiar with this so will have to try it out to see what's going on.

I happen to be able to read and write Japanese so that's helpful but for the purpose of reproducing the bug can you please detail step by step how things are configured, typed, etc.

[lonsagisawa]

Sorry for unnecessary and so ambiguous issue waste your time.
I will try best to explain repro, but it actually affects very small portion of Japanese user, and can mitigate with workaround with Karabiner-Elements. So keep priority for this issue lower.
Actually with Karabiner-fu Ghostty has speed of Kitty, and feels native like iTerm, and other terminals also has similar issue(explain later), so still best terminals out there! Huge appreciation👏

Repro

1. Install AquaSKK from https://github.com/codefirst/aquaskk/releases
2. Open system settings
3. Move to Keyboard setting
4. Click Edit... besides Text Input section
5. Add AquaSKK input sources(ひらかな, カタカナ, 半角カナ, 全角英数 from Japanese, and ASCII with @-shaped icon from English, see fig.1)
6. Open Ghostty.
7. Set input method to ひらかな, then set input method to ASCII
8. First, try switch to Japanese input mode keybind. Press Ctrl-j.
9. In Ghostty, AquaSKK mode switches ひらかな(Hiragana), AND shell receives Ctrl-j.
10. Try to input some Japanese. Press Shift-n and type ihongo, then press space, return.
11. Great! Kanji conversion should works as intended.
12. Then try Katakana input. Press q to switch mode.
13. AquaSKK switched to Katakana mode, AND shell also receives q.
14. Type tesuto. No need to press return, SKK is modal input method.
15. Return to Latin input press l. AquaSKK returns to ASCII input mode AND shell receives l.
16. Intended input was 日本語テスト, but shell shows empty command input first, and second prompt has 日本語qテストl.
17. Open Terminal.app.
18. Test Japanese input. redo repro no.8 to no.15.
19. Shell should have 日本語テスト in prompt. This is intended input.

fig. 1

Similar issue in other applications

Cross-platform applications usually suffers issue with AquaSKK. WezTer, Kitty also has similar one, but only Ctrl-j inserts symptom.
JetBrains IDEs, Microsoft Office and LINE(WhatsApp equivalent popular in Japan) also has issues, so AquaSKK has compatibility mitigation. It can be applied to Ghostty, I tried, but was not effective.
In native world, iTerm has similar issue and has specific workaround in iTerm side.

[ni-be]

To get the topic back up.

I did some testing as well. I made the following observations:

1. Switching the language using the romaji and kana key will not have any issues.
2. Switching the language with the ctrl+shift (J,K,L,;,') keys will print out the keycode while in the shell and do the action.
3. When in an editor such as helix, keycode will not be printed but for letter j if ctrl+shift+j is used.
4. Transliterate from hiragana - katana etc. works but once control pressed the characters disappear until enter is hit. in shell and editor
5. the ctrl+space binding to switch layouts works as intended.

Basicly the problem lies with keybindings that use the ctrl key for manupulating text.
FYI wezterm, etc. have the same issue, only iterm2 and the built in terminal do not.

[mitchellh]

Issue: #4539