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.
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].
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.
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 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.
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 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 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?
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.
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 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 :)
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.
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.
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 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).
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/
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).
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.
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.
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.
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).
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.
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.
163 comments
[ 3.1 ms ] story [ 237 ms ] threadMy favorite for gvim/MacVim is molokai: http://winterdom.com/2008/08/molokaiforvim , seconded by vividchalk when i'm on the terminal: https://github.com/tpope/vim-vividchalk
Haven't found any good color scheme for iterm2 yet. Currently i'm using thayer: http://ecto-plazm.deviantart.com/gallery/
http://natestedman.com/post/morrowind-for-textmate-xcode/
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.
https://github.com/NateStedman/morrowind
Will upload the vim one later after I finish it up.
This is supposed to be the version for Eclipse, but it seems that the colors are kind of different, which is a pity:
http://www.eclipsecolorthemes.org/?view=theme&id=1
http://blog.nozav.org/post/2010/07/12/Updated-tangotango-ema...
[1] http://www.vim.org/scripts/script.php?script_id=2215
[2] http://www.vim.org/scripts/script.php?script_id=1635
[3] http://code.google.com/p/vimcolorschemetest/
Molokai ain't perfect, but I have yet to find one I like more for daily use.
Source: https://github.com/entropie/dotfiles/blob/master/.emacs.d/co...
For iTerm2 I copied over the colors from Visor.app's theme.. but Solarized looks really nice, so maybe I'll soon be using that instead.
[1] https://github.com/acarapetis/vim-github-theme
http://i.imgur.com/Ui93Q.jpg
If anyone is interested, the theme is here:
http://notendur.hi.is/ths46/thor.vim
The .vim file started out as IR_black, I just hacked at the colors until I was satisfied, so the code's not clean or anything :)
[I also have a OS X terminal theme to go with it, and an emacs version.]
http://www.vim.org/scripts/script.php?script_id=2465
Screenshot with semi-transparent background: https://picasaweb.google.com/lh/photo/3ORpqSeM1kvLV0lceHpOjw...
https://github.com/larssmit/iTerm-2-Color-Themes
I actually tend to read (and write) comments a LOT. Which is why, I simply am not able to use any colorscheme that tries to hide comments.
IR_Black for Textmate though
I am not sure how it handles terminal colors. So I just configured Console2 to use Solarized colors and then tried every colorscheme in Vim.
"morning" scheme worked best for me. It is so much easier to read my coworkers crammed code.
https://github.com/strange/dotfiles/blob/master/.vim/colors/...
Python: http://files.pipsq.com/strange/python.png Erlang: http://files.pipsq.com/strange/erlang.png
http://www.vim.org/scripts/script.php?script_id=3534 https://github.com/strange/strange.vim
What's your terminal setup like?
I run tmux inside iTerm2.
I'll clean the theme up a little and make an isolated repository.
Looks decent in 8-color terminal as well.
You can download it here: http://www.vim.org/scripts/script.php?script_id=1975
Make sure to enable 256 colors.
[1] http://www.vim.org/scripts/script.php?script_id=619
I'll stick with Zenburn[1].
[1] http://slinky.imukuppi.org/zenburn/
Blurby enough? ;-)
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.
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 :)
http://studiostyl.es/schemes/solarized-dark
https://github.com/sellout/solarized/tree/master/emacs-color...
http://dropup.net/lz64u0ctpcge.png.html
https://github.com/purcell/color-theme-sanityinc-solarized
The color fix will probably get into sellout's repo, so interested parties should prefer that one over mine.
https://github.com/phiggins/solarized/commit/b3c2170ec01fb7d...
https://github.com/purcell/color-theme-sanityinc-solarized
(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.)
Thanks!
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).
its a refreshing change, awesome work
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'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 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've forked Mark's version and added a bunch of specific styles for the Light version, specifically a lot of rules for PHP and CSS.
It's not 100% yet, but it's already the best TextMate theme I've ever used.
https://github.com/deplorableword/solarized
Maybe it looks better on a different monitor? (I have a Samsung LCD.)
Using a Dell monitor attached to a mac via DVI though, and calibrated to the best of my ability using the OSX calibration tool.
If on Windows XP. Display Properties > Appearance > Effects
====== ( http://www.fullmalls.com )====
Air jordan(1-24)shoes $30
Handbags(Coach l v f e n d i d&g) $35
Tshirts (Polo ,ed hardy,lacoste) $15
Jean(True Religion,ed hardy,coogi) $30
Sunglasses(Oakey,coach,gucci,A r m a i n i) $15
New era cap $12
Bikini (Ed hardy,polo) $20
accept paypal and free shipping
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
====== ( http://www.fullmalls.com )====
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).
[1] https://github.com/evanphx/terminalcolours/downloads
https://github.com/varikin/solarized/tree/master/xcode4-colo...
for one thing, at least one of the bold text colors is the same as the background, this makes this text not even show up when it's present
it would be nice if not for this
https://github.com/deplorableword/solarized