altercation / solarized

precision color scheme for multiple applications (terminal, vim, etc.) with both dark/light modes
http://ethanschoonover.com/solarized
MIT License
15.8k stars 3.52k forks source link

Grays could be more distinguishable #104

Open huyz opened 13 years ago

huyz commented 13 years ago

This is not an issue per se. I'll just throw this out as an idea, so feel free to close.

After working with emacs, irssi, mutt, dircolors, etc. in a terminal, I feel that the grays are too close to each other. I wish that base01/base1 were farther away base00/base0.

As it is, they are almost indistinguishable, making them less useful for highlighting distinct text. Also, sometimes I'd like the text to really fade into the background, for something not important (e.g. a *~ emacs file in dircolors or a join/quit messages in irssi). And base01/base1 are just too different from the background base02/base2/base03/base3 colors to get a faded look.

Actually I think all the grays should be farther apart to make them more useful. But I don't know the color theory that you're using to come up with these...

What do you think?

altercation commented 13 years ago

The constraint is the symmetry. Let's discuss this using the example of dark mode.

If base0/1 are farther from base00/01 then 0/1 will display greater contrast against base2/3. This is acceptable and can even be desirable.

However, due to the symmetric relationship of dark and light mode, when we subsequently switch to light mode, base0/1 will now be much lower contrast against base2/3. This is most definitely not desirable.

I spent months testing variations of the key contrast deltas (∂1 base02-base03 contrast delta which is the same delta for 01/00 0/1 and 2/3) and, more relevant to this question, the central delta between 00/0 (∂2). The current value represents the optimal value given the floor/ceiling values of 03/3 (∂0) and the minimal difference delta of 03/02 (∂1).

I eventually developed a simple equation to calculate all this which sped up testing somewhat.

So, essentially, given that the 03/02 01/00 0/1 2/3 delta (∂1) is at an optimal value (any lower and contrast between those pairs is too low, any larger and we have less "headroom" for ∂2) and ∂2 (00/0) cannot be any larger without making two of the monotones less visible, this is the most balanced state.

Hope that clears up some of the reasoning. I worked pretty hard to optimized it.

There are some options going forward in other colorschemes. I have a couple other schemes that I won't be working heavily on till after Solarized is out of beta. One is non-symmetric and this allows for higher contrast on key monotones. The other has a wider delta between floor and ceiling.

Ethan Schoonover es@ethanschoonover.com http://ethanschoonover.com

tpope commented 13 years ago

Right now, there are two pairs of background colors that need to be swapped to switch between the light and dark background, right? Would it be too much to ask for a foreground color as well?

I have a vested interest in this because of my whole trailing whitespace thing.

altercation commented 13 years ago

Actually all eight base values are flipped. I'm still looking at what I can do to make trailing whitespace "visible but not obnoxious".

huyz commented 13 years ago

@tpope I'm not sure what trailing whitespace issue you're referring to (I searched issues but couldn't find it), but the following may or may not be of help to you. I like to highlight trailing whitespace in vim very distinctly. This is what I use:

" Highlight whitespace at end of line
" (if there's more than one extra one or more than two extra ones in
" the case of after a dot, so we don't get too much feedback as we type)
" http://www.vim.org/tips/tip.php?tip_id=396
highlight WhitespaceEOL term=reverse ctermfg=red ctermbg=NONE cterm=underline guifg=red guibg=NONE gui=underline
" NOTE: lookbehind prevents matching on spaces at beginning of line
match WhitespaceEOL /\([^.!? \t]\@<=\|[.!?]\s\)\s\s\+$/
tpope commented 13 years ago

@huyz, I asked @altercation for a level of whitespace visibility between 'low' (which is damn near invisible) and 'medium' (which is bold red). Most of the trailing whitespace I encounter is in reading other people's code, and I don't want my editor to scream at me for something I can't do anything about.

I'm aware of various overrides I can do to make it behave however I like, but as a guy who spends a lot of time roaming from pairing station to pairing station, having a sensible set of defaults all packaged up makes things a lot easier.