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 707221 - Underlines the wrong characters
Underlines the wrong characters
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.34.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
[needed-next][commit:75b06e0b5fff57e8...
Depends on:
Blocks:
 
 
Reported: 2013-09-01 12:32 UTC by Egmont Koblinger
Modified: 2014-04-16 17:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix (759 bytes, patch)
2013-09-01 13:07 UTC, Egmont Koblinger
committed Details | Review

Description Egmont Koblinger 2013-09-01 12:32:58 UTC
In presence of line drawing characters and underlines, the wrong characters are underlined. Probably vte intentionally tries to skip line drawing characters, but somewhere makes a mistake.

Simple example (in UTF-8 terminal):
echo $'\e[4mabc\342\224\214def\e[0m' # that's a U+250C
Expected output: abc┌def completely underlined.
Actual output: abc┌de underlined, followed by a non-underlined f.

More complex example:
Take a recent enough Midnight Commander, copy its default skin to ~/.local/share/mc/skins/default.ini and modify it to have almost the whole screen underlined:
[core]
_default_=lightgray;blue;underline
Start mc and notice how the rightmost columns are not underlined. Also notice that the exact characters which are underlined change a little when you cover and then expose vte's window, without changing the terminal's contents. Take a look at the bottom of the blue panel too where underlining the box characters is inconsistent.
Comment 1 Egmont Koblinger 2013-09-01 13:07:04 UTC
Created attachment 253751 [details] [review]
fix

This patch seems to fix the bug (at least it fixes both test cases above).

Once such a special line/box drawing character is enountered which needs special treatment, it doesn't make sense to continue the sequence of characters with identical attributes, so we should rather break that loop and handle the chars with identical attributes that we've seen so far.

Once that's done, the loop is started over and the line/box character is handled correctly (approx 50 lines above the stuff I removed there's another copy of the same code and its does what needs to be done).
Comment 2 Egmont Koblinger 2013-09-01 13:18:40 UTC
(Note that my patch still leaves these special characters non-underlined. According to the comment in the source, these characters get special treatment so that they are drawn even if are missing from the font. This kind of suggests that omitting underlines is not the desired behavior - right?)
Comment 3 Behdad Esfahbod 2013-09-03 20:38:27 UTC
ChPe, can you take a look into this?
Comment 4 Christian Persch 2013-09-16 20:57:43 UTC
Patch looks ok to me; committed to 0-34.

As for the attributes on graphic characters, I simply forgot about them when writing that code; they should get the attributes that make sense (so all except bold and italic, I think).
Comment 5 Egmont Koblinger 2014-04-16 17:38:32 UTC
Continued in bug 708195.