When I type chinese characters, the new letter will be inserted to the left of the cursor.

I don't have this issue on macOS with Code 1.6.1 and 1.7.0-Insiders. Seems like it's a system related issue and I have a feeling that it's a Code issue.
It also works great on Windows platform 😢
Thanks for your reply :P
I have the same issue:

I also have this problem :cry:
I can reproduce this issue on Ubuntu. Sorry guys I'll reopen it and see what's going on under the hood.
After digging into the code, it's a Code issue (my previous suspicion turns out to be correct).
@rebornix Other vim plugins, such as amVim, don't have this problem, does VSCodeVim use a different implementation mechanism?
@jetz we rely on selection change heavily as that's necessary for part of the features, but seems Code is generating wrong selection change when composition ends.
@rebornix thanks for your reply.
VSCodeVim on my Ubuntu has this problem, but it works well on Deepin(a debian-based linux distro) of my colleague, that's werid.
Highly rely on this plugin in Code, waiting for good news.
Hi @rebornix, after investigating a bit, I think these lines caused the problem:
https://github.com/VSCodeVim/Vim/blob/master/src/textEditor.ts#L25-L37
Code:
static async insert(text: string, at: Position | undefined = undefined,
letVSCodeHandleKeystrokes: boolean | undefined = undefined): Promise<boolean> {
// If we insert "blah(" with default:type, VSCode will insert the closing ).
// We *probably* don't want that to happen if we're inserting a lot of text.
if (letVSCodeHandleKeystrokes === undefined) {
letVSCodeHandleKeystrokes = text.length === 1;
}
if (!letVSCodeHandleKeystrokes) {
const selections = vscode.window.activeTextEditor.selections.slice(0);
await vscode.window.activeTextEditor.edit(editBuilder => {
if (!at) {
at = Position.FromVSCodePosition(vscode.window.activeTextEditor.selection.active);
}
editBuilder.insert(at!, text);
});
// maintain all selections in multi-cursor mode.
vscode.window.activeTextEditor.selections = selections;
} else {
await vscode.commands.executeCommand('default:type', { text });
}
return true;
}
Stack Tree (Right after inputting "示例" in Insert Mode):
insert (/home/fallenmax/code/github/Vim/out/src/textEditor.js:21)
(anonymous function) (/home/fallenmax/code/github/Vim/src/mode/modeHandler.ts:1332)
__awaiter (/home/fallenmax/code/github/Vim/out/src/mode/modeHandler.js:7)
__awaiter (/home/fallenmax/code/github/Vim/out/src/mode/modeHandler.js:3)
executeCommand (/home/fallenmax/code/github/Vim/out/src/mode/modeHandler.js:945)
(anonymous function) (/home/fallenmax/code/github/Vim/src/mode/modeHandler.ts:887)
fulfilled (/home/fallenmax/code/github/Vim/out/src/mode/modeHandler.js:4)
_tickCallback (next_tick.js:103)
As CJK characters are usually inputted with some input method software, they are emitted to vscode as a chunk of text (i.e. “示例” instead of "示", "例" separately), so the if() branch runs if we input >1 CJK characters.
After await vscode.window.activeTextEditor.edit(), L37: vscode.window.activeTextEditor.selections = selections resets selection(=cursor) to position where we start, which caused this problem.
I tried deleting L37, and cursor position is correct now. But I'm not sure if this removal won't cause other problems, so please take a look :P
@FallenMax Thank you, your solution is useful.
@FallenMax sorry for reaching out too lated and your investigation saved me a lot of time, it's the root cause :)
That line was added too long ago and the comment is saying that we did that for multi-cursor. I'd like to hear @johnfn 's comment on this.
@rebornix
Hmm. I can't actually recall the purpose of that line, though I'm sure it was important lol. The good news is that that entire method has been deprecated. If we can replace it with the new way of inserting text, we can get rid of it entirely.
@rebornix
sorry for my english , is the issue resolved?
this issue suddenly occurs when I update my vscode(to 1.11) and vim plugin(to 0.6.17).
and when I rollback the version to 1.10.2 and 0.3.8, the bug still exists.
I use ubuntu 16.04 and fcitx 4.2.9.1
i also have the same problem in my desktop computer but my labtop doesn't have the problem and they have the same os : manjaro
I don't buy it that that line is necessary. The only changes between the two lines of the selection is that we call await vscode.window.activeTextEditor!.edit(). That shouldn't affect selections at all. Unluckily, the original purpose of that line seems to have been obscured... https://github.com/VSCodeVim/Vim/commit/234040a4343d63eafa9662ba882e6d3f81ee2683
Also, I can't really tell the purpose of the line that says
if (letVSCodeHandleKeystrokes === undefined) {
letVSCodeHandleKeystrokes = text.length === 1;
}
https://github.com/VSCodeVim/Vim/commit/c49fa2294f5aea6ecfbd6d38cf5ba06e70fe0116 is the relevant commit, but I have no idea what that J bug is... @johnfn
Upon testing, removing either of the lines seems to fix the issue, and doesn't seem to introduce any other bugs...
I'm adding a possible fix for this issue in the next release. Please try out the release and report whether it's fixed or not. It will be version 0.8.4
Thank you @Chillee .It's fixed
OS: Ubuntu 14.04
VSCode: 1.12.2
VSCodeVim: 0.8.4
As multiple people have reported this issue as fixed, I will close this issue. Please report it if it's still a problem.
Most helpful comment
I have the same issue: