I've tried variations on low-color syntax highlighting (I've even tried no syntax highlighting!). While I agree most color schemes are too colorful, to the point where it's largely noise, I think trying to go super low on colors ends up hurting readability.
For example: keywords, specifically, are actually very useful to highlight. This post complains that misspelling "return" didn't make easily-scannable color changes (it changed the color from purple to red, which still looks like a special color)... But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually! In both cases with the proposed color scheme, "return" and "retunr" would have identical coloring: white.
Generally speaking I think a lot of the visual noise of syntax highlighting comes from having too many colors. For example, you don't need the "class" keyword to have a different color than the "const" keyword — and many syntax highlighting themes are guilty of doing exactly that. But it's useful to be able to immediately, visually see if you made a typo: if you expected to write a keyword, and it's colored like normal text, you know you messed up. Similarly, it's useful when reviewing code to quickly be able to tell whether there's a typo somewhere.
I have a pretty custom syntax highlighting theme for Neovim. I have a few categories that are highlighted differently:
- Keywords
- Function calls and method calls (highlighted identically)
- Property accesses (to highlight mistakes when you're simply accessing a property
instead of calling it — it's a different color than a method call)
- Non-string built-in primitive types like numbers, booleans, etc
- Strings
- Comments
- Types
Ultimately I think syntax highlighting is a tool to let you see mistakes. If you go too wild with the colors, it's true that since everything is a unique color, it's hard to tell when something is the wrong unique color. But you can use a relatively restrained palette and get a lot of value, and I think this post goes a bit too far in terms of reducing color usage.
I learned to code back when there was no syntax highlighting. You had one face, one font, one color on your 80x25 terminal. It might have been green, or amber, or white(ish) but that was it.
I'd prefer minimal-to-no syntax highlighting except for things that should NOT be there. Nonexisting keywords should be highlighted. Unclosed strings. Unbalanced parens or brackets.
I like making comments their own color so you can easily separate them from actual code but I'm otherwise in the minimal camp.
Your thoughts seem similar to mine. Going overboard with the colors just turns it all into visual noise. But cutting down as far as they have removes useful colors.
I've always thought the default Visual Studio color scheme was a nice balance. And I especially like the green comment color in that theme. It doesn't scream for your attention but also doesn't fade into the background (which, annoyingly, many themes do quite literally).
Of course if the author prefers their extra minimal colors I'm not going to tell them they're wrong. Though framing it as objectively better I do disagree with.
> But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually!
Yeah I generally want the opposite. I want keywords to be the thing being highlighted.
I also really dislike overly colorful themes, and I prefer light mode (dark mode is far too hard on my eyes, oddly enough I have to strain to focus or it's fuzzy).
But the author's alabaster theme still highlights the wrong things and is inconsistent.
public async Task<byte[]> SomeMethodName(Type param, Type param) results in Task, SomeMethodName, and BOTh the data type and parameter name being highlighted.
If highlighting isn't for keywords, why is Task and the data types highlighted?
likewise var result = await SomeMethodName(param, param); has result and SomeMethodName highlighted and I generally want the opposite, I want the PL's keywords highlighted and nothing else.
I prefer dark mode (precisely for the garish colors, sorry), but been using light mode... because it's hard to make everything use dark mode!
When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful. Yes, it's super simple for websites to detect the preferred color scheme with @media (prefers-color-scheme: dark) {}, yet most (such as this one) don't. I could use some hacks, but then I'm in for a world of pain. So I just use light theme everywhere and it's ok(ish).
> When my terminal was dark, the eg some docs in the browser were light, switching back and forth was quite painful.
I do this all the time (even at night without lights) with no problem at all. The key is to have properly set brightness/contrast on your monitor and gamma correction.
It can achieved by setting the brightness to a minimum (and use the contrast setting to go even lower, or even combine it with GPU settings in addition to monitor settings). It is also important to set a proper gamma correction so that darker/lighter levels don't have too big contrast.
The gamma correction needed can be measured by comparing the apparent thickness of antialiased text in black-on-white vs white-on-black color combinations that you toggle between. Once it is the same you get the right value. For example it's 1.3 on my LCD.
I was like this for a long time, but Dark Reader for Firefox and the default OS dark modes are good enough now I'd rather once in a blue moon fiddle with Dark Reader to correct a bad auto-color-assignment than put up with light mode in my browser and terminal overall. Just a thought. Until the last ~2 years, with win11, latest Linux desktops, and recent macOS all facilitating the change (if i couldn't do it everywhere i might still not do it, y'know? But they all actually work pretty reliably now)
I got started with Notepad on Windows, did that for almost a decade before switching to Linux and learning how to use vim. Definitely prefer the rainbow highlighting to going back to anything close to that.
For example: keywords, specifically, are actually very useful to highlight. This post complains that misspelling "return" didn't make easily-scannable color changes (it changed the color from purple to red, which still looks like a special color)... But then, proposes to not highlight keywords at all, so misspelling "return" would still be impossible to quickly scan for visually! In both cases with the proposed color scheme, "return" and "retunr" would have identical coloring: white.
Generally speaking I think a lot of the visual noise of syntax highlighting comes from having too many colors. For example, you don't need the "class" keyword to have a different color than the "const" keyword — and many syntax highlighting themes are guilty of doing exactly that. But it's useful to be able to immediately, visually see if you made a typo: if you expected to write a keyword, and it's colored like normal text, you know you messed up. Similarly, it's useful when reviewing code to quickly be able to tell whether there's a typo somewhere.
I have a pretty custom syntax highlighting theme for Neovim. I have a few categories that are highlighted differently:
- Keywords
- Function calls and method calls (highlighted identically)
- Property accesses (to highlight mistakes when you're simply accessing a property instead of calling it — it's a different color than a method call)
- Non-string built-in primitive types like numbers, booleans, etc
- Strings
- Comments
- Types
Ultimately I think syntax highlighting is a tool to let you see mistakes. If you go too wild with the colors, it's true that since everything is a unique color, it's hard to tell when something is the wrong unique color. But you can use a relatively restrained palette and get a lot of value, and I think this post goes a bit too far in terms of reducing color usage.