Hacker News Reader

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

I get the origins of low contrast comments - auto-generated stuff in old Java code was basically a box ticking exercise to please checkers that only checked if comments were available, probably for javadoc purposes, making these comments useless noise.

But that's only Java, and I want to believe most people moved away from box ticking exercises like javadoc blocks. Comments should be important and thus high contrast.

Thanks for sharing I love this theme. Implementing it now this morning and really appreciate the middle ground between no highlighting and the popular rainbow chaos themes.

Agreed 100% on highlighting the comments, that's what I also prefer and many themes still get wrong.

> | 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 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’ve been using vi (nvi) and mg and both doesn’t have syntax highlighting. I’ve copied a monochrome theme of github for my vim setup and my emacs config is using modus operandis which is somewhat minimal and muted.

While I can use rainbow color, but this day syntax highlighting kinda fades into the background as I don’t care that much. I like it for something like React and html for the tags part but indentation is much better than highlighting in my opinion.

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

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

Yeah, I forgot to mention them, they're pretty good (though I use the muted colour preset, the default one is too vibrant)

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

I have a crappy Emacs theme I built myself, inspired by Jon Blow's Emacs theme he uses on his stream which I find very peaceful to look at, but with a more bluish/indigo hue. It's full of bugs, so not comfortable sharing honestly, but I think it's worth spending an afternoon creating your own

I like pastel colors as well. So I use a GNOME extension that controllably mutes all colors on the screen. Makes my screen almost look like a color e-ink display. Muting it to an extreme makes it grayscale.

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.