Strange prompt coloring behavior with Solarized Dark colorscheme

[rbjorklin]

There seems to be some strange behaviour with Solarized Dark when comparing
Gnome-Terminal:

and Alacritty:

Switching bright and normal around gives the correct coloring in the prompt but completely breaks the vim colorscheme. Any thoughts on what may be causing this?

Mentioning everyone who touched the Solarized part of: https://github.com/jwilm/alacritty/wiki/Color-schemes#solarized
Ping: @polyzen @heliostatic @svmhdvn @jc00ke @russelldavies @FelipeCortez @jclinton @swansontec

EDIT: Should add that in the example above I'm using the starship prompt.

[chrisduerr]

Mentioning everyone who touched the Solarized part of

Please don't do this. There's no reason why these people should get involved here.

Looking at the URxvt theme (https://github.com/altercation/solarized/blob/master/xresources/solarized#L32-L39), these seem to be accurate though, so I'm not sure what we're supposed to do here?

If you dislike the solarized theme, there should be plenty more to choose from though. Or you can just selectively change it.

[rbjorklin]

Please don't do this. There's no reason why these people should get involved here.

Sorry, I wasn't aware this was bad practice. My thinking was that someone could weigh in regarding their experience with this.

these seem to be accurate though, so I'm not sure what we're supposed to do here?

I'm using the dark theme though so those lines are not really relevant to this issue. But the color codes do seem to be accurate.

If you dislike the solarized theme, there should be plenty more to choose from though. Or you can just selectively change it.

I don't dislike the theme at all. I've been a happy user of it with Gnome-Terminal for years and wanted to try out Alacritty. Switching over I noticed that the colorscheme behaves very differently between the two terminal emulators, is this to be expected?

[kchibisov]

@rbjorklin try setting draw_bold_text_with_bright_colors: false in alacritty.yml

[rbjorklin]

Thanks @kchibisov! That fixed it!

[kchibisov]

@rbjorklin FYI our colorscheme seems identical to urxvt one, solarized just uses shades of gray for bright variants and starship prompt are using bold text for a lot of things.

[rbjorklin]

Thanks for the clarification @kchibisov. I added a note on the color scheme wiki page that users may want to experiment with draw_bold_text_with_bright_colors.

[chrisduerr]

I added a note on the color scheme wiki page that users may want to experiment with draw_bold_text_with_bright_colors.

I strongly disagree with the idea that people should tweak draw_bold_text_with_bright_colors when they don't like their secondary colors.

This option is used to prevent bold text from drawing in your secondary colors, it doesn't stop rendering of secondary colors.

If you dislike the secondary colors of your colorscheme, you should change your colorscheme. That's the only solution that makes sense here.

[rbjorklin]

To me it seems that draw_bold_text_with_bright_colors: false is the most pragmatic solution as changing the secondary colors breaks the color scheme everywhere else.

Does using this option have some drawbacks I'm not aware of since you seem so strongly opposed to it @chrisduerr?

[chrisduerr]

I'm using this option too, however it's mostly unrelated to colorschemes. This is just a terminal functionality difference.

I'm not opposed to the option at all, I'm just opposed to using this option when you think that your bright colors don't look nice.

You should be able to render things in bright without them looking weird, regardless of bold or not, since it's always possible to explicitly specify the bright colors.

This config option is solely to address the conflation of boldness and colors, which is a bit of a historical problem.

[kchibisov]

I strongly disagree with the idea that people should tweak draw_bold_text_with_bright_colors when they don't like their secondary colors.

I also don't like that, but since our colorscheme is the same to urxvt one, I've just suggested a workaround instead of changing existing one in the wiki since it's kind of default solarized scheme.

I added a note on the color scheme wiki page that users may want to experiment with draw_bold_text_with_bright_colors.

I don't think that this tweak should be on the colorscheme section, it's a personal preference in my opinion. It's just happens to be, that in your setup everything was in solarized bright colors, which you don't like.

[rbjorklin]

Alright, thanks for taking the time to explain the situation! If anything it sounds like I should open an issue/PR on starship to allow tweaking the escape codes for $PS1.

[egmontkob]

[rbjorklin] To me it seems that draw_bold_text_with_bright_colors: false is the most pragmatic solution as changing the secondary colors breaks the color scheme everywhere else.

I concur. The Solarized color scheme wants to use 16 different colors with no automatic transitioning from some to some others when it comes to bold. There's absolutely nothing like this mentioned on its homepage, design document. They didn't take into account this (mis)feature of terminals.

In GNOME Terminal / VTE bug 762247 we added this option for the sake of Solarized, and later even made it the default as an attempt of cleaning up the legacy confusion between bright and bold. Now that we support 16 million colors, and still no unambiguous way of requesting bold only, we decided we'd push for cleaning up this confusion and \e[1m doing bold only (by default, the other behavior still available for compatibility).

The Kitty terminal emulator only implements this behavior, it doesn't support automatically brigtening bold text. In xterm and urxvt this behavior is available as a settings. It's not without precedence, and for Solarized users, indeed this is the most pragmatic, the single correct solution.

[chrisduerr] I strongly disagree with the idea that people should tweak draw_bold_text_with_bright_colors when they don't like their secondary colors.

It's not about not liking the secondary colors per se. It's about not liking an automatic switch to them when bold/bright is requested.

You should be able to render things in bright without them looking weird, regardless of bold or not, since it's always possible to explicitly specify the bright colors.

The problem is not to render in bright. The problem is to render in bold, without becoming bright (or a totally different color in case of Solarized) as well.

[kchibisov] I don't think that this tweak should be on the colorscheme section, it's a personal preference in my opinion.

It's borderline. For "regular" color schemes it's probably a matter of personal preference. For Solarized, it's a necessity.

See the aforelinked page for further opinions, drawbacks, etc. on this entire story.

[chrisduerr]

It's not about not liking the secondary colors per se. It's about not liking an automatic switch to them when bold/bright is requested.

I'm aware of that and as I've mentioned before, I use this option myself.

I just wanted to make it clear that even when secondary colors are used, things shouldn't look 'weird'. Drawing in bright red should still be a pleasant (subjective) red to you.

So if you're not a fan of how the secondary colors look, toggling this option just to see them less is not the recommended solution.

Now if you're like me and many others and think that making text bold shouldn't change its color, then that's exactly what this option was made for and I'd encourage everyone to make use of it.

I was aware that kitty doesn't even add an option for this (and have heard people frustrated about it), though it's new to me that gnome has this as a default now. It might be worth considering for Alacritty too, since I think it's the better option, though I'm not sure which way would be preferred by the majority of the users. Have you gotten any negative feedback about the change in defaults @egmontkob?

[egmontkob]

The feedback so far was surprisingly positive (at least neutral), although I honestly expected a negative one, for these reasons:

• Generally, when there's a change between two roughly equally good solutions, the change is usually perceived as negative. People tend to prefer the status quo rather than something new.

• People who dislike a change are more likely to speak up than those who like it.

• In this particular case the change "broke" certain things (more precisely: triggered a broken behavior e.g. in Linux's "make menuconfig", presumably elsewhere too).

I saw perhaps like 5-ish comments in distribution bugtrackers as well as stackexchange forums. After explaining what's going on, they were quite understanding of this change. No one I recall was explicitly negative about it. I'll try to collect these links (not right now; please ping me in a couple of days if I forget Update: they're in #2779).

The change went into git master almost a year ago, and released as stable half a year ago. Then it appeared in Ubuntu 19.04 and Fedora 30. So I think we should say that a relatively significant user base already has it.

Given the way dconf and our config settings works, I think (I'm like 99% sure) that those users who never toggled this setting (which only appeared a year earlier) got the behavior automatically changed to the new one, while those who ever set it back and forth stayed with the old behavior and didn't automatically receive the change. Plus, obviously, new users get the new behavior.

IMHO it would be lovely if Alacritty followed us in pushing the world into this cleaner state. It's your call whether to make it or not (or perhaps at a later time), I don't want to push you. I hope I could provide some precious information.

[chrisduerr]

I've created #2779 to get some comments from the Alacritty community. If you have some comments about the gnome change feel free to leave them there @egmontkob.

[egmontkob]

On a side note, let me also bring GNOME 791596 to your attention, pointing out that bold and bright only serve the same purpose (the text standing out more) with light-on-dark color schemes. With dark-on-light schemes these two attributes arguably work against each other, hence washing them up makes even less sense.