🚀 show an error when specifying true-color in 256-color mode

[raylu]

I set plus-style = "syntax #114433" in my .gitconfig and it worked on my system. I ssh-ed into a container (running an sshd, unusual, yes) using the same config and it output a completely different color

it took me a while of debugging to realize it was outputting in color space 5 (256-color, \33[48;5;237) instead of color space 2 (true-color, \33[48;2;17;68;51)

I came to file a bug report with a pile of screenshots but found #111 which mentioned --24-bit-color (now --true-color) and COLORTERM. there's definitely something broken in my container environment since COLORTERM isn't set, but it would have saved me a bunch of time if delta had just noted my choice of true/24-bit color and refused to continue instead of picking a 256-color

EDIT: turns out COLORTERM just isn't forwarded over ssh and my terminal's terminfo isn't in the most common distribution (ncurses) due to a... disagreement between the maintainers kovidgoyal/kitty#879 (comment)

another option that might be nice is to default true-color to always (cronvel/terminal-kit#139 (comment)) since almost every terminal supports it nowadays, especially the ones that delta is likely to run on

[lugen4ro]

I want to second this.

Was trying out a colorscheme for delta, but I got a totally different look even though everything seemed to be set up correctly.
The reason was that delta auto-downgraded my 24-bit colors into 256-colors because my terminal (Windows Terminal) does not set the COLORTERM environmental variable even though it does support true color.

I found this out because delta --show-config showed different hex-values than what I had in my configuration.

Took me a lot of time debugging this so having some error / warning would be highly appreciated.

My solution was to add true-color = always to my [delta] section in my .gitconfig file as described here.

[th1000s]

I think the default can become true-color / 24bit, with an option to still auto-detect or disable this entirely. Nearly all terminal emulators support it, see https://github.com/termstandard/colors.

@bash, as you have been looking at a lot of terminals recently, what do you think? The url above also mentions a way to querying a terminal, that may be a bonus feature for terminal-colorosorus.

[bash]

I haven't looked at true-color support in particular so I unfortunately don't have much to add on that front. The list of terminals in https://github.com/termstandard/colors looks pretty complete to me though (compared to my color detection survey).

Probably the most important offender in the "not supported" pile is macOS's default Terminal.app, so I'm not sure how great it'd be to enable true-color by default ¹.

Here's what true-colors look like on Terminal.app

Terminal.app:

vs WezTerm:

Adding a warning if a theme uses true-color but the terminal doesn't support it might also be a start as @lugen4ro suggested—but maybe too noisy? For reference this is how bat reports warnings.

Regarding detection: TIL that such a query exists—looks really interesting. I'm generally open to adding something like this to terminal-colorsaurus but there are a few notes that I'd want to consider:

• How widely supported is this query? If it's not widely supported then it might not be worth the extra startup cost.

• I'm a bit unhappy with this part:

  Here we set the background color to RGB(1,2,3) - an unlikely default choice

  1. The detection requires setting the background color—yet another caveat to add to the docs of colorsaurus sigh (I suppose it can be improved upon by sending a reset sequence at the end)
  2. Picking an arbitrary color and hoping its not the default choice seems rather interesting (I know, I know technically it's quite unlikely that we hit the exact color)

[...] due to a... disagreement between the maintainers kovidgoyal/kitty#879 (comment)

sigh—of course

Footnotes

1. Terminal.app does identify itself via TERM_PROGRAM=Apple_Terminal—but that environment variable is not forwarded by SSH & co. by default. ↩