[Bug] Fcitx5/Rime IME Enter key and candidate-window issues in integrated terminal

[cxiaoxiong]

Before Submitting

• I searched existing issues and did not find a duplicate.
• I can reproduce this issue on the latest release (or latest main build).
• I included reproducible details (environment, steps, expected and actual behavior, and evidence), not only a code-level suggestion.

Bug Summary

Bug Summary

On Ubuntu with Fcitx5 + Rime (Xiaohe Shuangpin), I found two IME-related issues in VMark's integrated terminal.

Issue 1

When Rime is in Chinese input mode, pressing Enter cannot commit the raw Latin letters / pinyin text.

This happens both:

• directly at the Bash prompt in VMark's integrated terminal
• inside Claude Code
• inside Codex CLI

I have to manually switch the input method to English mode before I can reliably enter English text or commands.

Issue 2

The normal Bash prompt itself does not flicker when using Rime, but after starting Claude Code or Codex CLI, the IME composition/input area flickers while typing.

In addition, when Claude Code or Codex CLI is first opened, the Fcitx5/Rime candidate/preedit window can appear in the wrong place on the screen instead of below the terminal caret.

After resizing, maximizing, or dragging the VMark window once, the candidate window moves back to the correct position.

---

Environment

• OS: Ubuntu 24.04.4 LTS
• Session: Wayland
• Shell: /bin/bash
• Input method framework: Fcitx5
• Input method: Rime
• Scheme: Xiaohe Shuangpin (小鹤双拼)
• VMark: latest release
• Installation: .deb
• Claude Code: installed via npm/nvm
• Codex CLI: installed via npm/nvm

Session type:

echo $XDG_SESSION_TYPE

### Operating System

Linux

### VMark Version

VMark_0.9.65_amd64

### Install Method

DMG / Installer Download

### Steps to Reproduce

1. Open VMark on Ubuntu 24.04.4 LTS under Wayland.
2. Open VMark's integrated terminal.
3. Use Fcitx5 + Rime with Xiaohe Shuangpin enabled.
4. Keep the input method in Chinese mode.
5. At the normal Bash prompt, type raw Latin text such as `claude`.
6. Press `Enter` to try to commit the raw Latin/pinyin text.
7. Start Claude Code or Codex CLI in the integrated terminal.
8. Begin composing Chinese text inside the Claude Code / Codex interactive input field.
9. Observe the IME candidate/preedit window position.
10. Resize, maximize, or drag the VMark window once and observe whether the IME candidate window position changes.

### Expected Behavior

- While Fcitx5/Rime is in Chinese mode, pressing `Enter` should be able to commit raw Latin/pinyin text such as `claude`, without requiring me to manually switch to English input mode first.
- Chinese IME composition inside Claude Code and Codex CLI should not flicker.
- The Fcitx5/Rime candidate/preedit window should appear near the terminal caret immediately.
- Resizing or dragging the VMark window should not be required to correct the IME candidate window position.
- Behavior should be similar to the Ubuntu system terminal.

### Actual Behavior

There are two reproducible issues.

1. Enter cannot commit raw Latin/pinyin text in Chinese IME mode

When Fcitx5/Rime is in Chinese mode and I type raw Latin text such as `claude`, pressing `Enter` does not commit the text as expected.

This happens both:
- at the normal Bash prompt in VMark's integrated terminal
- inside Claude Code
- inside Codex CLI

I have to manually switch the input method to English mode first before I can reliably enter English commands or words.

2. IME flickering and incorrect candidate-window position in Claude Code / Codex CLI

At the normal Bash prompt, Chinese input does not flicker.

However, after starting Claude Code or Codex CLI, the Chinese IME composition/input area visibly flickers while typing.

Also, when I first start typing, the Fcitx5/Rime candidate/preedit window may appear in a corner of the screen instead of near the terminal caret.

After resizing, maximizing, or dragging the VMark window once, the candidate window moves back to the correct position near the caret.

### Logs, Screenshots, or Repro

Environment:

```text
OS: Ubuntu 24.04.4 LTS
Session: Wayland
Shell: /bin/bash
Input method framework: Fcitx5
Input method: Rime
Scheme: Xiaohe Shuangpin
VMark installation: .deb
WebGL Renderer: OFF
Shell Integration: ON

### Additional Context

_No response_

[cxiaoxiong]

Additional Context 填：

This appears to involve two related but distinct IME behaviors:

1. `Enter` / composition handling in the integrated terminal itself, because the raw-Latin commit problem also occurs at the Bash prompt.
2. IME rendering / caret geometry inside terminal TUIs such as Claude Code and Codex CLI, because flickering mainly appears after entering those interactive interfaces.

I also tested changing the Rime preedit mode, but it did not resolve the problem.

The VMark Markdown editor itself does not show the same flickering behavior.

The Ubuntu system terminal does not exhibit these problems with the same Fcitx5/Rime configuration.

[xiaolai]

Thanks for the report — the two symptoms are described precisely enough to act on, and the detail that the preedit window snaps back into place after a resize or drag is a real clue rather than a footnote.

I can't reproduce this here. VMark is developed on macOS, and the two Linux machines I have access to are headless aarch64 boxes with no Fcitx5 installed, while VMark's Linux artifacts are x86_64 only. Guessing at IME behaviour without a reproduction is how the wrong fix gets shipped, so I'd rather ask you for a few specifics than invent one.

The most useful single thing:

fcitx5-diagnose > fcitx5-diagnose.txt 2>&1

and attach that file. It reports the input-method framework's own view of the environment, which is where most of these turn out to live.

Then, if you can, the environment variables VMark itself sees. Launch it from a terminal and include:

echo "GTK_IM_MODULE=$GTK_IM_MODULE QT_IM_MODULE=$QT_IM_MODULE XMODIFIERS=$XMODIFIERS"
echo "session=$XDG_SESSION_TYPE  desktop=$XDG_CURRENT_DESKTOP"

This matters more than it looks. VMark's UI is WebKitGTK, so it goes through the GTK input-method module, and a value of fcitx versus fcitx5 versus unset changes the behaviour completely. Whether the session is Wayland or X11 decides how candidate-window positioning is reported at all, which is the likely home of your second symptom.

Three questions that would narrow it further:

1. Does the Enter problem happen in VMark's editor as well, or only in the integrated terminal? The two take completely different input paths — the editor is a normal contenteditable, the terminal is xterm.js reading keys through its own handler — so the answer splits the search space roughly in half.
2. Does it also happen in an ordinary GNOME Terminal or Konsole running the same Claude Code or Codex CLI? That separates "VMark's terminal" from "Fcitx5 with these programs".
3. For the misplaced candidate window, does it appear at the screen origin, at the window's old position, or somewhere unrelated?

On the flickering after Claude Code or Codex CLI starts, and not at a bare shell prompt: both of those repaint a full-screen TUI continuously, so my working guess is that the preedit is being torn down and rebuilt on each repaint. If you can, whether the flicker follows the cursor or stays in one place would help confirm or kill that.

No urgency on any of this — the issue stays open either way, and the report is already better than most.

[cxiaoxiong]

Thanks. I updated to the latest VMark release and tested again.

My environment variables are:

GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
session=wayland
desktop=ubuntu:GNOME

The Enter-key issue is still reproducible in VMark's integrated terminal with Fcitx5 + Rime (Xiaohe Shuangpin).

When Rime is in Chinese mode, if I type raw Latin letters such as claude or pinyin text and press Enter, nothing happens. I have to switch the input method to English mode first before Enter works normally.

This happens at the normal Bash prompt in VMark's integrated terminal, and also inside Claude Code and Codex CLI.

VMark's normal Markdown editor does not have this problem.

I have attached the requested fcitx5-diagnose.txt.

[cxiaoxiong]

@xiaolai Thanks. I updated to the latest VMark release and tested again.

My environment variables are:

GTK_IM_MODULE=fcitx
QT_IM_MODULE=fcitx
XMODIFIERS=@im=fcitx
session=wayland
desktop=ubuntu:GNOME

I also generated and attached the requested fcitx5-diagnose.txt.

The issues are still reproducible:

1. Enter cannot commit raw Latin/pinyin text in Chinese IME mode

When Fcitx5/Rime (Xiaohe Shuangpin) is in Chinese mode, if I type raw Latin letters such as claude or pinyin text and press Enter, nothing happens.

I have to switch the input method to English mode first, then Enter works normally.

This happens:

• at the normal Bash prompt in VMark's integrated terminal
• inside Claude Code
• inside Codex CLI

VMark's normal Markdown editor does not have this problem.

2. IME flickering still occurs inside Claude Code and Codex CLI

At the normal Bash prompt in VMark's integrated terminal, Chinese input does not flicker.

However, after starting Claude Code or Codex CLI, the Chinese IME composition/input area visibly flickers while typing.

The flicker appears during composition and is still reproducible after updating VMark.

3. The IME candidate/preedit window is still initially misplaced

When I first start typing Chinese inside Claude Code or Codex CLI, the Fcitx5/Rime candidate/preedit window may appear in a corner of the VMark window instead of near the terminal caret.

After resizing, maximizing, or dragging the VMark window once, the candidate window snaps back to the correct position near the caret.

Additional answers to your questions:

1. The Enter problem does not happen in VMark's normal Markdown editor; it only happens in the integrated terminal.
2. The same Enter issue does not occur in the Ubuntu system terminal with the same Fcitx5/Rime setup.
3. The misplaced candidate window appears near a corner of the VMark window, and resizing or dragging the window makes it return to the caret position.

The flicker also seems to stay associated with the Claude Code / Codex CLI input area rather than the bare Bash prompt.

[xiaolai]

Thanks — your answers narrowed this down, and the Enter problem had a real cause, now fixed.

One thing first: fcitx5-diagnose.txt didn't come through. Neither comment has a file attached — GitHub only attaches it if the upload finishes before you post. It's no longer blocking, but still welcome.

Enter not committing raw Latin text — fixed in v0.9.73 (#1404)

With fcitx5, VMark's terminal is never told that a composition has started — each commit arrives only as a "composition ended" event carrying the text. The terminal kept that text when it was Chinese but threw it away when it was plain Latin letters, on the assumption that it couldn't be real input. On your setup that is the only way a commit arrives, so when Rime's Enter committed claude or raw pinyin, the text went nowhere while Chinese got through. That is also why the Markdown editor and the Ubuntu terminal were fine: neither goes through this code.

The fix keeps that text, and still skips anything the terminal already typed itself, so nothing appears twice. I can't run Wayland with fcitx5 here, so please tell me whether Enter works for you on v0.9.73.

Flicker and the misplaced candidate window — not fixed yet

I don't want to guess at these. fcitx5 documents a Wayland limitation that fits both: its GTK module draws the candidate window inside the application, GTK3 can't move that kind of window once it's shown, so fcitx5 hides and re-shows it to move it, which "may cause window blinking" (Using Fcitx 5 on Wayland). Claude Code and Codex redraw constantly and move the terminal cursor as they do; a bare Bash prompt barely moves it. That matches what you see, but it's an inference, not a reproduction.

One experiment would settle it. Launch VMark from a terminal the same way you did before, but put GDK_BACKEND=x11 in front of the command. That runs VMark through XWayland, where fcitx5 places its window differently. Then open Claude Code and type Chinese:

• If the flicker and the misplaced window are gone, the cause is that Wayland limitation, and the likely fix is for VMark to update the cursor position less often while those programs redraw.
• If they're still there, the cause is inside VMark's terminal, and I'll look there instead.

This issue stays open for those two.