{{ message }}
Repository navigation
Words cannot properly type in after using double space + shift to change line in Chinese #3468
Description
Description
When using Chinese input method, I won't be able to type in first word in the new line after using double space + shift.
The first character will be eaten and not shown in the input method.
用两个空格+shift进行换行之后，中文输入法的第一个字母不会正常显示在输入法里。
- Can you reproduce the issue?
Steps to reproduce
- Switch to Chinese input method: Pinyin - Simplified
- Use double space + shift to change to a new line
- type in whaterever words and issue shows
=================
- 使用中文简体输入法
- 用两个空格+shift进行换行
- 输入拼音，第一个字母会被吞掉，输入法中识别不到
Expected behavior:
The input method can properly read what I type.
输入法能正确读取我输入的字母拼音。
Actual behavior:
The first character cannot be read by input method.
第一个字母不能被输入法读取
Link to an example: [optional]
Versions
- MarkText version: 0.17.1
- Operating system: macOS Monterey 12.6 (M1 Pro chip)
Activity
lindeer commentedon Nov 24, 2022
on my arm64 linux machine, input drop down completely not show, maybe the support of input method has some issues?
Jocs commentedon Jun 23, 2026
Thank you for the detailed report. The MarkText editor engine has been fully rewritten since v0.17.1, and this specific issue was explicitly addressed in the new engine.
In the current codebase (
packages/muya/src/block/base/content.ts,lineBreakAutoPairat line 270), there is a dedicated guard that detects when aShift+Entersoft/hard line break was just inserted (blockText.endsWith('\n')) and corrects the cursor offset before the input handler processes the first character of any subsequent IME composition. This prevents the "first character eaten" behavior.If you are still experiencing this on a recent build (0.18.0 or later), please reopen with the current version number and your OS/input method details. Closing as resolved by the engine migration.
fix(muya): keep an IME composition off the block's trailing newline
Jocs commentedon Sep 10, 2026
Reopening: the June closure was based on
lineBreakAutoPair'scompositionendbranch in the new engine, but that branch is unreachable —composeHandlerforwards the rawCompositionEventintoinputHandler, andautoPairgates onisInputEvent('inputType' in event), which everyCompositionEventfails. So the code cited as the fix never ran.The behaviour reported here also still reproduces in the old JS engine, so it was never engine-specific: a block whose text ends with
\nrenders that newline as the last thing in its DOM, the caret sits inside the newline's own text node, and Chromium will not sustain a composition there — it overwrites the newline and abandons the composition, so the input method never receives the keystroke that started the word.Captured from a real composition driven through CDP
Input.imeSetComposition:Fixed in #5281.
fix(muya): keep IME input intact after a soft line break (marktext#5281)