I wish I could choose a language to preview the schemes with. My biggest gripe with many of these themes is that is looks great in some languages and terrible for everything else.
...and syntax file goes to colorize Something, but Else is perceived as common text.
I'm aware of limitations of vim, being text editor and not an IDE, but I'd rather syntax file to ignore the native API then to have me draw visual distinction between native and third-party classes when, effectively, I couldn't care less. The dissimilarity is just visual noise to me. :/
vim color schemes previewed in a variety of popular languages: https://code.google.com/p/vimcolorschemetest/ Just choose a language at the bottom of the page. Then wait... it takes a while to load the next page because its got a lot of html in many iframes
It occurs to me that the fewer lexical types a language has, the less possible it is to highlight it in a pleasant way. Lisps and Forths (and most assembly languages) must look unpleasantly spare; and an encoding like Urbit's Nock would be literally monochrome.
What bothers me isn't the isolated color scheme, but that without a ton of work (rolling it yourself?) the javascript in .js, .html, .erb, and any other file it might be in is highlighted completely differently.
You can actually do quite a bit to help with that by switching around which colors are assigned to which syntax rules, if you're willing to dive into the code.
This is unrelated, but in the first screenshot, how do you get a terminal windows inside vim ? ( git in the top right). I guess it is a neovim feature.
I find that theme very aesthetically pleasing, but I'm always having a hard time reading when the contrast between the text and background is so small compared to the theme vividchalk that I always fall back to.
Is this something you get used to, or is it a hopeless case for me to learn to use these beautiful themes?
Seconded. Tomorrow-Night is an amazing theme with several variants (blue, black, light...) and compatibility with everything. Even the Chrome Devtools.
I'm probably in the minority, but I've always found that anything other than constant-coloured text on a constant-coloured background with a high contrast to be more distracting than helpful.
One thing I like with syntax highlighting is when a string or other delimited expression hasn't been closed (e.g. as I'm writing it), the following code looks like it's part of the string or expression. It creates just the slightest tension in me: "close it ... close it ... close it ...
It's a similar feeling to when I haven't saved my editing in the last minute. :)
I find syntax highlighting is particularly useful in tightly-packed constructs. Consider this function returning a string interpolation in CoffeeScript:
(d) -> "id-#{d[@id]}"
In my default color scheme, the #{} (string interpolation), @ (this pointer), and () (function parameter delimiter) are muted, since they're syntactically critical but not helpful to my understanding.
The "id-" is more subtle than code but more visible than the muted syntax, because I only sometimes care about the string literal, and the array indexer [] is about the same.
The identifiers d and id are the regular typeface, since those are the code items.
The -> which creates a closure is brightest, because creating a closure is a relatively heavy operation and it's useful to be able to pick them out at a glance.
I understand that you CAN read it without highlighting, but the signal-to-noise ratio is much worse. In particular, the hash mark and atpersand stand out much too prominently.
The linked article is concerned about breaking up the "natural flow of the text", but I think that misses a critical observation. While prose text flows from left to right, line by line, that's not how code flows. Code's flow is in its structure.
I have colors switched off in most of my editors, but I have found that having a distinction between code and comments (particularly multi-line comments) helps to avoid confusion.
This is great. I'd like the ability to live-filter over and above the ability to search. Also, more than 10 hits per page. It'd be wonderful to have some sort of voting or popularity metric to sort by. And, for pie-in-the-sky features it would be nice to have filters based upon contrast / hues / etc. other than just "dark" and "light."
Can anyone recommend color schemes other than Solarized that have extensive support across board (not only vim, but all the plethora of terminal emulators, command-line applications, etc.)?
Solarized is too low-contrast for me, so I have hacked-on support for hybrid (solarized syntaxes + tommorow color codes), but it's not really uniform. And, imho, well-balanced contrast is the most important thing.
Non-exhaustive list of applications that I'd like to see supported - vim, emacs, tmux, weechat, vifm, newsbeuter, taskwarrior, mutt...
With Base16-Builder you can make a Yaml file of colours and it will build profiles for a zillion apps. It's pretty easy to hack to build other profiles as you just need to make an erb.
Base16 is organized in pretty much the same way as Solarized colours, so if you have gotten used to Solarized and just want to adjust the colours to something easier to see (I suffer from the same problem you do), then I think it is the way to go.
I hesitate to mention this because it isn't quite ready yet, but where I work we do a lot of remote pair programming over tmux. The problem is that everybody has their own idea of what colours look good. My buddy and I made a vim colorscheme that looks reasonable with many different palettes, called agnostic: https://github.com/ygt-mikekchar/agnostic
So if you ever need to pair program over tmux and one person wants a light background, but another person wants a dark backgroun, you can do it it. If you do that kind of thing a lot, then I recommend working with agnostic. Otherwise I think Base16 is probably the way to go.
I use hybrid in vim and base16 in everything else and that's about the best I've found so far. The base16 "builder" seems like it supports the most things:
I just use Base16 ( https://github.com/chriskempson/base16 ), so I have the same colorscheme in all relevant apps. It can emulate almost all of the popular schemes, plus has a lot of others.
I find myself often switching between dark/light colorschemes when I'm working inside/outside. However, this is a quite annoying task, I have to change the colorscheme of my terminal, and of Vim. Besides, I have multiple Vim sessions running in various tmux/terminal tabs, so when I switch to a different tab, I have to change the colorscheme of Vim again.
Then when I go inside/outside again I have to switch it all back. Quite a hassle. Has anyone found any trick to automate this? For starters I wouldn't know how to change the colorscheme of all my Vim sessions. Can you send a signal to your Vim sessions maybe? Then changing the terminal colorscheme is of course dependent on the terminal app you're using.
So the Solarized home page starts off with this paragraph:
> Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications. It has several unique properties. I designed this colorscheme with both precise CIELAB lightness relationships and a refined set of hues based on fixed color wheel relationships. It has been tested extensively in real world use on color calibrated displays (as well as uncalibrated/intentionally miscalibrated displays) and in a variety of lighting conditions.
I'm assuming this means it's giving a criterion to "measure" how good it is in a not-entirely-subjective-way. That always bothers me about selecting a theme. I have no idea if it's good or bad in any standard measurable way.
I look at these themes and can't really tell what it's "unique properties" or anything interesting about it just by looking at it.
Very cool. I'd love to see the ability to tag and filter 256-color schemes, for `TERM="xterm-256color"`. And some ranking metric (e.g. stars on the GitHub repo) would help surface the good ones that a lot of people use.
WYSIWYG editors like Vivify (http://bytefluent.com/vivify/) are helpful too. The greatest challenge for me with making vim look nice is in harmonizing the vim color scheme with that of my guake terminal emulator. I wasted too much time trying to synchronize terminal colors with vim colors, eventually giving up.
When filtering by Light, some color schemes come through that are Dark. Is this a bug or do those color schemes have both light and dark versions? I looked at one of the dark "light" schemes and it didn't seem to have a light version on the github page.
When I was googling for Vim color schemes some time ago I've seen that webpage. It is really nice, I like that dark/light feature (but some themes were miscategorised as dark, at least when I last checked).
Can we do more than 10 per page? I hate having to click next, next, next in between scrolling. If I could just flick the scroll wheel and let my eyes pick out the ones I like it would be so much easier!
[+] [-] andrewguenther|10 years ago|reply
[+] [-] synthmeat|10 years ago|reply
I'm aware of limitations of vim, being text editor and not an IDE, but I'd rather syntax file to ignore the native API then to have me draw visual distinction between native and third-party classes when, effectively, I couldn't care less. The dissimilarity is just visual noise to me. :/
[+] [-] shawnps|10 years ago|reply
[+] [-] masukomi|10 years ago|reply
[+] [-] hnnew|10 years ago|reply
[+] [-] derefr|10 years ago|reply
[+] [-] mdcox|10 years ago|reply
[+] [-] couchand|10 years ago|reply
[+] [-] golergka|10 years ago|reply
Especially when you switch from C-style languages to assembly, for example. Or to line-break sensitive formats like Python or YAML. Or markdown.
[+] [-] nathanaelkane|10 years ago|reply
[+] [-] stockninja|10 years ago|reply
I love the Tomorrow-Night theme:
Vim: http://i.imgur.com/HBaCTAu.png
Zsh: https://github.com/sindresorhus/pure
On Github: https://github.com/chriskempson/tomorrow-theme/blob/master/v...
[+] [-] Hates_|10 years ago|reply
https://github.com/chriskempson/base16-vim
[+] [-] seren|10 years ago|reply
[+] [-] polack|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] scrollaway|10 years ago|reply
[+] [-] userbinator|10 years ago|reply
It appears I'm not the only one:
http://www.linusakesson.net/programming/syntaxhighlighting/
[+] [-] a3n|10 years ago|reply
It's a similar feeling to when I haven't saved my editing in the last minute. :)
[+] [-] couchand|10 years ago|reply
The "id-" is more subtle than code but more visible than the muted syntax, because I only sometimes care about the string literal, and the array indexer [] is about the same.
The identifiers d and id are the regular typeface, since those are the code items.
The -> which creates a closure is brightest, because creating a closure is a relatively heavy operation and it's useful to be able to pick them out at a glance.
I understand that you CAN read it without highlighting, but the signal-to-noise ratio is much worse. In particular, the hash mark and atpersand stand out much too prominently.
The linked article is concerned about breaking up the "natural flow of the text", but I think that misses a critical observation. While prose text flows from left to right, line by line, that's not how code flows. Code's flow is in its structure.
[+] [-] Gracana|10 years ago|reply
[+] [-] nakkiel|10 years ago|reply
http://vimcolors.com/?utf8=✓&order=relevance&query=monochrom...
[+] [-] lordfoom|10 years ago|reply
[+] [-] jstimpfle|10 years ago|reply
> nmap <F11> :if exists("syntax_on") \| syntax off \| else \| syntax enable \| endif \|<newline><newline>
that makes F11 a toggle-highlighting button. Sometimes, highlighting helps spotting syntax errors.
Other than that, setting the "xterm*termName" X resource property to "xterm-256color" makes colors in vim much less distracting.
[+] [-] scelerat|10 years ago|reply
[+] [-] isomorphic|10 years ago|reply
[+] [-] nathanaelkane|10 years ago|reply
I've been wanting live-filter for a while but decided to launch with basic filtering.
Once I'm happy with core features I'll start looking at stuff like rating, favouriting, etc.
(I meant to post this comment earlier but it was throttling me.)
[+] [-] synthmeat|10 years ago|reply
Solarized is too low-contrast for me, so I have hacked-on support for hybrid (solarized syntaxes + tommorow color codes), but it's not really uniform. And, imho, well-balanced contrast is the most important thing.
Non-exhaustive list of applications that I'd like to see supported - vim, emacs, tmux, weechat, vifm, newsbeuter, taskwarrior, mutt...
[+] [-] mikekchar|10 years ago|reply
There is a related project called Base16-Builder: https://github.com/chriskempson/base16-builder
With Base16-Builder you can make a Yaml file of colours and it will build profiles for a zillion apps. It's pretty easy to hack to build other profiles as you just need to make an erb.
Base16 is organized in pretty much the same way as Solarized colours, so if you have gotten used to Solarized and just want to adjust the colours to something easier to see (I suffer from the same problem you do), then I think it is the way to go.
I hesitate to mention this because it isn't quite ready yet, but where I work we do a lot of remote pair programming over tmux. The problem is that everybody has their own idea of what colours look good. My buddy and I made a vim colorscheme that looks reasonable with many different palettes, called agnostic: https://github.com/ygt-mikekchar/agnostic
So if you ever need to pair program over tmux and one person wants a light background, but another person wants a dark backgroun, you can do it it. If you do that kind of thing a lot, then I recommend working with agnostic. Otherwise I think Base16 is probably the way to go.
[+] [-] hjst|10 years ago|reply
https://github.com/chriskempson/base16-builder
[+] [-] Zardoz84|10 years ago|reply
[+] [-] RVuRnvbM2e|10 years ago|reply
https://github.com/noahfrederick/vim-noctu
It takes colours from your .Xdefaults/.Xresources, and all terminal apps just use your configured scheme.
See also: http://www.xcolors.net/
[+] [-] DiabloD3|10 years ago|reply
[+] [-] gitaarik|10 years ago|reply
Then when I go inside/outside again I have to switch it all back. Quite a hassle. Has anyone found any trick to automate this? For starters I wouldn't know how to change the colorscheme of all my Vim sessions. Can you send a signal to your Vim sessions maybe? Then changing the terminal colorscheme is of course dependent on the terminal app you're using.
[+] [-] laichzeit0|10 years ago|reply
> Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications. It has several unique properties. I designed this colorscheme with both precise CIELAB lightness relationships and a refined set of hues based on fixed color wheel relationships. It has been tested extensively in real world use on color calibrated displays (as well as uncalibrated/intentionally miscalibrated displays) and in a variety of lighting conditions.
I'm assuming this means it's giving a criterion to "measure" how good it is in a not-entirely-subjective-way. That always bothers me about selecting a theme. I have no idea if it's good or bad in any standard measurable way.
I look at these themes and can't really tell what it's "unique properties" or anything interesting about it just by looking at it.
[+] [-] ghodss|10 years ago|reply
[+] [-] paulannesley|10 years ago|reply
Personally I use a slightly tweaked version of http://vimcolors.com/1/jellybeans/dark … the id of 1 in the URL suggests the author might too.
[+] [-] nathanaelkane|10 years ago|reply
[+] [-] Dowwie|10 years ago|reply
Whoever solves that problem earns a raise
[+] [-] dpacmittal|10 years ago|reply
[+] [-] anantzoid|10 years ago|reply
[+] [-] alxndr|10 years ago|reply
[+] [-] bergmann|10 years ago|reply
[+] [-] ashmud|10 years ago|reply
Aside: The pages are also a good browser stress test with the large number of iframes.
[+] [-] irth|10 years ago|reply
[+] [-] a1b2c3|10 years ago|reply
[+] [-] nathanaelkane|10 years ago|reply
[+] [-] nabn|10 years ago|reply
[+] [-] clemlais|10 years ago|reply