I’m very glad the conversation is about the quality of syntax highlighting, and not yet another “syntax highlighting sucks because I chose a particularly garish example to demonstrate this point”! More of that please!
Jumping on the reduced-color theme bandwagon: For the last several years I’ve been using — and iteratively modifying —a theme called minimal-light. I’ve diverged far enough from the original that I renamed it:
Nice one. Personally for my own taste I’d have probably formatted the comments a shade of gray, but red looks pretty nice too.
For what it’s worth, this is what I’m currently using (screenshot) and I like it a lot, but sometimes it does feel too colorful. I might take your theme for a spin.
Hah!, you see, the intense redness is the entire idea behind my theme. The original (which I can no longer find on the Internet) used the more common approach: there are 2 visual layers, and comments are in the less visible layer, greyed out.
I find that putting comments in the visual background leads to programmers a) ignoring the comments that are already there; b) tolerating superfluous, lengthy comments.
At a previous company, the ‘official’ code style policy involved huge comment blocks, which essentially included boilerplate easily found in the language manual, included in front of every function declaration. I figured one of the reasons people tolerated this bureaucracy is because they had comments ‘greyed out’ in their editors.
I definitely agree most themes highlight way too much. I’m using something like a stripped down gruvbox at the moment: http://imgur.com/a/sZaZP. I also highlight control structures though.
It’s hard to google for but I remember hearing about a language (ALGOL?) which specified a “typeset syntax.” Keywords are set in bold, identifiers in italic, etc. It seems that this could be a very readable sort of syntax highlighting as well.
Here’s a screenshot of my setup. I like to highlight just comments, literals (including strings), break/continue/return and references to key long-lived variables. In the screenshot, for example, highlighting caller_recipe helps to show that most of my logic just never cares about it. (It’s only needed for an error message deeper down the call stack.)
I’m very glad the conversation is about the quality of syntax highlighting, and not yet another “syntax highlighting sucks because I chose a particularly garish example to demonstrate this point”! More of that please!
Jumping on the reduced-color theme bandwagon: For the last several years I’ve been using — and iteratively modifying —a theme called minimal-light. I’ve diverged far enough from the original that I renamed it:
https://github.com/pzel/commentary-theme
Like the original poster, I don’t yet have all of the myriad
font-faces covered, but the theme does the job well enough for my own use.Nice one. Personally for my own taste I’d have probably formatted the comments a shade of gray, but red looks pretty nice too.
For what it’s worth, this is what I’m currently using (screenshot) and I like it a lot, but sometimes it does feel too colorful. I might take your theme for a spin.
Hah!, you see, the intense redness is the entire idea behind my theme. The original (which I can no longer find on the Internet) used the more common approach: there are 2 visual layers, and comments are in the less visible layer, greyed out.
I find that putting comments in the visual background leads to programmers a) ignoring the comments that are already there; b) tolerating superfluous, lengthy comments.
At a previous company, the ‘official’ code style policy involved huge comment blocks, which essentially included boilerplate easily found in the language manual, included in front of every function declaration. I figured one of the reasons people tolerated this bureaucracy is because they had comments ‘greyed out’ in their editors.
Interesting! That’s actually a very good reason. Thanks for the explanation on your choice of color.
That looks nice, thanks for posting it. Also, +1 for using Iosevka :)
I definitely agree most themes highlight way too much. I’m using something like a stripped down gruvbox at the moment: http://imgur.com/a/sZaZP. I also highlight control structures though.
I was not aware of gruvbox. I might migrate to it. I have been using material for a few years: http://imgur.com/a/fL30Q
It’s hard to google for but I remember hearing about a language (ALGOL?) which specified a “typeset syntax.” Keywords are set in bold, identifiers in italic, etc. It seems that this could be a very readable sort of syntax highlighting as well.
At first I scoffed, but actually I appreciate the thought he put into it. I’d say I’m convinced enough to give it a try for a week.
Here’s a screenshot of my setup. I like to highlight just comments, literals (including strings), break/continue/return and references to key long-lived variables. In the screenshot, for example, highlighting
caller_recipehelps to show that most of my logic just never cares about it. (It’s only needed for an error message deeper down the call stack.)To highlight specific variables I wrote this VimScript inspired by this demo.
It’d be interesting to have some sort of toggle-able highlighting where you can tell it to, for example:
Reminds me of an old post: https://github.com/robertmeta/nofrils/blob/master/README.md
I’d say the first example is far easier to concentrate on. Mainly because it’s, uh, not purple…
Hah :) I wanted a darkish theme, but didn’t want blue or black. The channel bar in Slack got me thinking that maybe purple could work.
each to his own then! :)
I might try making something like this for vim but with a black bg, I can’t really work with purple :shrug: