Hacker News Reader

Comment by jasonwatkinspdx | Hacker News Reader

I guess I may be an outlier here but I don't find any of those examples motivating at all. They make it harder for me to see the structure of the code at a glance.

Also I think it's a bit off the mark to think of it as being a wasted information channel. Redundancy is a feature of human languages, because our languages are not optimizing solely for density. A bit of redundancy helps our brains pattern match more consistently, almost like a form of forward error correction. Syntax highlighting is like that, at least for me, where it makes a big difference in seeing the structure at a glance, and more overly complex coloring rules thwart that for me. Like I don't want to be trying to match up rainbow shades of parens.

View on HN

In my experience, the biggest wins in syntax highlighting come from just a few wins: make comments a different color, make strings a different color, and if you've got something like shell where strings can contain embedded variable references, pop those variable references into a different color.

One of the big problems with a lot of the examples here is that, well, I spend most of my time on multimillion line codebases. If you want to pop stuff out to me, showing it in a different color is useless because it's not on the same screen; no, the way you give it to me is a macro that takes me to the next location of the thing of interest. And with a macro that lets me move to points of interest... the use of color is entirely redundant.

I've just installed a plugin in my emacs config the other day called dumb-jump[0]. The way it works is by running a grep tool (grep, git-grep, the_silver_search (ag), ripgrep) inside the current project with some patterns according to the file type. It hooks into emacs xref (dynamic links and history).

These days, I'm using very minimal highlighting (doric-themes [1] which is basically shade of one color and font-weight). I prefer to separate semantic units of code by whitespace. Then scanning becomes quick.

[0]: https://melpa.org/#/dumb-jump

[1]: https://elpa.gnu.org/packages/doric-themes.html

Moving to the next point of interest and highlighting all the occurrences are not mutually exclusive. In fact searches work like this in many apps.

I 80% agree with this, but I've also gotten a lot of mileage out of Emacs hi-lock mode. The simplest thing I always want: whatever symbol I'm pointing at right now, highlight everywhere (so I can trace it through the code quickly); more generally, I want to highlight an arbitrary regex, so for instance when I'm auditing a codebase for authorization, I quickly spot the functions that aren't following the same authorization patterns as all the others.

Oh I read it as modes that you'd toggle for specific tasks. I don't want the default coloring of my code to be paren matching, but I do when I'm getting confused and trying to match parens.

I like rainbow parentheses and this is already a common feature in code editors.

Every example past that was just worse for readability. I think you're right about density not being the only important metric here.

I think one important point in the article is being unnoticed: these special highlights would not be the default for reading code, but specific tools that the developer can turn on and off for when their use case is needed.

So, not much different than a search for regular expressions or a "show definition" tooltip

The rainbow braces thing is quite useful. It can save you a bit of bother counting. A lot of his other suggestions just seem like more general search things that should highlight matches the same way Ctrl+f highlights text in a web page.

Yeah, if that was my only option, I'd turn off highlighting entirely.

Reply on news.ycombinator.com