Color fix needed?

[hemanth]

That's how it looks in my terminal, can read the text only after highlighting them!

The color of the text is gray!

[sindresorhus]

This is the grey color that is turned invisible: \x1B[90m

[sindresorhus]

@altercation @TrevorBramble bump. A lot of people are experiencing this bug...

[altercation]

What's generating this prompt?

(Yes, this is a significant issue. I want to test and repo)

[sindresorhus]

@altercation node-prompt, see here.

Also see the referenced issues above.

That text is invisible because the authors of Solarized Dark made the "bright black" color the same color as the background. Whoops. Also, for some reason, they made almost all of the "bright" colors not lighter, but darker than their "normal" counterparts.

[altercation]

So it's clear, this is not a "whoops" at all, but rather a very intentional and considered compromise based on the shitstorm of conflicting standards, expectations and legacy applications that is terminal emulation.

While a change is possible, and the information about which applications and programs suffer from issues like this is very helpful, it isn't going to happen immediately as any change is going to break the way something works.

This is probably the number one concern I have (the bright black issue) and I will only make a change once I'm certain it's the absolute best option.

[hellais]

I was also experiencing this issue with yeoman, not sure on which side the bug should be fixed, but the workaround I found is to use this my Xresources

define hack_color #1c1c1c

*color8: hack_color

Changing the value of color8 to hack_color (it used to be set to !!base03 #002b36)

[satazor]

bump

[ghost]

I'm having the issue with the output from an ExpressJS application.

[cobyism]

Just ran into (what I believe is) this issue with yeoman. Here’s what the yeoman usage/help command looks like in iTerm2 with Solarized Dark:

…and with Solarized Light:

[cobyism]

Another example is the usage command of bower.

[mleveck]

What is the status of this? I just installed Yeoman 0.9.6 and large chunks of text are invisible in iTerm 2 with solarized dark. I'd let it go but: 1) My setup is far from uncommon. I'd say most OS X devs I know use iTerm2 and Solarized. 2) By definition Yeoman is a tool to make life easier, so I'd hope that fixing things like this might be a bit of a priority.

[ghost]

@mleveck You can look into the version in my pull request. Yeoman looks better with it...

[necolas]

Related problem in Mocha too - https://github.com/visionmedia/mocha/issues/802

[sindresorhus]

:/

[ghost]

Other themes give me the same problems such as Tomorrow Night Bright at https://github.com/chriskempson/tomorrow-theme. Really annoying.

[paulirish]

@altercation can you please look into this. Seems bad to advocate that people to abandon solarized but... 6 months in, we're just about at that point.

[altercation]

@paulirish Sure. I'll take a look.

[necolas]

This problem is also affecting Express: https://github.com/visionmedia/express/issues/1700

Most of the popular front-end tools have been or are affected by this long-standing bug.

[sindresorhus]

This is just ridiculous...

[ghost]

I know it’s not ideal, and nor maybe the correct solution, but some people have been getting good results from my fork at https://github.com/hydrozen/solarized. I tweaked the iTerm2 theme and the vim theme and it seems to work well enough for me.

[henrahmagix]

+1 for @hydrozen's fork. I'm using it successfully, but only with iTerm2.

[brianarn]

Another +1 for @hydrozen's fork and iTerm 2 usage. Works quite well, just set it up now. :+1:

[mbrevda]

As per https://github.com/altercation/solarized/issues/164, this is easly fixed by uping the contrast in iterm2 (I found a about a third from the left to be optimal)

[benhoskings]

The issue is that there is no way to render a low-intensity, neutral colour on Solarized in a way that also works with default terminal colour schemes. Here are the some schemes for comparison:

#!/usr/bin/env ruby

puts "running in an #{ENV['TERM']} (#{ENV['TERM_PROGRAM']})"

[2, 30, 37, 90, 97].each {|code|
  puts "using \\e[#{code}m: \e[#{code}mbam\e[0m"
}

A textmode linux pty:

A basic xterm's default scheme:

OS X Terminal.app's default scheme:

Solarized light:

Solarized dark:

                       linux pty   xterm     Terminal.app   solarized light  solarized dark
"\e[2m" low int.       -           -         low int.       -                -
"\e[30m" black         invisible   -         -              grey (*)         v faint
"\e[37m" white         -           white     white          white            white
"\e[90m" bright black  -           grey (*)  grey (*)       grey (*)         invisible

Notes:

• The '-' above means unchanged, i.e. the standard foreground colour for that scheme.
• 'low int' is an ANSI code which renders the given colour at a lower intensity. It would be useful for our purposes, but it's not widely supported.
• 'white' isn't always quite the same as the background white, but it's close enough that text rendered in white isn't readable.

As you can see, you get grey by using "bright black", because that's what the standard colour schemes support. (These are the terminals I have at hand, but I've seen this borne out over others too.) Solarized aside, everything correctly renders ansi 90m as grey, except a linux pty, which doesn't change colour.

(The only way to get grey on a linux pty is to render bold black text on a black background, 1;30;40m. This changes the background colour on a non-black terminal and results in invisible text in most xterm-like emulators. Can't win 'em all!)

Solarized dark's "bright black", though, is the same as the background colour. I'd be interested to hear the reasoning behind this choice, but in the meantime, in my opinion it's incorrect and ripe for fixing. Raising Solarized dark's 'bright black' slightly would do the trick.

I use a tweaked solarized and have bright black set to R30,G100,B118 which looks good to my eyes:

[benhoskings]

Oops, I made a little mistake above :) There's no need to render a background behind "bold black" text on a linux PTY, hence the 1;30;40m that I quoted can be simplified to 1;30m.

Without the black background, the text is visible on all terminals, but it doesn't render consistently enough to be useable for grey. A linux pty will render it in grey, but most standard themes will render it as bold, black text. (Solarized dark renders it in a very dark grey, too dark to be easily read.)

(I think "bright black" \e[90m is the right choice for grey regardless of this.)

[gingermusketeer]

+1

[sukima]

OMG @mbrevda the contrast setting in iTerm2 works perfect! Thank you!!!! Thank you!!!!

[ghost]

I’m still not sure the contrast setting really is the correct solution, I don’t see why only this theme would be affected.

[rdlugosz]

+1 for finding some kind of solution to this... @hydrozen's alternate schemes work great in terminal, but the Vim colorscheme doesn't play nice in macvim. May have to use the contrast fix, but I don't like that it impacts all of the colors.

[davidfou]

Contrast setting is definitely not the correct solution because it breaks the vim powerline. @hydrozen theme works perfectly (I don't use macvim) and now everything works perfectly! Many thanks

[ghost]

@rdlugosz maybe some of my tweaks should be exclusive when NOT in gvim. I’d have to check what I changed but it must be possible.

[deiga]

@hydrozen Your fixes make screen background all bright greyish

[ghost]

@deiga and you are using both my iTerm2 theme and the vim theme?

[deiga]

@hydrozen Yeah, I am

[ghost]

@deiga that’s odd. I had the same issue I think when I had only tweaked the iTerm2 theme... so then I tweaked the vim theme.

[deiga]

Not sure how the vim theme would effect my screen colors

[ghost]

@deiga Ahh sorry, I misread and assumed you were having the same issue I had with vim (where the background would be bright gray).

I tried launching screen and my background color is fine there. You only have the problem when running screen? or even outside of screen in the terminal?

[deiga]

Currently only in screen, here's a screenshot

More specifically, it's the caption and hardstatus which get colored funny, so it's not a big problem for me

[ghost]

@deiga and if you run screen but do not go into irssi the background of your terminal is fine?

The only problem I had was with the vim theme. I just installed irssi and it seems fine on my end but different than yours. Did you install a solarized theme for irssi? Maybe that one needs to be fixed too :( And if vim and irssi themes need to be fixed, then maybe my tweak to the iTerm2 theme isn’t the right solution to this problem?

I still wish somebody who knows their shit with iTerm2 themes would look into it once and for all. Solarized is a really nice theme and it’s a bummer that the whole repo seems abandonned right now.

[deiga]

@hydrozen Nope, it happens whenever I am in screen. I don't have solarized for screen, don't know that there is something like that. I have a custom theme https://github.com/deiga/dotfiles/blob/master/screenrc

And that probably is the issue :P

[ghost]

I just took some time to look at some other iTerm2 dark themes (Tomorrow Night, Zenburn, Desert), and none seems to use the color that’s set as Background Color in any of the Ansi color definitions. Also, Ansi 8 Color always seems to be gray in the other themes, while the current iTerm2 solarized theme defines it as the same dark blue that is set as the Background Color. So I’m 99.9% sure about my iTerm2 fix... but not so much about the tweaks I’ve done to the vim theme although it seems fine at first glance.

@altercation if by any chance you read this, can you look at my pull request so we can at least get the trivial iTerm2 theme fix merged? But since even @paulirish stepping in didn’t convince you I don’t think I will :)

[ghost]

@rdlugosz I think my fix should probably only be applied for terminal vim and not graphical vim. I’ll have to look into that.

[ghost]

@rdlugosz for some reason I can’t reproduce the problem I was having with the vim theme when using my iTerm2 solarized tweaked script. It’s like it fixed itself somehow.

[cuviper]

I feel like this could be vastly improved by just swapping so black=base03 and brblack=base02. The actual colors wouldn't need to change. Programs which output brblack text will still be hard to read, but at least not invisible against the background.

Would anyone be interested in such a fork?

[brianarn]

@cuviper I wouldn't sweat it, the @hydrozen fork works really quite well.

[cuviper]

@brianarn that only helps iTerm2 users, which I am not. I think a more general solution is needed.

[ghost]

@cuviper where are you having issues? which app?

[brianarn]

To be fair, we all think there needs to be a more general solution, but this project seems effectively dead. If we're going to rally around some new fork, it feels like @hydrozen's is already a good starting point for the work, is all. :)

[cuviper]

The same invisible-brblack issue occurs on all terminals. I see it through gnome-terminal, putty, and mintty, for instance. The particular program that's a problem in my case is htop, which uses brblack as a dark gray for de-emphasized text. Invisible is a bit too de-emphasized though, as you all realize. :)

OTOH, I think those programs which use brblack as some kind of emphasized text are very wrong, as that assumes a black-on-light terminal to begin with.

I'm not trying to disparage @hydrozen's fork, but I don't agree with his approach. He drastically redefined brblack in the terminal, which changes the whole palette, but then only adjusted vim to match. Having that new color be even brighter than base0 is just wrong to me, just reenforcing that bad assumption about brblack. Maybe that's a reasonable tradeoff in the Mac world, if a lot of programs are assuming black-on-white like this. I don't think that's a good direction in general though.

With the approach I'm considering, defining black=base03 and brblack=base02, only the themes which reference those names (or equivalent terminal color index) would need to update. Maybe if that's still too dark, base02 could be lightened, but I think it should remain dark enough to be a good background for base0 and base1 too.

That's my 2 cents, and then some. I'll probably go ahead and try it, see how it goes. It's ok with me if it doesn't become a new rallying point, because I think we're dealing with different constraints in the way brblack is used.

[ghost]

@cuviper which terminal are you using? In my fork, I only touched the iTerm2 theme and the vim theme, so that would not affect htop unless you’re using iTerm2.