hermes - 💡(How to fix) Fix Vietnamese Telex IME drops characters & tone marks in Hermes Desktop composer (macOS) [1 pull requests]

Describe the bug

Typing Vietnamese with the macOS built-in Vietnamese Telex input method in the Hermes Desktop composer silently drops characters and tone marks. The committed draft is missing leading words and loses diacritics — e.g. an intended … trả lời đang ít quá vậy rồi ends up rendered as …lời đang ít quá vậy roi% (leading clause trả dropped, tone mark on rồi→roi lost, and a stray % artifact left behind).

This is the macOS / diacritic-composition counterpart of the CJK IME composition bugs already filed (#39620 Windows/Japanese, #39025 Windows/Chinese). Vietnamese Telex composes per-syllable as the user appends tone/diacritic keys, so it triggers the same stale-draft path but produces dropped characters mid-word, not just a lost final candidate — confirming the defect is not CJK-specific.

Steps to reproduce

1. macOS, System Settings → Keyboard → Input Sources → add Vietnamese – Telex (com.apple.inputmethod.VietnameseTelex).
2. Open Hermes Desktop, focus the chat composer.
3. Type a Vietnamese sentence using Telex, e.g. trả lời đang ít quá vậy rồi (Telex keystrokes: traot lowif ddang it quas vaauj rooif).
4. Observe the committed draft: leading words and/or tone marks are missing; occasional stray characters (e.g. %) remain.

Expected behavior

Vietnamese Telex composition should commit the full text with correct diacritics. Confirmed composed text must remain in the composer draft and submit intact.

Actual behavior

Characters and tone marks composed during IME preedit are lost; the draft is missing leading clauses and shows stray artifacts.

Environment

• OS: macOS 15.5
• Hermes Desktop: v0.15.1 (Hermes Agent v0.15.1, 2026.5.29)
• IME: macOS built-in Vietnamese Telex (com.apple.inputmethod.VietnameseTelex)
• Input language: Vietnamese

Root cause analysis

In apps/desktop/src/app/chat/composer/index.tsx:

• handleEditorInput (line 575) early-returns while composingRef.current is true — draft state writes are skipped during composition. This is correct on its own.
• But onCompositionEnd (lines 1230–1232) only flips composingRef.current = false — it does not re-read the editor DOM and commit the finalized text into the draft (aui.composer().setText(composerPlainText(editor))).

The handler relies on a clean input event arriving after compositionend to flush the final text. With macOS Vietnamese Telex on Chromium, that trailing input event is not reliably delivered for the last syllable (tone-mark key folds into the preceding composition), so the diacritic/character composed at the boundary is never written to the draft. The draft then submits stale/partial.

This matches the technical note in #39620: "avoid syncing draft state from onInput while composition is active, then sync the editor DOM text on compositionend and immediately before submit/queue/save."

Proposed fix

In onCompositionEnd, after clearing composingRef.current, immediately reconcile the draft from the editor DOM, and also reconcile once more right before submit/queue/save:

onCompositionEnd={() => {
  composingRef.current = false
  const editor = editorRef.current
  if (editor) {
    const next = composerPlainText(editor)
    if (next !== draftRef.current) {
      draftRef.current = next
      aui.composer().setText(next)
    }
  }
}}

(A defensive composerPlainText(editor) reconcile in the submit path — alongside the existing composingRef guard at line 1285 — would also cover the case where Enter races composition end.)

Related

• #39620 — Japanese IME composition broken in Desktop composer (Windows). Same file, same suggested fix; this report adds the macOS + Vietnamese Telex data point.
• #39025 — Windows Chinese: rich composer draft stays stale.
• #39457 — CJK truncation in CLI (cli.py), separate prompt_toolkit code path; noted only to disambiguate (this is the Desktop/Electron composer, not the CLI).