After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 755668 - Preedit text not shown near right margin
Preedit text not shown near right margin
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-09-26 15:17 UTC by Egmont Koblinger
Modified: 2015-10-02 18:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix (534 bytes, patch)
2015-09-27 22:27 UTC, Egmont Koblinger
none Details | Review

Description Egmont Koblinger 2015-09-26 15:17:18 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.
Comment 1 Egmont Koblinger 2015-09-27 22:27:58 UTC
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.
Comment 2 Christian Persch 2015-09-28 19:01:35 UTC
You can test preedit cursor by using CJK input in ibus (e.g. japanese).
Comment 3 Egmont Koblinger 2015-10-02 17:29:44 UTC
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.
Comment 4 Egmont Koblinger 2015-10-02 18:03:50 UTC
Committed.