some way to disable bold colors?

[oconnor663]

I use the Solarized colorscheme in my terminal, which means that bold colors end up looking like different shades of gray. I'd like to be able to tell Cargo to use non-bold colors, or maybe be able to specify the whole palette in a config somewhere. What would be the best way to do that? I'm new to Rust, but I'm happy to try to write a PR if someone could suggest the way they'd like this to work.

[alexcrichton]

Currently we don't have configuration for this (beyond turning colors off entirely), but I'd be fine adding some options to .cargo/config for this!

[retep998]

I think having a configuration for which colors to use would be very useful.

[beckclib]

@alexcrichton Similar issue here, so I will no open a new one. How would one go about adding these options? Also, would you mind reminding me how to turn colours off entirely.

Thanks!

[alexcrichton]

You should be able to turn colors off entirely with cargo foo --color never, and you could add this by probably changing how MultiShell is constructed/configured in Cargo itself. I'm not exactly sure what we'd want to call all the options here and how we could have them be flexible for future configuration, however.

[beckclib]

Undertood and thanks for the kind response.

[oconnor663]

@beckclib I finally got around to trying this myself, but I'm very new to Rust, so by all means put up your own PR if you like.

[landersson]

+1 for being able to disable bold colours in rustc/cargo output. I like the colouring of messages, but bold text happens to be way less readable in my setup.

[epage]

As of #12578, cargo now has styling in multiple places. #12655 centralizes some of this and adds semantic names to it. #12627 proposes switching from termcolor to anstream which will make the styling API ansi escape codes on all platforms.

Note that cargo's styling has been duplicated into cargo fmt and soon cargo clippy. We'd need to make sure a solution works across these tools.

Related to anstream is anstyle-git and anstyle-ls which parse some user configuration formats into anstyle::Styles.

With all of that said, I don't think styling is worth it. We use basic ANSI styles which puts the user in control already by their theme choice / customization. See also clap-rs/clap#4132

[BurntSushi]

I'm not sure if this is the right place for this comment, but this issue seems related and is still open.

I'm not sure when exactly, but somewhat recently, the help output of Cargo has been using a very light blue color that is extremely difficult to read on a light background. I like colors generally and so would prefer to keep them on, but it'd be nice if Cargo used a color scheme that was friendly to both light and dark backgrounds. (That is, I'm not asking that Cargo become aware of whether a light or dark background is being used.)

Here's a screenshot to show what I mean:

[ChrisDenton]

Arguably this is an issue with your terminal's theme, but they commonly do mess up colours so maybe that's an argument for trying to workaround them.

[epage]

In #12578, we picked colors based off of cargo's current color palette, assuming that if people hadn't complained before that it should be fine (and relying on the RGB values being user-controlled). We also did testing with a variety of themes to avoid problems with this.

Side note: the user-control over colors is why I prefer we stick to the basic colors not use the full 256 colors or RGB

I'm assuming that the current use of Cyan on your terminal is in minor enough spots of cargo that you've tended to overlook it?

Some options

• Scope of problem is small enough that we decide not to address it
• Come up with a replacement color here and elsewhere in cargo (compiler is looking at adding magenta... ;) )
• Switch help only, maybe to a more neutral option like bold

[BurntSushi]

Ah I see. The old --help output didn't show any colors at all:

So yeah, it is definitely possible that in an older version, cyan was used in different ways that didn't bug me as much.

The comment about themes makes sense. FWIW, I'm using Alacritty and I don't believe I touched the theme at all, other than maybe changing the background to be white and the foreground to be black.

I was about to then make an argument about "well if I'm using the default Alacritty colors for a light background, then maybe cyan isn't a great one to pick." But then I tried Alacritty with its default config, and only its background/foreground colors overridden: alacritty --config-file /dev/null -o 'colors.primary.background="0xffffff"' -o 'colors.primary.foreground="0x000000"'. This is what I got:

Which looks quite nice. So... I should change my theme. Sorry for the noise.

[epage]

The comment about themes makes sense. FWIW, I'm using Alacritty and I don't believe I touched the theme at all, other than maybe changing the background to be white and the foreground to be black.

As a light-mode user, ouch. We seem to be in the minority and it takes care to ensure things are readable (some neovim plugins and zellij are my main pain points I've not solved atm)