Open rlue opened 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)?
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!
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.
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):
TISwitcher
process seems to initiate IM switch (it shows keyboard switch UI and handle hot keys).SystemUIServer
also involved (seems to handle messages from TISwitcher and sends distributed notifications to other processes)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...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.
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)
No rush — these problems aren't going anywhere. ;)
Enjoy your vacation.
Hey, just thought I'd check in. Any progress on this issue? (If not, no worries.)
Hi! Sorry, still in TODO... :-(
emacs-mac don't have such a problem
kawa has a workaround
https://github.com/utatti/kawa/blob/master/kawa/TISInputSourceExtension.swift
Thanks! I'll look at it!
https://github.com/laishulu/macism
I wrote an alternative tool, based on the codes from https://github.com/utatti/kawa
@vovkasm I want to check whether the input method is at the composition status, just like this
How to implement it in codes?
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 toxkbswitch
replaced withissw
: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:
Thoughts?