inconsistent text styling

[icy-comet]

I just put together a test file according to tcell's getting started guide for 4 text styles — italic, bold, blink and dim. And I found some inconsistencies in the outcomes.

Here are the results:

• Windows + Windows Terminal + Powershell - only the blink style works
  
• Windows + Conhost + cmd - blink and bold styles work
  
• WSL2 + Windows Terminal + bash - bold style doesn't work
  
• WSL2 + Conhost + bash - all styles work
  

Here's the gist I used for testing:
https://gist.github.com/icy-comet/76cc7fdbb77f272c5653e533ddebdb63

[gdamore]

Yep. The problem is that the underlying terminals are not consistent in what they implement. This happens elsewhere too. There isn't really much I can do about it sadly.

[icy-comet]

The problem is that the underlying terminals are not consistent in what they implement.

I am not sure if it's the terminal emulator at fault. Could it be related to the shell? @gdamore

oh-my-posh seems to handle some inconsistencies according to the shell it's running on. I mention it cause all the four styles work fine with Oh My Posh on my machine.

[tvarney]

The shell is not responsible for rendering styles, the terminal emulator is (with some minor caveats on Windows, that is). The snippet linked from oh-my-posh is handling how the different shells evaluate the prompt escapes for non-printing characters, specifically that bash uses \\[ and \\], while zsh uses %%{ and %%}. That's important for the prompt because the shell counts the rendered characters to determine where the prompt ends; mess that up, and you get weird behavior such as being able to delete bits of your prompt or the shell refusing to go all the way back to the end of the prompt. The actual escape codes are the same in the entire snippet (e.g. reset is \x1b[0m and bold is \x1b[1m in all three cases of the switch statement). These extra escapes are meaningful only in the prompt for these shells, and would be printed literally by any other program.

The reason why things 'just work' in oh-my-posh is that it assumes all of the extended ANSI escape codes are present and work. This actually works mostly fine in modern terminal emulators, since most have agreed to support a pretty good set of ANSI escapes, and windows conhost does as well (assuming it's enabled). Where these terminal emulators don't support an ANSI escape, they ignore it.

When running bash (and linux shells in general), either in WSL or natively on linux, the TERM environment variable is going to be what determines the capabilities that Tcell uses. Generally speaking, this will be a pretty capable terminal by default (e.g. a fresh ubuntu install on WSL uses xterm-256color, you can check by running echo $TERM, or change it by doing something like export TERM="xterm-direct"). This advertises to Tcell that it should use that terminal profile, which can be found here. However, the actual rendering of the text is going to be dependent on the emulator. Some of the differences you see come down to the difference between Windows Terminal and Conhost. Conhost programs generally have very little in the way of customization of the rendering available. That's not the case on Windows Terminal, which provides a lot of customization; you may actually have properly rendering bold style but can't tell because of how Windows Terminal renders it by default. You can change that by right clicking on the title bar of Windows Terminal, going to settings, then selecting the WSL distro you're running (e.g. ubuntu). Then, under "Appearance", scroll down to "Text Formatting" and change the "Intense text style". The default seems to be to use a brighter color, which for the default color scheme seems to be nearly the same as the regular default color. Switching to "Bold font with bright colors" makes the difference a bit easier to tell in my opinion, or you could switch up the terminal color scheme so the regular white and bright white fonts are more distinct.

The differences on conhost are interesting, but I'm pretty sure it boils down to the fact that on Windows things using conhost have to enable ANSI colors and styles, otherwise you get the old behavior prior to windows 10. Software that doesn't do this will behave differently than software that does, and you're at the mercy of whatever the program that created the console chose to do with it.

One thing to check would be if you are getting a cScreen or a tScreen - the lack of italics for instance happens when you get a cScreen. Powershell isn't available as a terminfo entry, so I'm pretty sure any time you use powershell you get a cScreen.

Ran across this because I was having difficulties with colors, but it turned out to be unrelated.

[gdamore]

I'm closing this, because it's really out of my control.