Rendered at 10:56:38 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
wzdd 47 minutes ago [-]
These rethinking-highlighting posts always start out with the wrong premise. The color for class names in my code is the color all the class names have. After a short time working with the code I would notice if one looked off.
The brain is really very efficient. You don’t optimise for random out of context recall unless you really try hard to do so. It says nothing about the efficacy of the scheme.
sph 3 hours ago [-]
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.)
flexagoon 2 hours ago [-]
> 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.
skydhash 15 minutes ago [-]
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.
my-next-account 2 hours ago [-]
>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.
sph 1 hours ago [-]
Yeah, I forgot to mention them, they're pretty good (though I use the muted colour preset, the default one is too vibrant)
embedding-shape 2 hours ago [-]
> 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! ;)
sph 1 hours ago [-]
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
34 minutes ago [-]
chrismorgan 2 hours ago [-]
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.
FridgeSeal 25 minutes ago [-]
I couldn’t tell you what colour my functions or structure syntax is, but I can tell you when I look at code, that the presence of the colour instantly lets me straight to whatever part of the text I care about at that moment.
noxss 2 hours ago [-]
In my case, colors matter because they help me read faster the keywords of a language that define algorithms such as conditionals, loops, beginnings and ends of functions, returns... without color it is more difficult to send the eye to the correct position. Perhaps it's due to habit or visual memory?
Good article that gives you food for thought
pasc1878 2 hours ago [-]
I found this site very difficult to read and I had to give up as it was hurting – the font is unreadable.
As for syntax highlighting – I don't like it either.
I use themes that change colour according to their nesting level.
econ 23 minutes ago [-]
I thought about nesting level coloring but had never seen it in action. I just look at it and it indeed looks nice.
I thought it would be interesting as it separates that what repeats a task from the actual work being done on it.
More nesting suggests more complexity.
In my experiments I notice different ways to write something look better with different kinds of highlighting.
If you for example use no highlights dividing the logic over tiny functions looks quite readable.
In one experiment I use dark colors on a black background with only the comments in bright white. I wrote a lot more comments using that. Everything had a description and I could gaze over it as if the code wasn't there.
burticlies 4 hours ago [-]
I like highlighting only the language concepts:
Reserved words are red
Strings are green
Constants/numbers are blue
Types/meta-language are yellow
Anything else is white.
It’s not too colorful but still gives you plenty of anchors for your eyes.
weinzierl 2 hours ago [-]
What about comments? Do you prefer comments to stand out or stand back?
polyterative 2 hours ago [-]
I prefer mine to have low emphasis because sometimes comments lie
Valodim 2 hours ago [-]
Good article, enjoyed it. I might give this idea a shot!
> Comments: these contain high level descriptions (faster than reading the code) and external context (the “why” that reading code can’t answer). This is the most scannable thing in any big code file.
Not sure about that one, depending on comment culture. Comments are prose and not structured, so to understand their meaning is a lot more cognitive load for me than (most) code. I certainly wouldn't have thought to call them "scannable".
econ 13 minutes ago [-]
I switch if the code is very ugly and unreadable. Often overly optimized things. One jumps to mind when I rewrote something to generate regexes.
Lindby 46 minutes ago [-]
I totally agree with you about the comments. Code is so much easier to grok. The comments are there as a reference that you can concentrate on if the code doesn't make sense to you.
nelsonfigueroa 2 hours ago [-]
I went through a similar journey not too long ago. I also asked myself "Why does highlighting even need to be in color?" when reworking my blog. I wanted a monochromatic look for my entire site, including code blocks. I noticed code blocks are still very readable as long as there's different tones. I still like pretty colors so I compromised by doing normal syntax highlighting when a code block is hovered over (or tapped on mobile).
Btw the dynamic highlighting by clicking on the code is so cool. I may or may not steal that idea ;)
0xjei 1 hours ago [-]
lovely takes! even if the percentage of techies who reads & codes effectively outside coding agents is way way smaller; I think it would be cool to apply this for reading diffs! there might be some adjustments but, I might end up trying to apply principles on top of diffs (https://diffs.com/)!
KronisLV 3 hours ago [-]
Cool article, really cool website (the font could also be a bit smaller, if it didn't mess with the fidelity), but the grayscale setup just doesn’t have enough contrast for my eyes to reliably pick up on it at a glance.
dainank 2 hours ago [-]
Maybe I missed it but has he posted his theme anywhere (I assume for VSCode since he mentioned he is using that)?
WhyIsItAlwaysHN 4 hours ago [-]
The continue keyword is also important, or alternatively the condition to run it.
I often fail to notice it on the first look of some snippet of code
cauliflower99 3 hours ago [-]
Really enjoyable read - well done! I wonder where else we could use an effective, minimal approach that solves the problem at first principles?
vova_hn2 1 hours ago [-]
Sorry, but I think that this is a completely made up problem. I've checked out the referenced Tonsky's article [0] and for me "colorful" examples are much easier to read than his suggested alternative.
Also, I had to use reader view for TFA because of this silly pixelated font. Ironic, considering that the article is about readability.
Of course it's a made up problem, most ultimately are. Programming (and life) are full of bike sheds for those with eyes to see them, does that mean they should not be painted?
tefkah 4 hours ago [-]
i’m surprise by how much i liked that! also: neutrality website, very tasteful
epolanski 2 hours ago [-]
> Why does highlighting even need to be in color?
I wrote a vscode extension for effect-ts authoring that indeed leverages this concept.
It adds underlines and/or bolder fonts to emphasize different functionality.
applfanboysbgon 3 hours ago [-]
I will always yap to anyone who will listen that I think syntax highlighting was a mistake that has cost humanity untold millions of productivity hours. I only highlight comments to distinguish code from not-code, I think everything else is a pretty distraction. Note how nobody ever got the idea to apply syntax highlighting to English or any other natural language, whether in books or on forums. I could believe syntax highlighting helps learn to distinguish things when you're new to programming, but for experienced readers syntax parsing happens as automatically as it does in natural language without any need of colors.
lexicality 40 seconds ago [-]
> Note how nobody ever got the idea to apply syntax highlighting to English or any other natural language
Yes they have? It's a fairly common method of teaching children sentence structure.
Pedagogy aside, take a look at what books looked like before the printing press.
> for experienced readers syntax parsing happens as automatically as it does in natural language without any need of colors.
If you're reading slowly, yes. The colours help you skim-read.
Why do you feel the need to intentionally hobble yourself? The human eyes can take in a spectacular amount of visual information at a glance, using colour, texture, shape and so on to instantly classify and identify things.
Decades of visual design research have proven that colours and shapes improve understanding and you're using a device capable of complex and rich information display, but you want it to look like a book because ..?
atiedebee 2 hours ago [-]
The article touches upon this:
> Unlike prose, where you usually read it linearly, with code you bounce around based on what connected elements you are exploring.
The moment you are jumping around a lot while reading, being able to understand the structure quickly becomes a major help. For example, dictionaries will have the words in a bold font while italicizing things like the plural etc.
applfanboysbgon 1 hours ago [-]
The punctuation/indentation already give you structure, all the highlighting does is break up the flow of actually reading. It essentially forces a micro-reset every second or third word rather than allowing you to seamlessly scan to find what you're looking for. It looks unreadable on the blog post because they have an unreadable font that is way too spacey (nothing against pixel fonts, just their particular choice of one...), but it really is way easier to read code if you try no highlighting with a real font.
I will caveat this on the fact that I use Allman brackets, and have even stronger opinions about that. K&R brackets are cancer and completely destroy the structure of code, so maybe that's why some people feel highlighting is necessary for "structure". With allman brackets, the punctuation guides your eyes to the indentation forming a clean box around each level of code, while if you draw a line from the opening bracket to the closing bracket with K&R style, half the code will be inside it and half outside it, bisecting the natural structure.
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.)
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.
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 think Prot's Emacs themes are good for this.
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 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.
Good article that gives you food for thought
As for syntax highlighting – I don't like it either.
I use themes that change colour according to their nesting level.
I thought it would be interesting as it separates that what repeats a task from the actual work being done on it.
More nesting suggests more complexity.
In my experiments I notice different ways to write something look better with different kinds of highlighting.
If you for example use no highlights dividing the logic over tiny functions looks quite readable.
In one experiment I use dark colors on a black background with only the comments in bright white. I wrote a lot more comments using that. Everything had a description and I could gaze over it as if the code wasn't there.
Reserved words are red
Strings are green
Constants/numbers are blue
Types/meta-language are yellow
Anything else is white.
It’s not too colorful but still gives you plenty of anchors for your eyes.
> Comments: these contain high level descriptions (faster than reading the code) and external context (the “why” that reading code can’t answer). This is the most scannable thing in any big code file.
Not sure about that one, depending on comment culture. Comments are prose and not structured, so to understand their meaning is a lot more cognitive load for me than (most) code. I certainly wouldn't have thought to call them "scannable".
Btw the dynamic highlighting by clicking on the code is so cool. I may or may not steal that idea ;)
I often fail to notice it on the first look of some snippet of code
Also, I had to use reader view for TFA because of this silly pixelated font. Ironic, considering that the article is about readability.
[0] https://tonsky.me/blog/syntax-highlighting/
I wrote a vscode extension for effect-ts authoring that indeed leverages this concept.
It adds underlines and/or bolder fonts to emphasize different functionality.
Yes they have? It's a fairly common method of teaching children sentence structure.
Pedagogy aside, take a look at what books looked like before the printing press.
> for experienced readers syntax parsing happens as automatically as it does in natural language without any need of colors.
If you're reading slowly, yes. The colours help you skim-read.
Why do you feel the need to intentionally hobble yourself? The human eyes can take in a spectacular amount of visual information at a glance, using colour, texture, shape and so on to instantly classify and identify things.
Decades of visual design research have proven that colours and shapes improve understanding and you're using a device capable of complex and rich information display, but you want it to look like a book because ..?
> Unlike prose, where you usually read it linearly, with code you bounce around based on what connected elements you are exploring.
The moment you are jumping around a lot while reading, being able to understand the structure quickly becomes a major help. For example, dictionaries will have the words in a bold font while italicizing things like the plural etc.
I will caveat this on the fact that I use Allman brackets, and have even stronger opinions about that. K&R brackets are cancer and completely destroy the structure of code, so maybe that's why some people feel highlighting is necessary for "structure". With allman brackets, the punctuation guides your eyes to the indentation forming a clean box around each level of code, while if you draw a line from the opening bracket to the closing bracket with K&R style, half the code will be inside it and half outside it, bisecting the natural structure.