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, 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.)

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 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.

>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! ;)