Switching to Chinese/Korean IMEs produce Latin/QWERTY output until switching windows

[rlue]

I discovered this project by way of vim-xkbswitch, after first learning of xkbswitch-macosx.

In using issw, I came across a bug identical to one I found in xkbswitch (reported here). The text of that issue is copied below, with references to xkbswitch replaced with issw:

---

I'm running into a strange problem where I can use issw to switch IMEs, but for certain non-Latin input methods, input to the current window comes out as US English until you switch to another window.

Specifically, I've tested on a handful of languages (Arabic, Spanish, English, Japanese-Hiragana, Japanese-Katakana, Korean, Simplified Chinese-Pinyin, Traditional Chinese-Zhuyin), and it only seems to be happening in Korean and Chinese (both Pinyin and Zhuyin) — both East Asian IMEs with alternate modes for English input.

Observations:

• It's not limited to the GUI terminal.

  I thought it might just be limited to the terminal at first, but then tested by running

  sleep 3 && issw -s 1 
  

  switching over to Firefox, waiting for the IME to change, and then starting to type. The same thing happens.

• It's always US English output, even if you're switching from a non-Latin language. (Possibly because US English is the default on my system.)

  If switching from Arabic to Chinese, US English characters still come out, not Arabic or Chinese. Usually, it's normal (single-width) characters, but sometimes (still haven't figured out why/when), it's double-width characters. Originally, this led me to believe that the unexpected US English input I was observing was a sub-mode of the IME that issw had switched to, but then I noticed the following:

  Both Korean and Chinese IMEs offer some mechanism for inputting US English characters without having to switch back to the English IME (in Zhuyin, caps lock will force all input to Latin/QWERTY; in Korean, holding down <Option> does the same). The behavior described in this issue is not a result of triggering these mechanisms: when this problem begins, <Option-a> outputs ‘å’, which is ordinarily not possible in Zhuyin.

• issw appears to preserve some IME statefulness that is not preserved by the standard system keyboard shortcut for switching IMEs.

  This one's kind of hard to explain, so I'll format it as a series of shell commands with comments:

  $ issw com.apple.inputmethod.TCIM.Zhuyin # switches to Chinese
  $ asdf                                   # at this point, input comes out in Latin/QWERTY
  
  # but if I switch to Firefox, the Chinese IME begins working correctly
  # and if I switch back to the terminal...
  
  $ ㄅㄆㄇㄈ                               # Chinese continues to work
  $ issw com.apple.keylayout.US            # at that point, I can switch back to English (pulling up this command via readline history)
  $ issw com.apple.inputmethod.TCIM.Zhuyin # then back to Chinese
  $ ㄅㄆㄇㄈ                               # and it works _without having to switch windows_
  
  # but then if I switch back to English with the system keyboard shortcut (CMD-Space)
  
  $ issw com.apple.inputmethod.TCIM.Zhuyin # and switch back to Chinese again
  $ asdf                                   # then we're back where we started...
  

Thoughts?

[vovkasm]

Thank you!
Will try my best to fix this.

Can you describe you system settings more detailed, particularly I'am interested what state of the: "Automatically switch to a document’s input source" checkbox (can be found in System Preferences -> Keyboard -> Input Sources)?

[rlue]

Wow, that was a fast reply!

That checkbox is not checked, but the behavior is the same even if it is. I'm happy to supply any other configuration information you require!

[vovkasm]

After some experiments, seems it is fixable, moreover it can fix other bugs and strange behaviours. But I need some time (probably day or two) to rewrite code properly.

[vovkasm]

Current progress:

After some experiments, seems it is fixable, moreover it can fix other bugs and strange behaviours.

Actually not (I was think that this issue can be fixed by run actual NSRunLoop to allow HIToolbox to manage its cooperation with other system processes). I converted code to use run loop, but unfortunately issue remain. I have some thoughts...

Documentation (note that this is all old and deprecated apis) from TextInputServices.h:

When an input method or mode is the selected input source, TSM will by default use the most-recently-used ASCII-capable keyboard layout to translate key events* (this keyboard layout is also the one that will appear in Keyboard Viewer); an input source for this keyboard layout is returned by TISCopyCurrentASCIICapableKeyboardLayout. If a different keyboard layout should be used for a particular input method or mode, then when that input method/mode is activated it should call TISSetInputMethodKeyboardLayoutOverride to specify the desired keyboard layout.

So this is documented behavior. And I think that by call TISSetInputMethodKeyboardLayoutOverride it is possible to switch to normal keyboard layout (but still not tested it). My current problem that I can't find method to find proper input source id for this "normal" layout. Experimentally I found it for method com.apple.inputmethod.TCIM.Zhuyin it is com.apple.keylayout.ZhuyinBopomofo, but I cant figure out how to programmatically get this id (or set of candidates) from original input source (source that user want to switch to).

Currently I try investigate how TIS currently work in my system to found out the proper way to address this problem.
Findings (may be not correct, it is my current thoughts):

1. TISwitcher process seems to initiate IM switch (it shows keyboard switch UI and handle hot keys).
2. SystemUIServer also involved (seems to handle messages from TISwitcher and sends distributed notifications to other processes)
3. HIToolbox framework has special methods to handle CapsLock state for IM that allow ascii keyboard layout. You can disassemble (otool -tvV /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/HIToolbox > ~/HIToolbox.dis) and see these symbols in code: _TISCapsLockSwitchShouldKeyboardLayoutUseAlternateForModifiers, _TISCopyCapsLockDesignatedInputMethodRomanMode, _TISToggleDesignatedInputMethodRomanMode, etc...

[rlue]

Jesus, this sounds like a real can of worms...

TSM will by default use the most-recently-used ASCII-capable keyboard layout to translate key events

Very strange, since issw still works for a lot of other non-ASCII input methods (e.g., Arabic, Japanese, Russian).

I wish I could help, but you clearly know way more about this than I do.

[vovkasm]

I think issw works for most input methods because those input methods don't have ascii-capable keyboard layouts or how it name properly... You absolutely correctly detected problem, only input sources that can "fast switch" to ascii with CapsLock key will show problem.

I will try to investigate more, but not sure about time... (If not this week, then only in September, because of vacation, sorry)

[rlue]

No rush — these problems aren't going anywhere. ;)

Enjoy your vacation.

[rlue]

Hey, just thought I'd check in. Any progress on this issue? (If not, no worries.)

[vovkasm]

Hi! Sorry, still in TODO... :-(

[laishulu]

emacs-mac don't have such a problem

https://bitbucket.org/mituharu/emacs-mac/src/26c8fd9920db9d34ae8f78bceaec714230824dac/src/macfns.c?at=master#macfns.c

[laishulu]

kawa has a workaround

https://github.com/utatti/kawa/blob/master/kawa/TISInputSourceExtension.swift

[vovkasm]

Thanks! I'll look at it!

[laishulu]

https://github.com/laishulu/macism

I wrote an alternative tool, based on the codes from https://github.com/utatti/kawa

[laishulu]

@vovkasm
I want to check whether the input method is at the composition status, just like this

How to implement it in codes?