256-color still in use

[remexre]

38 still left some use of 256-colors for gray; when using tmux on the Linux kernel console, this color gets quantitized to black, so addresses are unreadable

https://github.com/sharkdp/hexyl/blob/master/src/lib.rs#L15-L16=

[sharkdp]

Thank you for reporting this. What do you suggest we do here? There is no 16 bit gray color, right? Is there any way to detect terminals with no support for 8bit colors?

[remexre]

"Light black" is typically treated as gray. I have a patch for this here: https://git.sr.ht/~remexre/hexyl/commit/11488a55b9e5a7c6ba973f142ebc5307b5bb1bae

This seems to work well on my machines; I can PR it if it looks acceptable.

[sharkdp]

That doesn't seem to work for me:

[remexre]

Hm.... it works on my machine, and Wikipedia certainly implies it's common but it's of course a color-scheme-dependent thing -- do you know if your color scheme is a common one?

terminfo support could be added to detect terminals that can use 256-color, if we assume that terminals either support 256-color or are using a theme with a "light black" distinct from the background color? Terminfo support sounds like a pain, though I don't know off-hand what's available for it in Rust (so maybe it's not).

Alternatively, theme support would also probably be sufficient, assuming that the themes can specify either 16-color or 256-color colors. (Heck, they probably ought to support truecolor as well.)

I could take a look at implementing either of these sometime next month, I think.

[sharkdp]

I'd be fine with adding a --color-mode=auto/16/8bit option, where auto would currently simply select 8bit (what we have now) and 16 would be a legacy mode that would not use any 8bit ANSI escape codes. Users could then set an alias hexyl="hexyl --color-mode=16.

True color support can be detected by reading the value of COLORTERM. We do that in several others of my applications. But I'm not sure if hexyl needs that, as we don't specify color themes on our own.