I am convinced everybody gets syntax highlighting wrong and this article backs me up.
My pet peeves:
- I have no idea how people are supposed to be productive with non-semantic rainbow vomit themes that are so popular in modern editors. I'm too ADHD to want to be overly stimulated by useless information.
- I routinely hate encountering Zig code on Github, where the theme they use turns everything brown. Oh it's because it's a struct member. Dude, everything is a struct member in Zig, it's silly to allocate a vibrant colour for what amounts to 90% of the source code. Random example off my browser history: https://github.com/foxnne/aftersun/blob/main/src/time/enviro...
- Yesterday I opened some Lisp code in KDE's KWrite text editor, and every single default theme highlights parens with a bold font + vibrant colour to make them stand out. Parens in Lisp are supposed to fade in the background, not pop in your face. It was completely unusable, I had to turn off syntax highlighting.
Always seeking good, minimal, muted colour themes for my editors. I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
I remember a colleague that used to write code with syntax highlighting off, and thought that was an eccentric choice. The older I get, the more I appreciate his wisdom. I'd rather have no syntax highlighting than bad one; at least one would try to make the code easy to parse by its structure alone (shorter lines, comments to delimit sections, etc.)
> | have no idea how people are supposed to be productive with non-semantic rainbow vomit themes that are so popular in modern editors. I'm too ADHD to want to be overly stimulated by useless information.
At least personally, I've been living with ADHD long enough to have had to learn to cope with the fact that even if I tried to suppress various stimuli in my environment, I'd still find something distracting. Pretty much all of life is filled with background noise for me, so having some of the syntax look noticeably different is not that much of a net increase to distraction for me. To you my color scheme probably looks like "rainbow vomit", but I like bright colors on a black background, and I'm the one who spends all day looking at it, so why should it matter whether you like it as well?
I'm color blind. Most color schemes just fuck up reading. Or they hurt my eyes. I haven't found anything that really convinces me, although having some words in bold does help, but the number should be quite limited. I can see the structure easily enough, so there's no need to emphasize "THERE'S AN IF HERE, IT IS A RESERVED KEYWORD!!".
> I have no idea how people are supposed to be productive with non-semantic rainbow vomit themes that are so popular in modern editors.
That depends on what your use for syntax highlighting is. If you use it to find specific types of code, than yeah, it's probably unhelpful. But for me, the point of syntax highlighting is to just make reading easier by separating different parts of the code with different colors. I have absolutely no idea what each color means in my editor, it just matters that they're different.
> I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
It's programmer art!
>Always seeking good, minimal, muted colour themes for my editors. I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
I think Prot's Emacs themes are good for this.
> Always seeking good, minimal, muted colour themes for my editors. I wish we had serious designers to design themes for usability and comfort, and not people that have no business playing with colours.
I want the same as you, but probably also the same as you; I'm too lazy to do it myself. Maybe do all of us an favor, and create that yourself and share it with us? I too prefer no syntax highlight than bad one, and most out there are bad, and you clearly grok a bit more than the typical color scheme creator/maintainer, so you're already 50% there! ;)
Maybe a decade ago, I decided to start a theme from scratch, named bland. Initially, it was just black on white, with keywords bold, comments, macro invocations and lifetime tokens (this was all focusing on Rust) italic, and escape sequences bold italic. I decided to wait a week before deciding if I would add any colours at all. As expected, after that week I made strings red, comments green and numbers blue. Since then, I’ve made number type suffixes light blue, macro-related things orange, and delimiters grey (I should try dropping that one again). But things like making type, async, function*, for, const, of, &c. different? No, they’re all just bold black, no need to try distinguishing between them.
I also subsequently made a dark variant of it for my website’s dark mode and for occasions I want to use an editor in a dark place.
The colours involved are all high-contrast, using the RGB channels provided rather than trying to be silly with low contrast: #fff, #000, #c00, #090, #00c to begin with.
But I have no particular interest in publishing this in a form others can consume in whatever editors they use. Plenty of small tweaks that I develop over time, half for my own Vim syntax files. I think the approach itself, of experimenting deliberately yourself, is worthwhile.
Completely with you. I've played with limited syntax highlighting in the past (class names were blue, to answer the question in TFA), but for the past few years I've been running with plain black-on-white, with only a green highlight for comments, and a subtle yellow for strings.
https://i.xkqr.org/lighttheme.png
I think the relatively bold highlighting of comments is important – lots of times I'm the only person to react to incorrect comments because people's themes blur them into the background and they stop reading them.
(But then again, I'm crazy. I colour diffs blue and orange: https://i.xkqr.org/blueyellowdiffs.png inspired by similar advice in https://jameshfisher.com/2014/05/11/your-syntax-highlighter-... I think it has worked to help me notice things other reviewers have not, but it's hard to know for sure.)