While I'm aware that OP and I are in a minority - there is a cognitive overhead to having that information surfaced at all times when you may be trying to focus on something at e.g. the method level rather than the individual syntactic element level, and if that cognitive overhead exceeds the utility of having that information available, the sensible answer is to turn the highlighting off.

If I could have some sort of focus follows mind where highlighting automatically happens commensurate to what level of granularity I'm currently thinking about the code at I would be extremely interested, but absent "focus follows mind" it's a trade-off that everybody has to make for themselves.

Some people prefer to highlight almost everything, some almost nothing, some people find it helpful for some languages/tasks but not for others.

It's similar IME to the extent to which preferred debugging styles (printf versus interactive versus hybrid versus situational choices) are also something people have to figure out, and, well, different people are different, and that's neither a bad thing nor an avoidable thing.

I wonder if perhaps this is also a generational thing. Programmers from before syntax highlighting became popular would be less likely to prefer it, no? I’m not even sure if programmers from current/recent generations ever prefer not to have syntax highlighting, but I’m genuinely curious if there are such people out there.

I've known people who've started without synhi but wouldn't leave home without and people who started with rich synhi everywhere and now avoid it except for the first couple months of learning a new language, so it's certainly not just generational.

I would not at all be surprised if people who started off one way or the other (for generational reasons or indeed any 'whatever environment they were first introduced to' style reasons) are less likely to end up switching, but that probably says more about perceived switching costs as what would be most comfortable for somebody.

e.g. I know people who took a month to be comfortable without synhi but then loved that, and I've spent weeks trying to be more comfortable -with- and given up, and honestly anything that half screws your productivity for over a week is going to be a hard sell even if the end result -would- be better (waves in "also, still can't manage to drive emacs" ;)

I grew up with fully fledged syntax highlighting, but I still prefer to use really minimal themes as I find them to reduce cognitive overhead and eye strain.

It was hard for the first few hours, but then I eventually got used to it, and now I can't use anything else.

I know this is not quite as extreme as working without syntax highlighting :)

I started before syntax highlighting became widely used (in the Emacs 18 era), but was super-excited for syntax highlighting when it became available (Emacs 19 and XEmacs), and probably went overboard with it. These days, I prefer minimal syntax highlighting.

Not sure which editor I'm thinking about, but I do remember the exact feature you're describing implemented in one I used a while ago.

Ie, the paragraph (or block of code) your cursor is focused on is visible, the rest of the code is blurred out.

I recall that as well, my guess would be Sublime Text. Ah, it might have been this plugin for Atom, I was using that for a while:

https://github.com/davidleghorn/atom-focus-mode

Edited to add that I found this for VS Code which I might try:

https://marketplace.visualstudio.com/items?itemName=imagio.v...

I think I met this feature specifically in an editor made specifically for markdown and markdown only.

Although I can definitely imagine this being a plugin in different editors

The IDE could temporarily turn off all syntax highlighting outside the node that has the cursor.

Where the cursor is and where my mental focus is don't necessarily match, and it's really the granularity problem - expression level versus statement versus block versus etc. that causes 'mismatch between highlighting and focus' for me at least.

It certainly sounds like an experiment that would be interesting to try, though.

The way I see it, most syntax highlighting is actively adding mostly irrelevant information to the cognitive load of programming: stuff that should be obvious if you know the language. It does as little for my understanding as a novel in which, say, every proper noun was printed in red.

I can imagine more useful highlighting than color coding the types of the symbols encountered. Lighting up the active scopes. Giving the same hue to names that look like each other. There are probably highlighters out there that do that. But "simple" syntax highlighting is still the norm.

The same argument could be made for seeing anything in colour:

> most colours are actively adding irrelevant information to the cognitive load of existing. It should be obvious that apples and red and the sky is blue.

That’s silly, because it does add relevant information. Obviously it’s a spectrum - too many colours can hide information, but when used appropriately it’s fine.

Also everyone is different. Perhaps your brain gets distracted by the colours more than the majority of people.

> Lighting up the active scopes

As you had guessed a little later, there are a few different emacs packages that do this. One of them is "rainbow parentheses" that gives every bracket a different colour (remember that emacs supports lisp, so differentiating between lots of different parentheses is arguably more useful in emacs than any other editor). [0].

Another one is highlight parentheses [1] which highlights all parens that enclose the cursor position, and gives a darker colour to those "further away" from the cursor.

[0] https://github.com/Fanael/rainbow-delimiters

[1] https://sr.ht/~tsdh/highlight-parentheses.el/

> Giving the same hue to names that look like each other.

Emacs' 'Rainbow Identifiers' does that. I like it.

    https://github.com/Fanael/rainbow-identifiers

Define relevant