Added: Show IME composing text (e.g. Hangul) preview on terminal - #5215
Added: Show IME composing text (e.g. Hangul) preview on terminal#5215sng2c wants to merge 1 commit into
Conversation
…n-composing keys The terminal only renders text that is committed and echoed back by the program in the pty, so in-progress IME composition (e.g. ㄱ → 가 → 간) was not visible until commit, and the preview followed the cursor when a non-composing key (arrows/ESC/Tab from extra-keys or hardware keyboard) was pressed mid-composition. - Override InputConnection.setComposingText() to capture the composing text and draw it as a preview overlay at the cursor via a new TerminalRenderer.renderComposingText(), reusing the same mTextPaint and drawTextRun path as normal rendering (same font family/fallback, width scaling and cell text style: bold/italic/colors/dim). - Finalize composing on non-modifier keys in onKeyDown(): write the composing code points to the pty directly, clear the local Editable, and reset the IME via invalidateInput (API 33+) / restartInput so it drops its composing buffer (avoids duplication on the next input).
|
I tested all of CJKV. :-) It works!! https://github.com/user-attachments/assets/0210e7b8-5797-44ca-89ae-7045b31a8119 https://github.com/user-attachments/assets/8688dedb-18a2-462c-bbda-9889bf75ea2b https://github.com/user-attachments/assets/ff7c51b2-00f0-48e5-bdcb-61b798701cf2 |
|
I looked for common issues with CJK IME implementations in other terminal emulators on desktop PC, in order to try to understand what it should look like ideally. Here is a discussion I found comparing the implementations of ghostty and GNOME terminal. They said that in ghostty, there is a problem that the cursor is not visible or movable during the preview, but in GNOME terminal that problem does not happen. Could you check that thread and compare this PR to it, and let me know whether this makes Termux more like GNOME terminal, or more like ghostty? |
So this is about a special case: cursor movement within the IME composing buffer. Thank you — that's a case I hadn't considered. If anything, I was hoping for a result closer to GNOME Terminal. However, this PR forces a commit whenever an arrow key is pressed, so even if the virtual keyboard supports moving inside the buffer, the composition could end I think I need to revisit this and work toward a more fundamental implementation. Also, regarding IME input from a physical keyboard: it seems hardware input needs to be routed through the IME as well, so that should probably be handled separately. I think it's best to withdraw this PR. Shall I improve it and submit it again? |
|
I think I need to revisit this and work toward a more fundamental implementation. :-) |




Hello Termux maintainers,
Thank you for your continued work on this project. I'd like to kindly submit this contribution for your review.
Problem
When using an IME (e.g. Korean/Hangul input), the in-progress composition (e.g. ㄱ → 가 → 간) was invisible in the terminal until committed, because the terminal only renders text echoed back from the pty. Additionally,
pressing non-composing keys (arrows, ESC, Tab from extra-keys or hardware keyboard) mid-composition caused the preview to follow the cursor unexpectedly.
Solution
drawTextRun path (consistent font, width scaling, bold/italic/colors/dim).
duplication on the next input.
Changed files
Although this was developed and tested primarily with Korean (Hangul) input, the implementation relies on the standard Android InputConnection composing text API, which is shared across all CJK IMEs (Chinese, Japanese,
Korean). I believe this should work correctly for Chinese and Japanese input methods as well.
I would greatly appreciate your feedback and any suggestions for improvement. Please feel free to request changes if anything does not align with the project's conventions.
Thank you for your time and consideration.