Slightly related, I don't like (mostly in OOP langs) when I have something like:

    import lang.native.api.Something;
    import third.party.api.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. :/

I agree many of the default Vim syntax highlighting files leave a lot to be desired. You can improve it though and Vim highlighting is actually very powerful. I use a C syntax highlighting improvement plugin to add (among other things) highlighting to operators and function names in calls[1].

You can also quite easily customise syntax highlighting by placing your own additional syntax file in .vim/after/syntax for a language. I use this to add some more custom keywords. You could quite easily add highlight support for ".Else" in an after/syntax file.

[1] https://github.com/justinmk/vim-syntax-extra

Why is something limited in highlighting because it's a text editor and not an IDE? Highlighting is about text so it's quite a core feature of an editor.

Usually because the text editor is limited to regular expression and region matching, while the IDE parses the language into an AST so it knows what each bit actually means.

Except a text editor can also generate the AST.

What I meant was that the limitation in highlighting is usually due to the limitation in pattern matching. Of course, IDEs usually contain text editors, and they often do highlight using an AST. But that's expensive, both to develop and to run, and especially if you're not going to use the AST for any other IDE-like activity. Pattern-matching is cheap and usually good enough.

Okay, you are not talking about a problem in principle but how it practically is in reality. I don't know if text editors like Sublime/Atom also have that problem but when it comes to vim I can agree with that. Wouldn't wonder if there are some better external highlighters that can be integrated with vim. I heard that people use a vim plugin for using external linters for static analysis of code and spell checking.

And just to make sure, we agree that adding a feature like AST based highlighting wouldn't make an editor an IDE, right?

Agreed.

I agree. I sent a tweet to the author requesting it, hopefully he sees it: https://twitter.com/shawnps/status/615780187800629248

Yep, saw it, thanks :)

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

Seconded. A language selector would make choosing a theme for your language with this tool much more effortless.

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.

Unpleasantly spare?

http://take.ms/k83XH

Clojure is an exception to the number of lexical types found in most Lisps, note. Scheme doesn't highlight nearly as nicely.

Now please explain blurb/nth-blurb :)

That's code for a fancy loading screen, which animates some svg thing and also shows a couple happy messages (aka blurbs.)

I would really like to read the rest of the source of whatever that application is.

Are you using Reagent?

I am using reagent and re-frame. Sadly the codebase is closed source. :(

OMG! How do I do that? Mind sharing your configuration?

Sure, I use emacs prelude. I think you can get the same results here if you just use prelude + the amazing theme called moe. My emacs config (which is to be used inside/ontop of prelude) is at https://github.com/escherize/prelude-dotemacs

loved the rainbow brackets on that, it must be so useful to see where they match up with colour.

It is! Also when your cursor is on a paren, the text editor lights up its partner: http://take.ms/PJS1p

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.

Yes.

Especially when you switch from C-style languages to assembly, for example. Or to line-break sensitive formats like Python or YAML. Or markdown.

Completely agree and it's pretty high on the TODO list.