GNOME Bugzilla – Bug 755668
Preedit text not shown near right margin
Last modified: 2015-10-02 18:03:50 UTC
Go to close to the right margin, and enter Ctrl+Shift+U followed by some digits. As the preedit string would overflow beyond the right side of the terminal, it actually begins to scroll to the left; however, the beginning is cropped off. Looks to me that vte_terminal_paint_im_preedit_string() properly moves the entire preedit string to the left; it's vte_terminal_draw() that sets a too small clipping region. Which, in turn, is the responsibility of vte_terminal_im_preedit_changed() not properly invalidating. Indeed, it calls _vte_invalidate_cursor_once() which expands the invalidated area by preedit_width to the right, but never to the left.
Created attachment 312252 [details] [review] Fix How to have a "preedit cursor" to test the behavior? Adding one more cell for that seems silly to me; vte_terminal_paint_im_preedit_string() doesn't draw an additional cursor, just perhaps paints one of the preedit cells in reverse.
You can test preedit cursor by using CJK input in ibus (e.g. japanese).
With this patch the behavior (incl. CJK) is not any worse than before, yay! :) The "one more for the preedit cursor" comment is apparently a leftover from bug 418588, so it's okay to remove. With Ctrl+Shift+unicode the preedit cursor is always at the end of the string, hence it's never painted. With CJK, the preedit cursor can be moved backwards, and in that case the corresponding character is painted in inverse (regardless of the terminal's cursor shape). This situation might not be ideal; I guess it'd be better if we painted the terminal's cursor in both cases. Anyway, that's a different story.
Committed.