This kind of nibbles at the edges of the longstanding question: Whether source code is best represented as a linear document.<p>Because historically, that was true for the obvious reasons of pragmatism; you could put it on a punchcard, print it to paper, save it to a file all using the same character encoding and rendering methods, and when we went to interactive editing that didn't change: half of the joy of plaintext is that you can select, copy, paste, search and modify in mostly standard ways across many tools.<p>Syntax highlighting is incrementally in line with this paradigm since there's only one syntax for the language(syntax extension and mixed-language documents aside) and it too follows a linear order, although it also recognizes that an AST exists. But as you get into stuff like code folding, Intellisense and other IDE-like features, deviations emerge. More of the selections deal with symbolic meanings(declarations, types) and not really the tokens or the characters they consist of, and only incidentally the delimiters of the AST.<p>But - when we try to fully re-envision it and express these other concepts directly we tend to end up with something that is unfamiliar, a bit clunky and alienating(most graphical languages). So the accepted developments always seem to come in these little ideas that are mostly-optional add-ons.<p>Chuck Moore did use semantic color as a language feature in ColorForth, but his specific goals lean towards a holistic bootstrapping minimalism, so I haven't seen it taken up elsewhere.
I don't buy it.<p>1. I personally find syntax highlighting incredibly helpful as a way of setting off syntactic elements, and incidentally as a way of calling attention to typos (like a missing quote or misspelled keyword). The author seems to dismiss this without any analysis.<p>2. Using color for syntax highlighting doesn't mean you can't <i>also</i> use color to highlight other useful things (like search results or errors), as the author suggests. Many editors which support syntax highlighting do exactly this!<p>3. The author's examples aren't particularly compelling. For example, using colors to denote levels of nesting will make code flash between colors as you edit it. Highlighting variables by type feels like a form of syntax highlighting, not something new, and most of the examples of highlighting code which meets specific conditions (variables which are assigned to multiple times, long functions, functions without documentation, etc) all feel like they could be summarized as "linter warnings/failures".
Some people are reacting to the (clickbait-y) title, which is a more extreme statement than what the author ends up advocating. The ultimate argument is that it's ok to syntax highlight sometimes, but sometimes it might be helpful to use color in other ways.<p>Personally, I find syntax highlighting to be very useful, but I also agree that using color in other ways can be more useful at times. As it happens, syntax highlighting was one of the inspirations for the color gradient text pattern I developed to make reading on screen easier. [1] The existence of syntax highlighting helped me to think about color in text as an information channel that can be used to make certain tasks more efficient, so I'm very grateful for that!<p>1: <a href="https://chrome.google.com/webstore/detail/beeline-reader/ifjafammaookpiajfbedmacfldaiamgg?hl=en" rel="nofollow">https://chrome.google.com/webstore/detail/beeline-reader/ifj...</a>
If you haven't before, I'd recommending giving Intellij's semantic highlight a look: <a href="https://blog.jetbrains.com/pycharm/2017/01/make-sense-of-your-variables-at-a-glance-with-semantic-highlighting/" rel="nofollow">https://blog.jetbrains.com/pycharm/2017/01/make-sense-of-you...</a><p>Every variable name is assigned its own color, so you can track the data dependencies in your function using color. Similar to what the author suggests as "Type Highlighting"<p>Some might consider it distracting/overstimulating, but I find it both useful and it makes the code look a bit more 'artistic'.
VSCode semantic highlighting is mentioned by the author, and it does support these type of use cases. It works by first doing normal syntax highlighting, then asynchronously getting the semantic info for semantic highlighting, since it's a much slower process.<p>The current language-specific implementations do use it to just augment the syntax highlighting, since that is what is what most people would expect. But out of the box it already supports some use cases the author mentioned, such as different highlighting for imports or constants. The full AST and type info can be used for this (depending on the language server), so pretty-much anything is possible.<p>What I personally find very useful (and had to hack experimental support for) is highlighting of TypeScript async/Promise values and functions. This is something that a language server can identify easier than humans, and can make a big difference in coding.
Too much color ends up overwhelming. I can find the red circle super quick because it's the only red thing in a sea of black and white.<p>But I like the idea of going beyond syntax. Maybe a way to get the best of both worlds would be to have keyboard shortcuts that toggle cycle through different views. Press this shortcut to color-code types, press this other one to color-code error handling, etc.<p>Also, maybe other visual depictions might be useful. Maybe parentheses could start off very tall and get slightly shorter as you go a layer inward. Or add a 3D/depth shading effect so that code each level of parens literally looks like a level. Or whatever else you can think of, the point being that it doesn't have to be color.
I think too much syntax color is an easy way to shoot yourself in the foot as a developer. When everything is highlighted, and everything is important, nothing is important.<p>We need to choose what is important, I like to highlight language keywords as grey, function names as blue and numeric values / strings as purple / green. Everything else is white, and it works great.<p>tree-sitter[0] should end regex-based syntax highlighting, check this out for nvim: <a href="https://github.com/nvim-treesitter/nvim-treesitter" rel="nofollow">https://github.com/nvim-treesitter/nvim-treesitter</a><p>I really want to see tree-sitter used to power an awesome linter, that works across languages.
Visual Studio does semantic highlighting for at least C# (they call it enhanced highlighting). Static classes, parameters, internal structure of regex strings, etc. Basically anything returned by the Roslyn Classification API.<p>I personally like it, but I think other people feel that syntax highlighting plus semantic highlighting leads to rainbow soup.
Syntax highlighting shows something that's already visible. What could be highlighted that <i>isn't</i> already visible?<p>Undefined variables? Those really should get a squiggly underline, as with spell checkers. Some IDE probably does that already.<p>Anything more subtle?<p>A key point in language design and program tooling is detecting that thing A, which needs to be consistent with thing B far away in some other module, isn't. Most hard to find defects involve some distant relationship. What could be done with color or other automatic annotation to help?
A really good post, but problem 2 is the biggie here:<p>> What if something needs to be colored two things for two different reasons?<p>As another commenter points out, JetBrains already do a lot of the ideas this person has raised - but they do it in response to actions. Eg. Put the cursor next to one bracket, the matching bracket is highlighted.<p>I think the key to breaking this open is an editor that does different highlights at different times in response to user actions; the key will be getting the right user actions so this is seamless and easy to use.
I don't think this is suggested: highlight all uses of a field in a class, or a variable in a method.<p>IntelliJ does this for the field/variable under the cursor, with a background colour and a margin colour. I'd like to see what it would be like with all variables in their individual colours.
Good points in this post, although I'd add the word "Only" in front of the headline.<p>IMO, syntax highlighting definitely has its uses, but why limit ourselves to only using colors for that? I'd like to see a future, where depending on whether I'm, for example:<p>- sketching the structure for a completely new program,<p>- implementing a new feature to an existing program,<p>- refactoring an existing program,<p>- debugging a problem in my program,<p>- writing tests, or<p>- trying to find something for reference<p>I'd be able to seamlessly switch between different highlighting schemes. I don't (yet) know what I'd prefer for each of these different modes of software development. The author of TFA lists some ideas for some different ways of doing semantic highlighting. Maybe over the years I'd grow to like some of them for some of these tasks.
I'd like to see a <i>truly</i> flexible code display system that treats things as a matrix.<p>As the author describes, you have a number of possible concepts we might like to visually denote:<p>- Language constructs (ie, traditional syntax highlighting)
- Parentheses/bracket pairs
- Context highlighting
- etc etc etc.<p>The author considers a single "information channel", text color.<p>There are other possible, largely orthogonal, information channels.<p>- Text background color
- Font weight (light/bold/regular)
- Font face
- Font italic / upright
- Font underlines (single, double, dashed, bold, squiggle, etc)
- Font underline color?
- Perhaps font effects (shadow, blur, etc)
- The editor gutter (Sublime and others expose this)
- Hover state (ie, tooltips)<p>I'd like a text display system that lets me mix and match inputs and outputs, matrix style. Perhaps I'd like to use font weights to denote one concept, and underlines for another.<p>Perhaps I'd like to use standard text-color choice for language constructs ala traditional syntax highlighting, and text background color for "context" or "semantic" highlighting (where each variable gets a unique color within its scope)<p>It would most certainly be able to create some real visual nightmares with this level of control, but applied judiciously, it could be very valuable.
Written by an author who had never seen IntelliJ IDEAs highlighting framework.<p>Yes, it does syntax highlighting, but it also manages to mix it up with local variables, etc.
I've got a muddled response to this.<p>On one hand, it sounds really helpful and exciting to have tools assist us with these problems e.g. I've read the "show nesting" idea before and wondered why we don't have it yet. Yet on the other hand, I think the post misses the mark in some ways.<p>Most IDEs and editors working with most typed languages already do more than colouring in types: they typically hint ahead of entering characters what type of thing should go in each place where a typed thing can go. I think this is more useful than colour, and we already have it.<p>Taking this further, if our editor has toggles for the categories listed, and thus if it has ASTs (or equivalent things) to work over for semantics, then it probably could do even more than highlighting. Some editors already help you refactor: renaming identifiers across a project, pulling functions out etc. It's not just colouring, it's active involvement with the code, its' types and behaviours.<p>Further, the author deployed an overly simplistic view of colour and our visual perception. In my case, the "red" circle wasn't much easier to find because it was red, but because it was filled in. If it had the same colour as the rounded squares, and was filled in, I would have found it just as fast. The <i>real trick</i> in the grid examples is that some tool (in this case the author) had identified the significant information and done <i>something</i> about it, before the reader even got to apprehend the situation. Tooling which does this would absolutely be more powerful than tooling which doesn't. We already have tools which do some of these things. The drive shouldn't be "we need more colour?" the drive should be "what features are most helpful to coders?"
The author raised an interesting point with respect to syntax highlighting for types. I find the convention that literals be typed (ints, strings, etc...) to be inappropriate. That is very low-level and these should always be inferred.<p>Where typing should exist is at the level the author suggests, such as<p>* Iterators
* List-like structures
* Functions that return option types<p>and other more abstract structures.
I've experimented with using various "semantic depth" color schemes when writing clojure.<p>Depending on the code it can be useful.<p>Some I tried:<p>- <a href="https://github.com/istib/rainbow-blocks" rel="nofollow">https://github.com/istib/rainbow-blocks</a> - rainbow blocks, the "OG"
- <a href="https://github.com/seanirby/rainbow-blocks-bg" rel="nofollow">https://github.com/seanirby/rainbow-blocks-bg</a> - rainbow blocks but background style
- <a href="https://github.com/alphapapa/prism.el" rel="nofollow">https://github.com/alphapapa/prism.el</a> - Prism, a slightly more "friendly" rainbow blocks implementation
I find the unhighlighted circle to be about as quick to identify as the red one.<p>Also, I work for someone who is color blind. This whole attitude of "we must do something really important with color because it's so powerful" goes against the idea that it has to be optional.
The use cases demonstrated are compelling but there seems to be an underlying assumption that current syntax highlighting techniques are broken. After reading the article I'd argue that there is a case to be made for enhanced but temporary syntax highlighting modes where most highlighting classes are muted except the focus of your attention, such as imported package variables.<p>Consistency is important, both for style and syntax highlighting. It is hard to anticipate what a developer is mentally focused on as they scan code.
What’s amusing to me is how few suggestions around highlighting ignores the vast amounts of whitespace that surrounds every character. Borders (partial and full), underlines, strikethrough, background colors, font faces... so many options, yet are we’re constantly limiting ourselves to the color of a letter and the occasional red squiggle.<p>The one valid excuse I can think of is “my editor doesn’t support it”, to which I say BS. VIM, in a terminal, can do most of those.
> Why aren’t things this way?<p>They...are. With proper extensions, for example, VSCode does many of those things, and can switch which of the supported things it is doing, on top of also doing syntax highlighting, and some of the changes are automatic and context-driven.<p>And while VSCode is my current daily driver, that's been true of code editors for quite some time.
This is somewhat true, although I think keywords should still be highlighted. I once wrote a plugin that highlighted all labels in different colors. Even with a good palette it was really bad... The scope or block highlights could be useful. Difficult for some languages probably, but I would give it a shot.
He somehow missed rainbow identifiers, which is quite useful to represent the data flow in a function:<p><a href="https://www.emacswiki.org/emacs/ColorIdentifiersMode" rel="nofollow">https://www.emacswiki.org/emacs/ColorIdentifiersMode</a>
Egads ... that rainbow parentheses suggestion is horrific to my eyes. Most editors already do a good job of showing matched braces without shouting.<p>The problems he mentions are not tied to syntax. We need better CONTEXT aware highlighting is the gist of the article.
I use <a href="https://plugins.jetbrains.com/plugin/10080-rainbow-brackets" rel="nofollow">https://plugins.jetbrains.com/plugin/10080-rainbow-brackets</a> for IntelliJ to color matching brackets.
I don't know how to make it but I always wanted a vscode extension to text background colour what scope you were in for teaching. The rainbow vomit some beautifully indented student python would be...
This is awful, a mess. I prefer little to no syntax highlighting, just a grayscale theme with some bold and italics. Actual code clarity (naming, etc.) and structure (indentation, whitespace, etc.) is what is important.<p>Recently there was an article here about what makes a good photograph, one element was few colors, bringing focus to what matters. That is what code should look like, like a good photograph. Not like a rainbow exploded.
I don't get it. Author is a programmer, why doesn't he just develop this?
I don't need this and I don't want it bloating my text editor.
Syntax highlighting is very useful, if not then it wouldn't be so commonplace. The other highlighting methods are also useful. But there is not one objective best highlighting method, it actually changes from moment to moment depending on what you are doing. And many editors in fact already change how they highlight things based on the context! For example, when I search for something, my editor highlights all matches. If my cursor is on an opening bracket, it will start highlighting the matching closing bracket.<p>Some of the highlighting methods shown in the article also seem a bit useless to me. Assigning colors to indentation levels? Surely the indentation itself is a huge visual clue already that doesn't need colors to be wasted. The rainbow parentheses example also shows that there are limits to how many obiously distinct colors you can actually have on screen at the same time, and the colors don't uniquely show nesting levels.