[Feature Request] Undercurl text decorations

[Claudia Hardman]

Having compiled vim to support 24-bit truecolor escape sequences (https://bitbucket.org/ZyX_I/vim), one thing I am missing in themes the &guicolors option now enables is undercurl support. An example of this is from the Molokai theme by Tomas Restrepo:

if has("spell")
  hi SpellBad    guisp=#FF0000 gui=undercurl
  hi SpellCap    guisp=#7070F0 gui=undercurl
  hi SpellLocal  guisp=#70F0F0 gui=undercurl
  hi SpellRare   guisp=#FFFFFF gui=undercurl
endif

Because this feature requires both KS_UCE and KS_UCS (t_Ce and t_Cs respectively to end and begin undercurl), this would likely need to be patched into ZyX's branch of Vim to support these options to be set in non-gui modes, as it only seems to be defined inside #if defined(FEAT_GUI).

If this is enabled for hterm, there would need to be relevant escape codes supported inside the terminal to set the following CSS attributes:

text-decoration-line:  underline;
text-decoration-style: wavy;
text-decoration-color: (value of guisp);

I've been able to enable something close to this effect by using vt_tiledata with user-css rule:

.tile_1 {
  text-decoration-line: underline;
  text-decoration-style: wavy;
  text-decoration-color: #FF0000;
}

and passing escape sequences to wrap text in the tile_1 span tags as demonstrated in the screenshot attached.

[Robert Ginda]

That's pretty cool.  I didn't even know 'text-decoration-style: wavy' was a thing.  I'm a little wary of adding these "ESC |" sequences though.  Am I right that they're only used in a branch of vim, and only when compiled with some kind of GUI?  What's FEAT_GUI exactly?

You could probably hack this with a combination of vt_tiledata and underline.  Set .tile_1 to only { text-decoration-style: wavy; }.  Then send both the SGR for underline (ESC [ 4 m) and the tiledata escape.  You'll get the underline and underline color from the SGR, and the tile_1 class will make it wavy.  The underline color would be the same as the text though, and maybe that's missing the point.

Rob.

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/9e6f95f2-0c69-4cfa-90d3-39a9abf128fa%40chromium.org.

[Claudia Hardman]

As far as I can tell, the ESC | sequences are specific to GUI, the rest of this file defines escape sequences with the usual ESC [ or ]. An example of this is taken from the truecolor patch for vim:

# ifdef FEAT_TERMTRUECOLOR$
     {(int)KS_8F,•       IF_EB("\033[38;2;%lu;%lu;%lum", ESC_STR "[38;2;%lu;%lu;%lum")},$
     {(int)KS_8B,•       IF_EB("\033[48;2;%lu;%lu;%lum", ESC_STR "[48;2;%lu;%lu;%lum")},$
 # endif$

There doesn't seem to exist a real Unix terminal compatible escape sequence for undercurl, vim just has it's own special definitions in place for the GUI.

FEAT_GUI is I believe what returns true when Vim is compiled with --enable-gui flag, or when the gui variant, gvim, is actually what is running (I'm not a real programmer). For the case of terminal-bound vim, this would not be true, hence the need for Vim to be patched. I have written a response to the 24-bit truecolor support thread in the vim Group to prompt discussion on this.

You are right in that this can be acheived with vt_tiledata, but as you mention also the point is to ideally have also the text-decoration-color come through as well. I wouldn't consider this a critical feature, merely a "Nice to Have" where one could kick out (for example) "\033[8;#FF0000;C sometext \033[8;c", and you get a red undercurl below " sometext " as if it were spelled wrong. Even if Vim is patched to expose &t_Cs and &t_Ce but default to an underline that is supported in any terminal, the definitions could be changed in your vimrc to set your own escape sequence.

Alternatively, if we had a way to get text-decoration-color, I could just as easily string vt_tiledata, underline, and theoretical underline color sequences all together for the same effect.

[Claudia Hardman]

Also of note, I might have discovered a defect with vt_tiledata. When resizing my terminal, resizing my tmux panes, or even just pushing the buffer back in tmux with Ctrl+L and scrolling up to see it again, the span tags around the text are just gone, so the red curly underline in my example screenshot goes away.

[Robert Ginda]

On Fri, Feb 13, 2015 at 2:38 PM, Claudia Hardman <cjh...@gmail.com> wrote:

As far as I can tell, the ESC | sequences are specific to GUI, the rest of this file defines escape sequences with the usual ESC [ or ]. An example of this is taken from the truecolor patch for vim:

# ifdef FEAT_TERMTRUECOLOR$
     {(int)KS_8F,•       IF_EB("\033[38;2;%lu;%lu;%lum", ESC_STR "[38;2;%lu;%lu;%lum")},$
     {(int)KS_8B,•       IF_EB("\033[48;2;%lu;%lu;%lum", ESC_STR "[48;2;%lu;%lu;%lum")},$
 # endif$

There doesn't seem to exist a real Unix terminal compatible escape sequence for undercurl, vim just has it's own special definitions in place for the GUI.

FEAT_GUI is I believe what returns true when Vim is compiled with --enable-gui flag, or when the gui variant, gvim, is actually what is running (I'm not a real programmer). For the case of terminal-bound vim, this would not be true, hence the need for Vim to be patched. I have written a response to the 24-bit truecolor support thread in the vim Group to prompt discussion on this.

You are right in that this can be acheived with vt_tiledata, but as you mention also the point is to ideally have also the text-decoration-color come through as well. I wouldn't consider this a critical feature, merely a "Nice to Have" where one could kick out (for example) "\033[8;#FF0000;C sometext \033[8;c", and you get a red undercurl below " sometext " as if it were spelled wrong. Even if Vim is patched to expose &t_Cs and &t_Ce but default to an underline that is supported in any terminal, the definitions could be changed in your vimrc to set your own escape sequence.

Alternatively, if we had a way to get text-decoration-color, I could just as easily string vt_tiledata, underline, and theoretical underline color sequences all together for the same effect.

You could use a different tile for each wavy underline color, I guess.

I think extending the true color sequences might be the best approach.

	* For true color (24-bit) support, the following apply.
	* 38 ; 2 ; R ; G ; B Set foreground color to rgb(R, G, B)
	* 48 ; 2 ; R ; G ; B Set background color to rgb(R, G, B)

 

Hterm could treat "ESC [ 58 ; 2 ; R ; G ; B m" as text-decoration color changes.

Realistically, I'm probably not going to get to this soon.  I'd accept a patch though.  There are a number of commits that do similar things in hterm_vt.js history if you or anyone else is interested in having a shot at it.  In particular, have a look at the 24-bit color change, vt_tiledata change, and italics via CSI.

Rob.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/44fa418b-46e0-421e-80ac-7237d88e4715%40chromium.org.

[Claudia Hardman]

I will have a look through the code and change history and see what I can grok. I'm just a lowly QA tester, but I'd like to try :)

[egm...@gmail.com]

Hi,

Not sure how relevant it is after almost 3 years. I came across this thread using a Google search, and thought you might be interested:

Recently the Kitty terminal emulator has added support for undercurl as well as colored underline/undercurl, and VTE (the terminal emulator widget behind GNOME Terminal, Terminator, Tilix and quite a few more) also followed. I've also filed feature requests for iTerm2 and Konsole.

Apparently vim and neovim have already / are about to support these, see e.g. vim undercurl, vim color, neovim.

Undercurl:

The new SGR 4:3 (\e[4:3m) attribute, strictly with a colon as separator, was introduced to start a curly underline.

In the mean time, 4:0, 4:1 and 4:2 were also added as aliases for the standard 24 (turn off all kinds of underlining), 4 (single underline) and 21 (double underline), respectively.

At some point in the future, probably 4:4 and 4:5 could also stand for dotted and dashed underlines in some order (these are the five types of underlining supported by HTML/CSS).

Colors:

Tthe new SGR 58 (just as you proposed in this thread) and 59 sequences specify the color of the underline, following the pattern of 38 and 39. That is, 58;5;idx for an entry of the 256-color palette, or 58;2;r;g;b for direct RGB. There's no shortcut notation for the first 16 entries (corresponding to SGR 30-37 and 90-97), use the 256-color mode with indices of 0-15 instead.

59 reverts to the default, that is, the underline's color auto-following the text color.

In case you're short of bits, I believe it's okay to drop some precision, e.g. store only 4 bits per color channel. We were also considering this in the VTE bug.


Cheers,
egmont

[Mike Frysinger]

if other emulators have picked it up (like VTE), then adding it to hterm sounds fine

this should be a lot easier to do since i added support for subparams in https://chromium-review.googlesource.com/782465 ... i was kind of annoyed by that change originally, but it looks better in this light ;)

i've filed this request in https://crbug.com/794130 so it won't get lost

-mike

--

You received this message because you are subscribed to the Google Groups "chromium-hterm" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/d98242e9-6dfc-41d0-a981-d70b262160b7%40chromium.org.

[Mike Frysinger]

not directly related, but since it was mentioned somewhere along the way, i posted this to fix ISO 8613-6 handling in hterm.  i opted to:

- support 38;5;P (for xterm/legacy) and 38:5:P

- support 38;2;R;G;B and 38:2:R:G:B (for xterm/legacy) and 38:2:[...]:R:G:B[:...]

- drop support for 38;5:P and 38;2:R:G:B (for the same reasons outlined in the vte bug)

- for 38:0/38:1/38:3:.../38:4:..., i'm only going to support the ISO 8613-6 forms since no one seems to currently support them, and might as well start on the right foot

https://chromium-review.googlesource.com/828084

thanks for the heads up

-mike

On Tue, Dec 12, 2017 at 5:25 AM, <egm...@gmail.com> wrote:

--