vim extension issue with Chinese IME

[localvar]

• VSCode Version: 1.2.1
• OS Version: Windows 10 professional

I tried two Vim extensions, amVim and VsCodeVim, both have problems when using Chinese IME:

• Input Chinese word doesn't work correctly
• issue with Chinese IME

from the comments of the issues: it is not only affect Windows, but also OSX and Linux; and not only Chinese, but also Japanese.

So, it is highly suspect this is an issue of VSC instead of the extensions.

[rebornix]

The reason this issue comes with Vim extensions is because Vim needs to monitor user's keyboard input and all these extensions are listening to type command, but it's working in a strange way.

Let's say users want to type in a Chinese word 安 and in Chinese IME, they should type a + n then in their IME popup window, choose the first word by pressing 1 or space. Currently if you monitor type command, only a is emitted by VS Code.

So ideally, if users type an1 in Chinese IME, VS Code should only pass 安 to type command listeners.

[fenbox]

Hope this can fix soon, it's terrible for Chinese (reference above)

[freshcn]

+1

[Yukaii]

vimStyle works with Chinese

VSC: 1.3.0
OS: Mac OS X El Capitan

Tested with Default Zhuyin IM & Squirrel IM

[rebornix]

@Yukaii are you saying Chinese works perfectly using vimStyle even with steps I mentioned above? Not sure if I set up wrong things, but I just installed latest version of vimStyle and tried to type 安 in normal mode, and the vim mode breaks.

[alexdima]

@localvar @rebornix I am sorry my VIM sample contained a typo that was causing IME to fail when in insert/append mode:

See alexdima/vscode-vim@708d4c0

After that change here is IME in insert mode with my VIM sample:

Please note that his works by overwriting the built-in command replacePreviousChar and then delegating back to it as needed. See here

[alexdima]

Please also note that my sample does not support IME building in normal mode because I am lazy and didn't do it, but not because it could not be possible.

[alexdima]

Also, possible causes for different behaviour in 1.2.1 could be the PR #5615 -- but IMHO the PR is quite good.

[Yukaii]

@rebornix you're right, I found Pinyin IM breaks normal mode as you described, Zhuyin IM also has some problems:

I input "可動" these two word in normal mode and it insert correctly, but when I only type one Zhuyin phonetic character "ㄎ", and press enter, it replace first word "可".

[rebornix]

@alexandrudima oh man, you helped all Chinese Vim users out. replacePreviousChar is exactly what we need to handle CJK IME without breaking the Vim Mode.

[rebornix]

@alexandrudima played with this API and I found that current information is not enough yet. A really simple example:

First, below is what will happen when we use Vim with English IME

1. Open a file
2. Use English IME
3. Type a
4. The Vim mode should be switched to Insert Mode immediately. It's not related to any key strokes after.

Then use Chinese IME

1. Open a file
2. Use Chinese IME
3. Type a
4. Our extension (VSCodeVim or @alexandrudima 's Vim)'s type command handler will be invoked, and args: {text: 'a'} is passed to it. At the same time, replacePreviousChar is still not invoked.

Here comes the problem, since we are using Chinese IME, this a might be replaced by a Chinese character later. But if we are using English IME, we should translate this a to Switch Mode to Insert Mode. In type command handler, we have no idea about the IME info so we don't know how to handle this a correctly.

Another funny example with Chinese IME is

1. Open a file and the Vim Mode is Normal
2. Use Chinese IME
3. Type an
4. A popup window shows up and provides several possible Chinese characters we want to type in.

If we type 1, Chinese IME will pick up the first Chinese character listed in the popup. And we will get a replacePreviousChar event, the args passed in is {text: '安', replaceCharCnt: '2'}. However, if we press Enter key, we will get a replacePreviousChar with {text: 'an', replaceCharCnt: '2'} . The expected way of handing this an in Vim is

1. Switch to Insert Mode (because the first char is a)
2. Insert n.

You may already see the problem, when we get the replacePreviousChar event with arguments {text: 'an', replaceCharCnt: '2'}, we have no idea that whether we should replace previous characters with an or translating them to switch to Insert Mode then insert 'n'. Again, that's because we are lack of the information of IME.

Personally I think it's not a good idea to detect IME info ourselves because we will end up moving the same logic of VS Code to the extension.

[alexdima]

I will investigate further in our code-base, but beware that we don't have any input building (IME) logic either, Chrome does that.

We take the "lower-level" events:

• input
• compositionstart
• compositionupdate
• compositionend

We then do quite some computation to eliminate the text we have previously placed in the <textarea> for screen readers and to accommodate different browsers and then we deduce what was the diff (what was actually typed). https://github.com/Microsoft/vscode/blob/master/src/vs/editor/common/controller/textAreaHandler.ts#L114

So far I have found that these two primitives: type and replacePreviousChar were sufficient, but I understand your problem too, especially in normal mode, where the receival of type: a could be a part of building a complex Chinese word or it could be the actual typed a. And once you've made a decision to go into append mode, replacePreviousChar is not really useful.

I will investigate if we can enrich type and replacePreviousChar, otherwise we might end up exposing something different to help in the normal mode case.

[alexdima]

Here is an example how to use the new compositionStart and compositionEnd:

alexdima/vscode-vim@2c1ccd7

The idea is you can overwrite (similar to type and replacePreviousChar) two more -- compositionStart and compositionEnd. These two new ones should help in distinguishing the composition case vs non-composition case.