IME behavior

Typing Chinese, Japanese or Korean through an IME (input method editor) composes text in stages before it becomes committed input — pressing a key does not mean a character has actually been typed yet. The widget is IME-safe: it never sends a query for text that is still composing.

The rule

Only the last committed query is searched. The segment currently being composed is shown with the browser's normal composition underline, but it is excluded from the query sent to the API.

For example, typing toward 稍後閱讀 (read later) through an IME:

1. 稍後閱 commits — the widget searches 稍後閱, and results for it appear.
2. 讀 begins composing — the widget shows the composition underline after 稍後閱, but does not search 稍後閱讀 yet, and does not clear the existing results.
3. 讀 commits — now the widget searches the full 稍後閱讀.

Results never flicker to empty or stale mid-composition; they stay exactly as they were for the last committed query until the next commit.

Why this matters

Without this guard, every intermediate composition state would fire a query, most of which are not real words yet — wasted requests, and results that visibly thrash as a reader is still deciding what to type. suo's bigram-based CJK recall (see CJK) already makes a partially-typed committed query useful, so there is no need to query composing text to get a responsive feel.

Testing this yourself

The most reliable way to see this behavior is a real IME: switch to a Chinese or Japanese input method, open the playground or a live widget, and type a multi-character word slowly, watching the network panel — a request should appear only after each commit, never on a composition update.

Composition and keyboard shortcuts

While composing, ↵ confirms the IME's own candidate selection rather than opening a search result — the widget only treats ↵ as "open the highlighted result" once composition has ended. This matches how every other combobox on the platform (and the OS text field it is composing into) behaves.