Its really rare to see that much thought going into the aesthetics of stereotypically "geeky" applications like vim and terminals, even the website looks entirely different from pretty much every website I have seen around these tools
Thanks very much. Looking back at my early hg repos on this project I refined it for about six months.
As an aside. I have a nominal post in my head contrasting the development and refinement of a colorscheme like this vs the infamous 41 shades of blue. There is room for refinement and testing in design, but I think it has to be coupled with a clear design goals and opinions.
It would be very interesting to learn about the methods you used to create this.
Are you planning to create a palette with more shades? Some time ago I needed lighter Tango tones and created this extended palette: http://emilis.info/other/extended_tango/
I just tried this with Perl, and it looks great (the fold-column's a bit bright, but I don't have that on by default). Have you thought about uploading it to vim.org?
I am sitting on a mostly-done vim version right now as well, the GUI colors are all good, but I wiped out the terminal colors (I want them to just be the defaults). I'm not exactly a vim expert and I almost always use the terminal vim exclusively for git commits, which don't really need highlighting, so the motivation to fix those sort of disappeared.
Thanks for the kind words about molokai; took a bit to get it ported, but I've enjoyed it a lot since then. 99% of the props should go to the original authors of monokai and Hamish, though :)
Molokai ain't perfect, but I have yet to find one I like more for daily use.
is there a reason why most of these color schemes (including solarized), have a very low contrast for comments - making them difficult to read.
I personally use the desert colorcheme (http://hans.fugal.net/vim/colors/desert.html)
I mostly use IR_black for vim and emacs, that's definitely a classic. But I'm also quite fond of a custom scheme I made; the colors mostly come from Textmate's Made of Code scheme. Here's a screenshot:
I am currently using darkspectrum[1] for diff output and candycode[2] for everything else. There is a huge gallery of them, viewable with several code samples, on the Vim Color Scheme Test page[3].
I use molokai as well, but with some small tweaks (darker near-black background, lighter more visible comments, and a more visible line highlight). Inconsolata font for life, I've tried just about every other programming font out there and I always keep coming back.
So, my mind is blown that you put so much effort into designing a color scheme, and thanks, but maybe put the img/ directory in your git repo somewhere else, so that a git pull of a color scheme doesn't take 50(!) megs.
I was afraid that would be a pain for people, sorry! You're right, I need to do this. There is a reason, which is that the exact same repo does double duty as the webpage (via Hakyll). It's super convenient because I have hakyll process the README out into an index.html (pulling webserver local imgs, so there is some sed magic).
I may try to break out the images as another subtree or make a website subtree. It was lower on my list of priorities, but clearly a pain to others cloning/forking. I'll try to sort it before beta2.
I haven't looked into how one can export gnome-terminal color palettes yet, but if anyone else is interested, I think these are the correct settings in gconf:
Edit: Ok, I pulled down the source for gnome-terminal since I couldn't find a way to export/import color schemes. The color palettes are all hard-coded, so that is unfortunate :(.
agreed, but there is no mechanism for importing/exporting additional color schemes (I guess you could export an entire profile, but that entails quite a bit more than just color schemes).
After investigating this (and raising the aforementioned Emacs bug), I've concluded that sRGB hex colors - as used by Ethan - are simply not the right hex colors to enter in Emacs in order to get the desired results. Instead, Emacs apparently works with Generic RGB values, and after some laborious conversion calculations in Apple's "ColorSync Utility", I got the right results:
I know you were joking, but actually, why not? If the color scheme is easier on someone's eyes, wouldn't it make sense to use it everywhere? Personally I've often found using dark themes in my editor a bit jarring when switching to other tools like a file browser or terminal if the settings are drastically different.
(Using the latest Emacs under OS X, it suffers from the same color issues mentioned elsewhere in this comment thread, but hopefully Emacs will soon get fixed up accordingly.)
I don't like this scheme and I don't buy the pseudo-science blurb. It's based on shades of blue. Our eyes are the least sensitive to blue. And what's up with the red and pink, is this some cruel joke?
I was a dedicated IR_Black user (in both VIM and Visual Studio), and didn't think highly of this at first. But after about an hour, it's grown on me. If I can scrape together some time, I'll throw together a VS2010 color scheme/theme.
The monotones have symmetric CIELAB lightness differences, so switching from dark to light mode retains the same perceived contrast in brightness between each value. Each mode is equally readable. The accent colors are based off specific colorwheel relations and subsequently translated to CIELAB to ensure perceptual uniformity in terms of lightness. The hues themselves, as with the monotone ab values, have been adjusted within a small range to achieve the most pleasing combination of colors.
I hope that doesn't turn too many other folks off from the page and colorscheme. It may sound like a pseudoscience blurb, particularly if you aren't a color geek, but I sure didn't intend it to. It's all technically relevant and (I thought ;) tightly descriptive.
Lab was actually a big part of the initial inspiration for the colorscheme. I work a lot in lab space (Lab is more correct, but cumbersome to type) and for anything related to actual human vision it is head and shoulders above other color models/spaces. It's also awkward if you think in RGB and notoriously poorly supported outside of Photoshop (though most OS color management systems that I'm aware of translate everything back into Lab or a Lab equivalent).
The color relations are also foundational to palette creation in traditional graphic design. They are super useful in creating a palette that feels harmonious and (subjectively) unified.
I'd be happy to go into more detail, but I tend to go on at length and, much like when I get into talking about code with people not interested in code, talking about color spaces with those not interested is a sure fire turn off :)
CIELAB might not be pseudo-science, but the claim that the application of CIELAB makes this a good scheme is, at best, dubious.
The bright red and pink don't blend with the other colors at all. Their jarring contrast (and red hue) could be adequate for an alert message, but not for innocent and frequent syntax elements.
Maybe there is a math model that captures all relevant aspects that make a good syntax highlighting color scheme. But this model clearly doesn't.
i tried a modified zenburn for a bit (i modify all my colour schemes so that the background is pure black), but went back to desert256 in the end. i just find it more pleasant to look at for hours at a time.
I don't know about the rest of you, but my eyes literally started to hurt when I read the text on that page, presumably because of the color of the text v. background. Doesn't bode well for using it in vim...
Maybe it looks better on a different monitor? (I have a Samsung LCD.)
Bizarrely: I, too, had to strain to read the page; which I attributed, however, to the weight of the font: so thin that it won't render without artifacts.
I found the theme rather comfortable for using in the terminal; however I set TERM=xterm-256color so that vim would also pick up the light colour scheme—there seemed to be some issues with the background colour on gnome-terminal/Ubuntu.
When I was brave enough to test outside of urxvt and iterm2/terminal.app, it seemed that terminal emulators are all over the place in terms of background color support in vim terminal mode.
You might have tried this already (and it might not actually be related to your issue), but there is a variable you stick in your vimrc (let g:solarized_termtrans=1) to force it to take the background of your terminal emulator (useful only if you are running with the solarized colors in terminal mode).
I should come up with a some recommendations on setting TERM to ensure proper colorscheme support, but that way lies madness (for me at least).
I don't mean to sound particularly thick here, but is there a way to apply these colours to my OSX Terminal too? I've installed the bundle for Terminal.app, and they look lovely in emacs, but can I use them in my general bash environment, too?
Once you've activated that theme in Terminal.app's preferences, all your colors in the shell will use the colors defined in the colorscheme. So red will be the red in the colorscheme, blue -> blue, etc.
Anyone get a chance to test out how this looks with vimdiff? That's one area that usually ends up looking fugly b/c the theme creator neglected to look at it. Other areas that are typically neglected (though not in this case): code folding, split buffer dividers.
It would be nice to have a script that would start with this as a base, but let you tune the contrast. I like the theme, but would like more contrast than this (I use small fonts, and I really feel like more contrast is necessary when doing so).
fwiw, there is a high contrast option in the vim colorscheme (let g:solarized_contrast="high").
I'm working on cleaning up some of the build scripts that generated specific files (the mutt directory has an ugly shell script as an example, there are better ways of course).
I was interested in seeing what the colour palettes might look like in the real world. Here's are the some multicolr searches for the 5-colour palettes:
Man, I love those sets. Hadn't used that site before but it's awesome. Very nice to see the stark ocean and ink in water in the last set. Not too far off from the deep ocean feel I was targeting during design.
Is anybody willing to explain how to switch between light and dark? I can't seem to understand the scss snippet that he gives. Apparently, you only have to switch 4 colors, It would be nice to know what those colors were.
I'll be expanding the webpage to detail that, but essentially:
base03 = background
base02 = background highlight
base01 = background data (comments, etc.)
base0 = normal text
The scheme was designed to allow for:
base1 = optional bold/emphasis
Just swap the zeros (initially I was using minus/plus, e.g. base-1 and base+1 but this isn't usable across all apps) to swap dark and light modes. There is a good example of this in the vim script as well as the sass snippet (and the mutt compile script if you are a glutton for ugly bash scripts).
base3 = light background
base2 = dark background
etc.
You shouldn't need to do any of this manually, however. The vim script has a light/dark mode built in and where there isn't a way to toggle modes I am distributing light and dark versions (the terminal color schemes).
Very nice! It is indeed amazing how much thought and effort was put into this, and it is appreciated. At some point, I'll have to convert for Visual Studio use if someone doesn't beat me to it.
Am I the only coder who doesn't like working with light text on a dark background? I have 20/20 vision, and I find it really uncomfortable to use these.
My theory is that it depends on when/where you normally work. If you have a tendency to code at night or in dark rooms, dark on light is very bright. At least, that's why I go light on dark.
My vim renders everything way darker (or perhaps is just that there is not as much contrast) than in the screenshots. I double checked that I am using xterm-256color (and also checked against rxvt-unicode-256color).
It's too bad, I really like how it looks in your screenshots, but in my computer not so much...
I cannot seem to get the colors to render properly on Snow Leopard, using Terminal.app, and vim. Anyone else have any trouble but get it to work?
I installed the thing as instructed. I installed SIMBL and the SIMBL plugin, installed Solarized Dark Terminal.app theme, installed vim using pathogen, and set .vimrc with the additional g:solorized_termcolors=16 option.
The 64-bit TerminalColours SIMBL plugin that's linked to in the README doesn't play nicely with binaryage's 64-bit Visor plugin, for some reason. However, Evan Phoenix's fork[1] works perfectly for me.
It was a prototype I made for a prospective client. I sometimes use Dutch comments (and variable names) in such a case. Btw, 'Tekstanalyse' is also a Dutch word.
Does this work in the console (vim)? I currently have desert256 working nicely in iTerm (xterm-256color). I'm away from my computer or I'd test it myself. Thanks! Never seen anyone put this much effort into a color scheme! I actually feel like I personally owe it to you to give this a shot.
Yes, but the 256 mode is actually an approximation of the real color theme. For exact colors you have to set up the 16 ansi colors of your terminal to the right colors and set a var in vimrc. See the docs for details.
I made a simple Pygments version[1] for use on my website. I immediately thought it was perfect for my site, but I'm sticking to molokai for Vim. Thanks!
its a refreshing change, awesome work