When Korean keyboard layout (Hangul) is active, Entering a space does not work properly.

[oboki]

When Korean keyboard layout (Hangul) is active
Entering a space does not work properly.

If I enter a space twice, it works as one space.

When the extension downgraded to version 17.x, works properly.

Please help!

To Reproduce
Steps to reproduce the behavior:

1. Set keyboard layout to Korean.
2. Enter a word, enter a space once, and then enter the word again.
3. You can see that there is no space.

[berknam]

@J-Fields Do you have any idea for a way that we can create tests for this sort of issues with different keyboard layouts?

This issue was introduced with #5271 while fixing another issue with chinese input. The problem is that chinese input creates a popup box that stays open until the user presses <Esc> (to cancel), <space> (to accept the first suggestion, it doesn't insert any space), <Enter> (to input the actual latin pressed characters instead of chinese characters) or the number of the pretended suggestion. The CompositionEnd event is triggered when the popup box closes, so we are storing the composition state until the CompositionEnd and then handle the resulting keys one by one.

The problem is that with korean input, there is no popux box, there is a different cursor that shows the changed/replaced characters with each key press and the CompositionEnd event is triggered either by <Esc> (to cancel), <space> (to accept the current character and insert a space), <Enter> (to accept the current character and insert a new line) or when pressing a character key that can't change the existing one (that accepts the current character, ends composition and then starts composition again with the new character).

The <space> and <enter> is already fixed on master, the problem is when you press a character that can't change the current one so it accepts the current one and starts a new composition. This happens on vscode side straight away and that means that it starts the new composition state way before we have the chance to handle and insert the accepted character, so the new composition will always start where we will insert the character and after we insert the character it doesn't update its position so it stays on top of our character. (this was mentioned on this comment #1287 (comment))

I have a fix for this and I'll create a PR as soon as I can so that you can see the difference. It still bugs me a bit, because my fix is basically doing the exact same thing as vscode does (calling the defaults on the CompositionStart and type (after composition started) events) in order to keep track of the inserted text and then remove that text and handle it through Vim which will end up inserting it again. This works well and doesn't reintroduce the issue that #5271 fixed. But this introduces a visual cursor flicker that is barely noticeable if the extensionHost isn't busy but clearly noticeable if it is busy.

With fix:

Current master:

I tried to press the same keys both times and then just gave up... 😄

Notice that on current master the next key composition starts on top of the one that was just inserted but we can't see it until we introduce another one or a space, that might lead to confusion

I will still try to find another way, but it won't be easy since we need to let vscode insert the character so that the composition cursor moves correctly but we also need to handle the resulting keys in order to check for remaps, or in the case of chinese for actions, since with chinese pressing <Enter> results on the initially pressed latin characters.