[VS Code extension] Korean IME composition is dropped in the prompt input — one keystroke leaks as raw Latin after Shift+Enter, and syllables intermittently split into jamo

The prompt input in the VS Code extension loses the active IME composition context, so keystrokes that should have been consumed by the IME reach the textarea raw. This is not the IME switching back to English — the IME stays in Korean mode the whole time; only the composition binding is lost.

Some background so the traces below are readable: on the standard Korean 2-set layout, 라 is typed as f (ㄹ) + k (ㅏ), and 가 is r (ㄱ) + k (ㅏ). A correctly working IME never emits the Latin letters — it composes them into a syllable.

Symptom 1 — one keystroke leaks as raw Latin right after Shift+Enter

Reproducible:

1. Copy some Korean text from a web page.
2. Paste it into the prompt input, then press Shift+Enter for a new line. The IME is still in Korean mode.
3. On the second line, type 라고 (f, k, r, h).

Expected: 라고
Actual: 라 comes out as fㅏ — the first keystroke (f) bypassed the IME entirely and was inserted as a literal Latin f, and the IME only re-engaged from the second keystroke (k → ㅏ).

So exactly one keystroke is lost to the IME, immediately after Shift+Enter. Pasting first makes it noticeably easier to hit — I suspect the paste triggers an extra re-render (long pastes get replaced with a [Pasted text #N] placeholder), which lines up with the Shift+Enter handling.

Symptom 2 — a syllable being composed intermittently splits into jamo

While typing normally (no Shift+Enter involved), an in-progress syllable sometimes gets committed early: 가 ends up as ㄱㅏ, i.e. the ㄱ was flushed as a standalone jamo and the following ㅏ started a new composition instead of joining it. This one is intermittent rather than reproducible on demand, but it happens often enough to be disruptive.

Both symptoms look like the same root cause from two angles: symptom 1 is the composition context not being ready, symptom 2 is an active composition being force-ended.

Suspected cause

The input is a controlled textarea whose value is set programmatically. When the value is reassigned (or the node re-rendered) while a composition is active, the browser fires compositionend and tears down the composition. On Windows (TSF / IMM32), the first keydown that arrives before the IME context is re-attached is delivered to the application instead of being routed to the IME — which is exactly the raw f in symptom 1.

Suggested fix

• Track compositionstart / compositionend and do not reassign the textarea value (or remount the node) while a composition is in flight — queue the update until compositionend.
• In the Shift+Enter handler, insert the newline without a full programmatic value reset if possible.
• Guard key handlers with event.isComposing (keyCode === 229) so IME keystrokes are never treated as committed input.

Notes

• This started at some point relatively recently; it did not happen when I first started using the extension.
• The only workaround I have is to pause briefly after Shift+Enter before typing, or toggle the IME off and on to force it to re-bind.
• This is not Korean-specific in principle — any composition-based IME (Japanese, Chinese) should be able to hit the same path.

Environment

• VS Code extension: 2.1.220 (win32-x64)
• VS Code: 1.109.3
• OS: Windows 11 (10.0.26200)
• IME: Microsoft IME, Korean (ko-KR), 2-set layout