Support different kinds of underline rendering

[sudormrfbin]

Adds four new modifiers that can be used in themes:

• undercurled
• underdashed
• underdotted
• double-underline

TODO

• Specify color for the underline (currently automatically inherits the style of the cell).

[A-Walrus]

Wrote a PR to add color to the underlines: PR

[archseer]

Wrote a PR to add color to the underlines: PR

Looks great! I wanted support for that too :)

[sudormrfbin]

Added undercurl support detection based on terminfo. Thanks to @A-Walrus for the color customization code :)

[the-mikedavis]

This is really sweet 😀

I took it for a spin and I found some odd behavior when using move_char_left over a diagnostic: https://asciinema.org/a/QwKpcsg1IXFj84JTcvjqBWWxc

The asciicast doesn't really show it very well but I have diagnostic.error set to

"diagnostic.error" = { underline = "red1", modifiers = ["undercurled"] }

I also have the ui.cursor.primary set to underline too

"ui.cursor.primary" = { bg = "bg3", modifiers = ["underlined"] }

Moving right across the diagnostic doesn't do anything interesting but moving left seems to un-underline the parts of the diagnostic that the primary cursor was on.

So I think there might be some conflict with the intersect or resetting behavior?

[sudormrfbin]

This only seems to affect them when the underlines are different, for example when both the error and cursor modifiers are undercurl, there is no glitch. Also the glitching behavior is also slightly different for me; putting the cursor in the middle of the error underlined word cuts off the rest of the word underline rather than removing the underline only on pressing the left key:

The modifiers used (the cursor is undercurled instead of the error):

"diagnostic.error" = { underline = "red", modifiers = ["underlined"] }
"ui.cursor.primary" = { fg = "white", modifiers = ["reversed", "undercurled"] }

[archseer]

There seems to be no reset call for SetUnderlineColor in this block:

helix/helix-tui/src/backend/crossterm.rs

Lines 119 to 124 in da52d20

	map_error(queue!(
	self.buffer,
	SetForegroundColor(CColor::Reset),
	SetBackgroundColor(CColor::Reset),
	SetAttribute(CAttribute::Reset)
	))

[archseer]

Could it be that we have to emit NoUnderline followed by underline if the cell changes from one underline to a different type in the next one?

[archseer]

I tried this on wezterm: the underline color changes, but it's using the same underline (not undercurl). I did confirm that undercurl works normally via

printf "\x1b[58:2::255:0:0m\x1b[4:1msingle\x1b[4:2mdouble\x1b[4:3mcurly\x1b[4:4mdotted\x1b[4:5mdashed\x1b[0m\n"

[archseer]

has_extended_underlines is false for me. Manually overriding it to always be true works and I don't have the same rendering issue as above

[sudormrfbin]

has_extended_underlines is false for me. Manually overriding it to always be true works and I don't have the same rendering issue as above

Seems like wezterm's terminfo file has to installed separately:

curl https://raw.githubusercontent.com/wez/wezterm/master/termwiz/data/wezterm.terminfo | tic -x -

There's also one more problem at play here even if you have the terminfo file but when it's installed in ~/.terminfo/: tic attempts to install the terminfo entry in /usr/share/terminfo first and if denied permission installs it in ~/.terminfo, so by default the above command will install it in your HOME. But there seems to be a bug with the path added in cxterminfo, adding ~/ instead of ~/.terminfo. It's a separate bug but overlaps with the wezterm issue.

So to check if wezterm works with undercurl:

curl https://raw.githubusercontent.com/wez/wezterm/master/termwiz/data/wezterm.terminfo | tic -x -
export TERM=wezterm
export TERMINFO=~/.terminfo
hx # or cargo run, etc

Fixing the cxterminfo bug should remove the export TERMINFO step, but the terminfo file will still have to be installed for wezterm (unless we also add a version check similar to checking $VTE_VERSION).

[EpocSquadron]

Tested this out and noticed sometimes the way underlines work in wezterm it's going to be clipped (in other words, there's not enough room for the underlines so it looks funky). I brought it up in the wezterm matrix and there may be upcoming fixes to make it look better in more cases, but I think we should include up front in the documentation that font adjustments may be needed with any given terminal emulator for the fancy underlines to look good. For example, wezterm provides a way to increase the line height and adjust the positioning of the underline to be closer to the text. Any combination of that may be enough to resolve the issue.

See matrix discussion in wezterm room for more information: https://matrix.to/#/!PirwUBcuIlTXwNveYz:matrix.org/$muIHcpgbicXxPXLFuxvfXEMmPg-oqmGu0drVRc_UnA4?via=matrix.org&via=kde.org&via=mozilla.org

[sudormrfbin]

Closing in favor of #4061.