Font color in some contexts might be indistinguishable from terminal foreground color

[0xd34df00d]

I noticed this when running tests and benchmarks of bytestring, which uses tasty (and tasty-bench). Compare vs

So far this looks like a tasty's issue, as I don't think I ever noticed anything that might hint it's a color scheme issue.

[UnkindPartition]

It is a real issue, but one that's not specific to tasty. There's no way (that I'm aware of) to query the terminal color scheme, so if you use any custom colors at all, there is a chance that the colors you choose will coincide with the user's background color.

For instance, here I changed my background color to make the USER column disappear in htop:

So while I don't think we could avoid this problem automatically, we could expose an option (that you could set via an environment variable in your ~/.profile) to customize the color scheme of tasty to match that of your terminal. What do you think?

Also, as a workaround, you can disable colors with --color=never.

[UnkindPartition]

Actually, there is a way to query for background: https://stackoverflow.com/a/7767891/110081. But it's not supported by ansi-terminal yet.

So what would be needed is:

• add this query to ansi-terminal
• figure out a way to adjust the color scheme automatically based on the background color to maximize readability and implement it in tasty

[0xd34df00d]

Didn't know about the approach with the escape sequence! What I had in mind is COLORFGBG, which is more limited, but I have a vague recollection that it's quite widely available. Probably the right approach is to implement both, starting with the escape sequence and falling back to COLORFGBG if it fails.

I'd be happy to hack on this.

[Bodigrim]

@0xd34df00d a query background color was added in ansi-terminal-0.11.4 as getLayerColor.

[bfrk]

Instead of trying to be (too) clever and adapt the color scheme depending on the terminal's background color, why not simply make the color scheme configurable by the user? My preferred way would be via environment variables, something like TASTY_COLOR_DETAILS, TASTY_COLOR_OK, etc.

[Bodigrim]

I'd gladly take a PR based on getLayerColor. Not positive about environment variables, likely too much hassle to parse, document and fail gracefully.

[bfrk]

I have made a PR in order to show that customization via environment variables is a viable solution.

• Parse: simple, uses the Read instance for the three ConsoleFormat ingredients (I would have used a derived instance Read ConsoleFormat, but that is a record type -> too verbose)
• Document: see haddocks for getFormat
• Fail gracefully: my approach is to fall back to the standard format if the corresponding environment variable does not exist or has a bad format. This is for Haskell developers, who can be expected to look up the constructor names in the docs for ansi-terminal.

[Bodigrim]

Sorry @brfk, but I'm really not positive about environment variables. The issue does not quite justify an additional piece of configuration, not that many people ever complained about it. If a user is unhappy with the choice of colors, they can simply pass --color never.

If someone wishes to improve status quo by taking default foreground color, replacing Dull with Vivid and using the result for reporting, - that's simple enough from my perspective to be merged.