Allow disabling truecolor and use closest "simple" color, even if terminal can support truecolors

[spenserblack]

Yazi 0.3.3 (VERGEN_IDEMPOTENT_OUTPUT 2024-10-31)

I'm starting this as a discussion just in case my request actually is supported, and I'm just missing something.

The default theme looks great in a terminal with a dark theme! But sometimes I use a light theme. I'm assuming that most of yazi's testing has been done on a dark terminal. An easy way to provide better support for light themes is to provide an "escape hatch" for disabling true colors. That way it becomes the terminal theme's job to make sure the 16 colors (black, white, red, etc.) look good, not the application theme's job.

I tried some of the common ways to force disable truecolor, but Yazi is smart enough to know I'm using WezTerm and can show truecolors 🧠

TERM=dumb TRUECOLOR=false COLORTERM=none yazi

I'd ask for this to be a CLI option, if possible. For my personal usage, my preference frequently changes, so it isn't really suitable for a config file, and works better in CLI. A simple way to do this is --truecolor auto|never|always (default: auto)

Edit: I just saw #988, which could help partially resolve my personal issue. But it would force me to exit yazi after switching themes to reload the appropriate colors.

[sxyazi]

This sounds a bit weird - are you referring to the icons? Besides icons, Yazi's default theme does use 16 colors instead of true color to better match terminal colors, you can find the default color scheme at https://github.com/sxyazi/yazi/blob/main/yazi-config/preset/theme.toml

[spenserblack]

Yes, mostly the icons are the problem right now. My problem is that the preset colors look perfect in a dark terminal IMO, but then switching to light it becomes a problem (like EditorConfig becomes white on white). Like I said I think #988 will can resolve this, (or, more accurately, #1644, auto-switching flavors). Sorry, I saw those issues after making this discussion (different solution for same problem, so they didn't come up in my duplicate search). So this isn't much of a priority to me now.

However, I think that a flag like --truecolor=auto|never|always isn't that weird, for the following reasons:

• A user can use a terminal that does support truecolor, but yazi thinks it doesn't. For example, they're either using a new, unknown terminal, or testing a fork that adds support.
• A user is using a terminal that doesn't support truecolor even though yazi thinks it does, or they need to disable it (e.g. vision problems)

For example, colorchoice in your dependency tree offers a choice to specifically enable ANSI colors, but not all colors. I assume this is for similar reasons that I described.

--color=auto|always|never is pretty common (ls, diff, grep), and colorchoice in your dependency tree implements a choice like this. So the weird part might be that I'm asking specifically for --truecolor, not --color. But it provides a quick and easy escape-hatch to improve compatibility without having to change your configured theme.

But, regardless, I just dug through crossterm and I saw that, that there isn't an option to specifically disable non-ANSI colors while keeping others. There is a way to disable/enable all colors, so yazi could theoretically support --color=always|auto|never. But I've also discovered that crossterm respects the NO_COLOR environment variable (NO_COLOR=true yazi), which is good enough for my usage when colors look bad. So I'm going to close since this request as it is is pretty much impossible with crossterm, and existing support is close enough.

[spenserblack]

Ouch, shortly after posting this I realized that NO_COLOR=true messes with how yazi highlights the currently selected file/folder. It's inconsistent, and the same item can be highlighted or not depending on whether you cycle up or down (I'm guessing a misplaced "reset" somewhere). TBH you might want to force-enable ANSI colors always (i.e. not respect NO_COLOR=true), since when they're automatically disabled by crossterm it breaks yazi's rendering. I can file a bug report with more details if you want.