5 ms·

It's really "syntax classification by color" rather than highlighting. The goal is to make related parts of syntax the same color so the brain doesn't have to h

It's really "syntax classification by color" rather than highlighting. The goal is to make related parts of syntax the same color so the brain doesn't have to handle the classification itself (which it's bad at and will short circuit and get wrong sometimes, and take too long other times), sp the goal should usually be to just differentiate parts, not to emphasise/highlight parts (though emphasising code over comments is fairly justifiable, I admit).

solasluaith 4y ago
Thank you for this succinct explanation, that’s pretty much exactly what I was aiming for! Would you be okay with me adapting the explanation for the README at some point?
- scratcheee 4y ago
  Feel free!
Sharlin 4y ago
"Semantic highlighting" might be an interesting concept to study further. As in, annotated or (semi)automatic highlighting of "pay extra attention while reading" parts of code – tricky, nonobvious, mem/thread-safety critical sections, code that assumes invariants or is responsible for their maintenance, and so on. Some existing examples are "warning squiggles" added by IDE integrated linters, as well as language-level syntactic markers for "here be dragons" parts like Rust’s `unsafe {}` that can be highlighted by standard syntax highlighters (as an aside, it occurs to me that for simplicity’s sake most syntax coloring is in fact merely lexical coloring, but I digress…) It seems to me that many color schemes these days choose to render comments in grayed-out, low-contrast colors. I find this to defeat the purpose of comments and maintain the unfortunate notion that they are something nearly redundant. A properly written comment tells me something nonobvious and should be displayed prominently rather than faded into obscurity!
- solasluaith 4y ago
  I absolutely agree that intelligent highlighting or added emphasis to at least some part of the code is very worth investigating. I would argue it should probably be used more sparingly than colouring, but could be complementary. By combining the colours from the base and the contrast++ palette this would even be possible with Penumbra while maintaining the clean separation between colour properties. In this area, as a novice coder, I am absolutely out of my depth though, so I’d have to defer to actual experts for the implementation. Someone else brought up a similar point on comment emphasis but I’ve seen the opposing opinion too.
- siraben 4y ago
  Tree-sitter[0] can provide semantic highlighting and I've been using it with all the languages I program in, including writing my own grammar[1] for a language that didn't have syntax highlighting. The improvement in readability is a quantum leap, because colors actually have semantic meaning rather than just being eye candy. With the situations you describe, you can write tree-sitter queries to make unsafe code highlighted in a different color, for instance, or highlight specific anti-patterns. [0] https://tree-sitter.github.io/tree-sitter https://tree-sitter.github.io/tree-sitter [1] https://github.com/siraben/tree-sitter-formula https://github.com/siraben/tree-sitter-formula
platz 4y ago
The original scheme that made me realize this should always be the goal was Steve Losh's BadWolf [1] Control flow & operators etc are dark red, identifiers more or less neutral, and top level functions accented. This makes it easy to scan quickly, because you want to be able to navigate a file quickly without getting bogged down in a rainbow of color and then slow down down to understand the tricky bits. Just reading the comments provided a lot of insight on things like accent color usage. Im very used to warm colors now so Gotham is the closet spiritual thing in VSCode to this. [1] https://github.com/sjl/badwolf/ https://github.com/sjl/badwolf/ https://raw.github.com/sjl/badwolf/master/colors/badwolf.vim https://raw.github.com/sjl/badwolf/master/colors/badwolf.vim
strainer 4y ago
I read code which is not highlighted with little want for color, except certain cases like mixed php and html where I find it really helpful to have the two separated into different hues eg. green/blue and yellow/red. So I find the trend for color schemes with many lexical types colored differently, unpleasant to the eye and usually of little practical advantage. The more different things we try to distinguish in a color theme, the harder it is to produce a comfortable aesthetic and the harder it is to make things which should advance or retreat from the eye, to do so. Keywords can take pleasant color slots which are not the most easily read, because their color confirms they are typed correctly. There is little advantage and much overhead in theming keywords of different types differently. Strings types can all share a hue similarity with small difference to help notice single or double quotes etc. Escaped chars are good to stand out a bit, within the appropriate quotation hue. Comments should be in color range which retreats from the eye a little and is well separated from the executable hues. I feel its all window dressing, plain text is just a little harder to scan for things than nicely syntax highlighted. Busy, un-finessed syntax highlighting is more of a quirk to be tolerated than it is a comfort.

solasluaith 4y ago

Thank you for this succinct explanation, that’s pretty much exactly what I was aiming for! Would you be okay with me adapting the explanation for the README at some point?

scratcheee 4y ago
Feel free!

Sharlin 4y ago

"Semantic highlighting" might be an interesting concept to study further. As in, annotated or (semi)automatic highlighting of "pay extra attention while reading" parts of code – tricky, nonobvious, mem/thread-safety critical sections, code that assumes invariants or is responsible for their maintenance, and so on. Some existing examples are "warning squiggles" added by IDE integrated linters, as well as language-level syntactic markers for "here be dragons" parts like Rust’s `unsafe {}` that can be highlighted by standard syntax highlighters (as an aside, it occurs to me that for simplicity’s sake most syntax coloring is in fact merely lexical coloring, but I digress…) It seems to me that many color schemes these days choose to render comments in grayed-out, low-contrast colors. I find this to defeat the purpose of comments and maintain the unfortunate notion that they are something nearly redundant. A properly written comment tells me something nonobvious and should be displayed prominently rather than faded into obscurity!

solasluaith 4y ago
I absolutely agree that intelligent highlighting or added emphasis to at least some part of the code is very worth investigating. I would argue it should probably be used more sparingly than colouring, but could be complementary. By combining the colours from the base and the contrast++ palette this would even be possible with Penumbra while maintaining the clean separation between colour properties. In this area, as a novice coder, I am absolutely out of my depth though, so I’d have to defer to actual experts for the implementation. Someone else brought up a similar point on comment emphasis but I’ve seen the opposing opinion too.
siraben 4y ago
Tree-sitter[0] can provide semantic highlighting and I've been using it with all the languages I program in, including writing my own grammar[1] for a language that didn't have syntax highlighting. The improvement in readability is a quantum leap, because colors actually have semantic meaning rather than just being eye candy. With the situations you describe, you can write tree-sitter queries to make unsafe code highlighted in a different color, for instance, or highlight specific anti-patterns. [0] https://tree-sitter.github.io/tree-sitter https://tree-sitter.github.io/tree-sitter [1] https://github.com/siraben/tree-sitter-formula https://github.com/siraben/tree-sitter-formula

platz 4y ago

The original scheme that made me realize this should always be the goal was Steve Losh's BadWolf [1] Control flow & operators etc are dark red, identifiers more or less neutral, and top level functions accented. This makes it easy to scan quickly, because you want to be able to navigate a file quickly without getting bogged down in a rainbow of color and then slow down down to understand the tricky bits. Just reading the comments provided a lot of insight on things like accent color usage. Im very used to warm colors now so Gotham is the closet spiritual thing in VSCode to this. [1] https://github.com/sjl/badwolf/ https://github.com/sjl/badwolf/ https://raw.github.com/sjl/badwolf/master/colors/badwolf.vim https://raw.github.com/sjl/badwolf/master/colors/badwolf.vim

strainer 4y ago

I read code which is not highlighted with little want for color, except certain cases like mixed php and html where I find it really helpful to have the two separated into different hues eg. green/blue and yellow/red. So I find the trend for color schemes with many lexical types colored differently, unpleasant to the eye and usually of little practical advantage. The more different things we try to distinguish in a color theme, the harder it is to produce a comfortable aesthetic and the harder it is to make things which should advance or retreat from the eye, to do so. Keywords can take pleasant color slots which are not the most easily read, because their color confirms they are typed correctly. There is little advantage and much overhead in theming keywords of different types differently. Strings types can all share a hue similarity with small difference to help notice single or double quotes etc. Escaped chars are good to stand out a bit, within the appropriate quotation hue. Comments should be in color range which retreats from the eye a little and is well separated from the executable hues. I feel its all window dressing, plain text is just a little harder to scan for things than nicely syntax highlighted. Busy, un-finessed syntax highlighting is more of a quirk to be tolerated than it is a comfort.