vovkasm / input-source-switcher

Command line input source switcher for Mac.
MIT License
139 stars 11 forks source link

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

Open rlue opened 7 years ago

rlue commented 7 years ago

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:

Thoughts?

vovkasm commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

Enjoy your vacation.

rlue commented 7 years ago

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

vovkasm commented 7 years ago

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

laishulu commented 4 years ago

emacs-mac don't have such a problem

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

laishulu commented 4 years ago

kawa has a workaround

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

vovkasm commented 4 years ago

Thanks! I'll look at it!

laishulu commented 4 years ago

https://github.com/laishulu/macism

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

laishulu commented 4 years ago

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

图片

How to implement it in codes?