3 ms·

I'm going to try this because I love the concept. However I have doubts - part of the reason I use syntax highlighting is to... well, highlight important things

by junon 4y ago

I'm going to try this because I love the concept. However I have doubts - part of the reason I use syntax highlighting is to... well, highlight important things. Part of being able to skim code is to pick out the key words or symbols that denote control flow, important (exceptional, even) cases, etc. The dizzying array of identifiers is less important when trying to skim and pick apart the general "feel" of code quickly. In this pallette, at least with python, the identifiers are red, everything is "flat" (due to the perceptual brightness) and thus nothing really sticks out or gives me "grit" to hold on to when navigating around. I could be wrong. This is just my hypothesis going in. Cool project nonetheless, I love the idea to use color science as the basis for this.

maegul 4y ago
Feel the same way. I’ve made my own personal colour scheme over time by manually adjusting colours by eye (fun procrastination). Following personal and intuitive preferences this way has lead to a palette that is almost certainly not uniform but one that I mostly like. I suspect a useful tool would be one that starts with vision science based uniformities but that then enables personalised tweaks, ideally with vision science guidance. To your point, it matters what kind of tokens a colour is going to be used for. If they’re small (eg operators), then the effective perceptual uniformity is broken. They’ll be less conspicuous. Being brighter and more saturated would probably help. Perceptual salience can be tricky, and it’s useful to remember that our colour vision is flawed and finicky. Similarly but inverted for large tokens such as class names. Beyond that, once you start modulating saturation and brightness to get a nicer look, you’re back into a 3D colour space where the evenly spaced hues idea starts to make less sense, or so I suspect. Nonetheless, cool work! I would have liked to do the same if I was able!
- edwintorok 4y ago
  Try https://huetone.ardov.me/ https://huetone.ardov.me/ for a tool based on vision science guidance.
- bXVsbGVy 4y ago
  > Perceptual salience This is defined by luminance. This is the 'L' in Lab and OKLab (and in their polar representation: LCH and OKLCH).
- solasluaith 4y ago
  My base assumption was to treat code like text and you’re right, this means that smaller tokens are not as salient as larger ones. But if you really wanted to go down that rabbit-hole you’d ideally have to adjust each token individually according to its size, including font size, physical display size and potentially even take into account glyph differences between typefaces. Given the way that themes are currently implemented, I thought making this simplification was reasonable. If you’re not dead set on the hard constraints I was aiming for, the tool linked below looks great for your purpose though, except it should really be using OKlab instead of CIELab.
gmiller123456 4y ago
I use syntax highlighting is to... well, highlight important things. I think "syntax highlighting" is a bit of a misnomer, "syntax coloring" might be better. Since some type of styling is done to pretty much all code in most of the common themes, you really can't say it's highlighting everything. One principle of design is that in order to emphasize something, other things have to not be emphasized. The syntax coloring just increases the contrast of similarly weighted things.
- solasluaith 4y ago
  Exactly, the fundamental assumption that I’m making is that all code should have the same level of emphasis — like a regular text — while maintaining the ability to scan for categories of words. If someone disagrees with that assumption, the palette will not work for them.
scratcheee 4y ago
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.

by junon 4y ago

maegul 4y ago

Feel the same way. I’ve made my own personal colour scheme over time by manually adjusting colours by eye (fun procrastination). Following personal and intuitive preferences this way has lead to a palette that is almost certainly not uniform but one that I mostly like. I suspect a useful tool would be one that starts with vision science based uniformities but that then enables personalised tweaks, ideally with vision science guidance. To your point, it matters what kind of tokens a colour is going to be used for. If they’re small (eg operators), then the effective perceptual uniformity is broken. They’ll be less conspicuous. Being brighter and more saturated would probably help. Perceptual salience can be tricky, and it’s useful to remember that our colour vision is flawed and finicky. Similarly but inverted for large tokens such as class names. Beyond that, once you start modulating saturation and brightness to get a nicer look, you’re back into a 3D colour space where the evenly spaced hues idea starts to make less sense, or so I suspect. Nonetheless, cool work! I would have liked to do the same if I was able!

edwintorok 4y ago
Try https://huetone.ardov.me/ https://huetone.ardov.me/ for a tool based on vision science guidance.
bXVsbGVy 4y ago
> Perceptual salience This is defined by luminance. This is the 'L' in Lab and OKLab (and in their polar representation: LCH and OKLCH).
solasluaith 4y ago
My base assumption was to treat code like text and you’re right, this means that smaller tokens are not as salient as larger ones. But if you really wanted to go down that rabbit-hole you’d ideally have to adjust each token individually according to its size, including font size, physical display size and potentially even take into account glyph differences between typefaces. Given the way that themes are currently implemented, I thought making this simplification was reasonable. If you’re not dead set on the hard constraints I was aiming for, the tool linked below looks great for your purpose though, except it should really be using OKlab instead of CIELab.

gmiller123456 4y ago

I use syntax highlighting is to... well, highlight important things. I think "syntax highlighting" is a bit of a misnomer, "syntax coloring" might be better. Since some type of styling is done to pretty much all code in most of the common themes, you really can't say it's highlighting everything. One principle of design is that in order to emphasize something, other things have to not be emphasized. The syntax coloring just increases the contrast of similarly weighted things.

solasluaith 4y ago
Exactly, the fundamental assumption that I’m making is that all code should have the same level of emphasis — like a regular text — while maintaining the ability to scan for categories of words. If someone disagrees with that assumption, the palette will not work for them.

scratcheee 4y ago

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.