Repository navigation
Underline not rendered after some SGR 22/39/49 #3076
Description
Environment
Windows build number: Win32NT 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0
Steps to reproduce
echo -e '\e[4m underlined \e[33m yellow \e[39m should still be underlined \e[m'
Expected behavior
The entire line should be underlined.
Actual behavior
The "should still be underlined" bits aren't underlined.
Note that SGR codes 22, 27, 39 and 49 seem to cause this effect, but only if they're predeced by a 1, 7, 30-37 or 40-47, resp., that is, only if they do actually turn off some other attribute.
Also note that if the "should still be underlined" text is made longer so that it overflows to the next line (or even multiple new lines), it's underlined in the last one of these lines. This makes it perhaps a reincarnation of #47.
Furthermore, changing the window width and thus causing a reflow of the text removes the underlining from the last line.
Activity
DHowett-MSFT commentedon Oct 6, 2019
Investigation yields that the attributes are read & stored correctly; next step is looking at VtEngine (ConPTY out).
DHowett-MSFT commentedon Oct 6, 2019
VtEngine::_RgbUpdateDrawingBrushesdoesn't factor in any attributes other than bold & color (actual RGB value) when it decides to emit\e[m. This is something that'll probably be addressed by #2661, which suggests that we should defer converting attributes into RGB values (and other unpacked flags) as late as possible.DHowett-MSFT commentedon Oct 6, 2019
I'm keeping this one open as a linked workitem. Thanks for finding this, Egmont Koblinger (@egmontkob)!
aeiplatform commentedon Oct 6, 2019
Since
echo -eis not POSIX compliant, you should rather combineprintfandtputfor text formatting.In POSIX
echoacts likeecho -eby default but not in bash, because of arguments expansion.I guess this command for my current bash works as expected.
(GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu)).
In POSIX this would be equivalent for yours example:
printf "%s underline %s yellow %s should still be underlined %s\n" "$(tput smul)" "$(tput setaf 3)" "$(tput setaf 7)" "$(tput sgr0)"egmontkob commentedon Oct 6, 2019
Re
echo -evs.printf: I know, usingecho -eis a bad habit of mine, I know I should useprintf. :)I disagree with
tput, though (andechovsprintfdoesn't really matter either). I'm not writing portable software here, I'm writing a reproducer test case for a bug in the terminal emulator.Using
tputinstead of raw escape sequence introduces a level of indirection, makes the behavior depend on$TERMas well as potentially the terminfo version where my intent is not to, and is IMO harder to read. The terminal emulator cares about numbers like 37 or 39, and not terminfo capabilities such assetaf.Also, by far not all escape sequences can be generated by
tput, let alone deliberately broken ones, which some of my other bugreports are about.E.g. there's no terminfo capability I'm aware of that would generate
\e[39mthat my example uses. You mistakenly changed that to\e[37m, or, well, itstputequivalent, modifying the test case, which could be the reason for you not hitting the bug.DHowett-MSFT commentedon Feb 21, 2020
Lol- I just hit this myself, forgot we had a bug on it and re-investigated it.
Apparently what I said months ago is still true. Weird how that works.
Improve the propagation of color attributes over ConPTY (#6506)