I'd like to contribute a fix that wraps the Japanese IME preedit at the right edge

[akiya3]

When I type with a Japanese IME, the uncommitted text (the preedit) does not wrap at the right edge, and its leading characters stop being displayed. For example, if I reach the right edge while typing 「あいうえお」, 「あいう」 disappears and only 「えお」 is shown, pushed against the right edge. The same happens when I start typing at the left edge instead of mid-row: once the preedit is longer than one row, characters disappear from the left one after another, while the last character I typed stays visible.

Because of this, while typing or converting, I can't check what I've typed or which part is being converted. The display is fine once the text is committed.

[GIF: typing from the middle of a row]

[GIF: typing from the left edge]

[Screenshot — expected text: にほんごにゅうりょく]

Environment: Orca v1.4.249 / macOS Tahoe 26.3（25D125） / IME: macOS, Google Japanese Input and ATOK

As a Japanese speaker, I would really like to see this improved, so I plan to write a fix that wraps the preedit at the right edge. Because the current display is built into Orca's implementation and tests, I'd like to discuss the approach before I start.

How the current display came about

The following is based on my own investigation.

Hiding the leading part of a preedit that overflows the right edge and showing its tail was introduced in xterm.js by xtermjs/xterm.js#5747. That change limits the preedit's display width to the space from the cursor to the right edge and hides the leading part that overflows.

In Orca, #17170 kept this width limit and replaced the implementation with one that right-aligns the preedit. It also keeps the composition caret, and the anchor used to position the IME candidate window, inside the terminal even when typing in the last column of a row. That PR added a unit test checking that the preedit is right-aligned in the last column. It also added a rendered e2e test checking that, when typing Korean in the last column, the caret and the candidate anchor stay inside the terminal, and the same condition is registered in Orca's reliability gates.

#19367 is a fix that makes the width of preedit characters in Japanese and other CJK text match committed characters. The rendered e2e test added in that PR includes a check that types eight 「あ」 in the last column of a row and verifies that the right edge of the caret and the right edge of the candidate anchor element line up with the terminal's right edge. That check verifies placement at the right edge; it does not verify that the full preedit is visible after wrapping.

Proposed fix

While keeping the caret and the candidate anchor inside the terminal, I'd like to wrap a preedit that overflows the right edge onto the next row, so the full text is visible while typing and converting.

Questions

1. Would you accept a fix along these lines?
2. I believe this fix would require changing the parts of the tests above that check right-edge alignment to match the wrapped display. Would that be acceptable?
3. #23338, which has not been merged yet, draws the preedit directly in the terminal cell grid. According to its description, it also right-aligns the preedit at the right edge, as the current display does. Should I build the fix against the current display, or should it follow feat(terminal): draw the IME preedit in the terminal cell grid #23338's rendering approach?

Related

#22678, which is still open, reports that the composition caret stays at the end of the preedit when the insertion point is moved within it. While the leading part is hidden as it is now, moving the insertion point toward the start may put it out of view, so that issue is also related to this proposal.