solarized

solarized copied to clipboard

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

The color of the text is gray!

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

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

What's generating this prompt?

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

@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.

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.

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)

bump

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

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:

Another example is the usage command of bower.

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.

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

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

:/

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

@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.

@paulirish Sure. I'll take a look.

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.

This is just ridiculous...

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.

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

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

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)

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:

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.)

+1

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

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

+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.

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