I remember having a chat with Andrew Gerrand at some Go conference, about how syntax highlighting is mostly done wrong, we just got used to it being that way. It's not like we colour words in a sentence based on their type, but we do enjoy tools highlighting misspelled words or grammatical errors.
In my experience syntax highlighting as a tool mostly help with certain classes of errors (e.g unclosed string or comment), not visually tokenising text for me to understand.
I've seen some such uncoloured theme (nofrils) that would de-emphasise either comments or code, and you could toggle between the two states, which I found quite useful in nicely commented files:
There are a bunch of learnings and a couple of links to references in that article. Ironically one of the most prevalent I experienced was this one, which I found very odd because picking a colorscheme for my $EDITOR is quite literally a choice that would affect only myself:
> People on the internet will get very angry at you if you tell them you don’t like syntax highlighting. VERY ANGRY.
> It's not like we colour words in a sentence based on their type,
All of today's human languages were developed in a time without computers, pens (and their predecessors) have trouble switching ink color for every word. If goose quills and inkwells could change color as easily as computer monitors, I bet there would have been at least a few languages that use color to denote meaning.
Somewhat tangential: but I love the LiquidHaskell demos, mostly because they show what would be possible if our tools would just be a tiny bit smarter.
Example:
1. Goto here: http://goto.ucsd.edu:8090/index.html#?demo=Order.hs
2. Run Check, it should turn green
3. Break the code, e.g. turn around the >= sign in line 147
4. Run Check again, it will turn red and highlight line 147 and 148
What happened here?
We told the compiler that elements in an ordered list will be in increasing order (l.119). Now the compiler is able to check that constraint and by turning around the comparison we violated the it.
Ie by telling the compiler a tiny bit about our goals (have ordered lists) it is now able to check that our algorithm is correct.
In my experience syntax highlighting as a tool mostly help with certain classes of errors (e.g unclosed string or comment), not visually tokenising text for me to understand.
I've seen some such uncoloured theme (nofrils) that would de-emphasise either comments or code, and you could toggle between the two states, which I found quite useful in nicely commented files:
https://robertmeta.com/posts/syntax-highlighting-off/
There are a bunch of learnings and a couple of links to references in that article. Ironically one of the most prevalent I experienced was this one, which I found very odd because picking a colorscheme for my $EDITOR is quite literally a choice that would affect only myself:
> People on the internet will get very angry at you if you tell them you don’t like syntax highlighting. VERY ANGRY.
Some of these vim "color"schemes:
They pair well with vim-airline's "raven" theme.