GNOME Bugzilla – Bug 764330
Tab background color problem
Last modified: 2016-05-08 08:35:33 UTC
Found at https://bugzilla.redhat.com/show_bug.cgi?id=1321764 (see screenshots over there): "When ncurses uses a tab to position cursor, vte sometimes (when the tab is past all non-blank characters on the line) clears the space with background color. It's unexpected as the terminfo does not have xt (dest_tabs_magic_smso) property." Simple test case: echo -e '\e[44ma\tb' In xterm, only the letters a and b have blue background in that row, the 7 spaces in between remain of the default background. In vte, all of them become blue.
The linux console, konsole urxvt, st, putty all behave like xterm, so it indeed must be a bug in vte.
Created attachment 324965 [details] [review] Fix I'm wondering if this is the right way to fix it... I guess so.
Not perfect yet, e.g. try this: echo -e '\e[41m\e[K\e[C\e[C\e[42m\e[K\r\e[44ma\tb'
With this latest test case: After the "clear to EOL (\e[K)" is printed in a column other than the leftmost, I believe we come to the state where NUL bytes in the rowdata (and text stream) denote cells that have attributes to remember, yet are kinda unused, not copy-pasted etc. After printing the entire test string and then copying with mouse, currently vte copies "a\tb", although the desired visual behavior is to have some red as well as some green cells between "a" and "b". To achieve this, there are two possible ways to go: 1) Modify the smart tab algorithm not to kick in in this case (when NUL bytes are already there) and get spaces instead (that is, copying will give "a<7spaces>b", or 2) Legitimately allow fragments of a TAB character to have different attributes. I'd say 2 is practically a no-go (would even require changing the stream format, since attr changes are encoded as offsets to the text stream), so let's go for the first: spaces instead of TAB if that portion of the line has already been used.
Created attachment 325042 [details] [review] Fix for comment 3, PoC Tiny proof of concept fix for the second part (the bug discovered in comment 3). If proves to be functionally correct then the code can be cleaned up a bit.
Created attachment 325043 [details] [review] Fix for comment 3, cleaned up version Should be functionally the same as the previous patch, this is the one to be committed.
Fixed on master. (Might later cherry-pick to some older branches, we'll see...)
Ok to cherry-pick to 0-44 if you want, otherwise please close as FIXED.
Cherry-picked to 0-44, closing.