
The Definitive Guide to Syntax Highlighting - jgorauskas
http://www.wilfred.me.uk/blog/2014/09/27/the-definitive-guide-to-syntax-highlighting/
======
Crito
Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's
_' A Case Against Syntax Highlighting'_:
[http://www.linusakesson.net/programming/syntaxhighlighting/](http://www.linusakesson.net/programming/syntaxhighlighting/)

Personally, I _do_ find syntax highlighting to be useful, but I think it is an
interesting dissenting opinion that is worth mentioning. OP's article mentions
that Acme doesn't have syntax highlighting, but doesn't really expand on that.

~~~
userbinator
I'm with Linus' side on this - I started writing code without syntax
highlighting, and never had any problems doing so. In fact many times I use
paper or a whiteboard to prototype some code I'm writing, to mentally step
through it and verify that it does what I want it to.

I think much of it has to do with your attitude towards programming languages
and source code: do you view them as being intrinsically difficult and thus
requiring special tools to handle, or think that they're not any harder than
human languages to work with (after having learned and used them extensively)
so it feels completely natural to read un-highlighted code like you would text
in a human language?

Looking at the rest of his site, you'll find that he has done an incredible
amount of other interesting things too, which does increase the credibility of
his argument - he doesn't use syntax highlighting, because he doesn't need it
to understand his code.

~~~
seanmcdirmid
Syntax highlighting is just a tool to eke out a few points of productivity in
reading code. I know many people prefer plain text, notepad-style, but some of
us like reading typeset documents where formatting (bolding, color, lines) is
applied to make the document structure more pronounced.

I think much of it has to do with your attitude toward typography: do you view
it as being utterly pointless and devoid of value, or do you like things that
don't look like featureless crap.

------
jhallenworld
It is interesting to implement syntax highlighters- to solve the problem of
making them fast and efficient. In JOE, I save the continuation of the syntax
highlighter parser for the beginning of each line. When the user changes the
file, the file is re-parsed beginning with the continuation at the start of
the line. Parsing stops early if the resulting continuation at the beginning
of some subsequent line matches the saved value.

JOE's highlighter supports recursive calls: for example to switch syntax to a
scripting language embedded in HTML. Originally I implemented this with
template instantiation of the sub-syntax. Recursion is allowed, but to a
limited depth: the advantage is that the state can still be represented as a
single number.

Later, this was replaced with a real call stack. It turns out that the call
stacks of the saved continuations are often identical (stated another way-
there is already an identical continuation, so when there is a call, we search
for and reuse it if found).

The continuation also includes a buffer for saved data (for example for here
document delimiters). The continuation ends up being 32 bytes on 32-bit
machines:

    
    
      struct highlight_state {
              struct high_frame *stack; /* Closure */
              int state; /* Program counter */
              unsigned char saved_s[24]; /* Local data */
      };
    

Anyway, it's at least conceptually straightforward to extend this to have any
kind of state. Also, it should be possible to compile the syntax parser to the
native machine code. Even so, the interpreted implementation is quite fast.
Fast enough that there has not been a need to try to run it asynchronously or
after a delay as in some other editors.

------
drothlis
The article doesn't mention highlighting the declarations/definitions of types
& variables. I find it far less obtrusive, and more useful, than lexical
highlighting. It's surprisingly easy to do in Emacs, and it works reasonably
well across most language modes. Example screenshots:
[http://david.rothlis.net/code_presentation/distracting_synta...](http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/)

------
noir_lord
An interesting and very clear article.

As someone who started in an era when syntax highlighting didn't exist (at
least on the machines and tools I was using at the time) I personally like it
a great deal.

I found something the other day in the intellij ide's that I really liked (and
had not seen before though I may have missed it) which was the ability to
highlight the variable under cursor contextually (different for reads and
writes).

Like so [http://i.imgur.com/u9UkXPN.png](http://i.imgur.com/u9UkXPN.png)

It was a small change but when running through code you've not used/seen
before I've found it a nice little touch at getting a good grasp of whats
going on with variables.

------
platz
I've seen more than one talk where the presenter lamented a lack of
highlighting based on highly nested structures. So, for example, changing the
color based on the closure that one is in. Or, changing the color based on the
execution context one is in (so one can make sure they are modifying the
variable in the appropriate context).

This would be useful in langues that make heavy use of callbacks such as
javascript or scala.

Not sure how hard it would be to implement though - it might require a full
parse or compiler pass.

~~~
philbo
There are actually a few implementations of this for JS, it is an approach
that Crockford has championed quite a bit (e.g
[https://plus.google.com/+DouglasCrockfordEsq/posts/XXkzgJEoE...](https://plus.google.com/+DouglasCrockfordEsq/posts/XXkzgJEoE9v)).

Some implementations that I'm aware of, there may be others:

* [http://www.vim.org/scripts/script.php?script_id=4748](http://www.vim.org/scripts/script.php?script_id=4748)

* [https://github.com/mazurov/sublime-levels](https://github.com/mazurov/sublime-levels)

* [https://github.com/daniellmb/JavaScript-Scope-Context-Colori...](https://github.com/daniellmb/JavaScript-Scope-Context-Coloring)

------
arianvanp
There is a really great mode [0] for haskell that does the same thing as hl-
sexp-mode. Oh and did I mention it fully supports structured editing? These
kind of modes really make me question why programs are still written in text
instead of ADTs... We don't need to run lexers and parsers to do our syntax
highlighting and other fancy stuff... it would be awesome.

[0] [https://github.com/chrisdone/structured-haskell-
mode](https://github.com/chrisdone/structured-haskell-mode)

------
micampe
This made me think that it would be useful to have different, easily
switchable highlighting modes: syntax and symbols when I'm writing, structure
when I'm reading code.

Or maybe syntax highlighting for the scope I'm in and structure for the rest.

I often use the folding/nesting indicators when reading code, it would be an
extension of that.

~~~
kndyry
I've been using (and loving) something similar to this while switching modes
between code and prose in vim [0]. In addition to changing how syntax
highlighting, spellchecking and line breaks happen, there are some other
interesting bits specific to prose; like formatting text for pasting into word
processors, &c.

[0] [http://alols.github.io/2012/11/07/writing-prose-with-
vim/](http://alols.github.io/2012/11/07/writing-prose-with-vim/)

------
visarga
Does this exist in Sublime Text too? ... color-identifiers-mode, rainbow-
delimeters and highlight-parentheses-mode

~~~
Derbasti
I believe that Sublime Text is a descendant from Textmate, and therefore uses
a single table of recursive regular expressions for syntax highlighting.

It therefore can not distinguish multiple instances of the same thing
(different variables) or overlay different highlighting modes on top of one
another.

------
signa11
on this note, does anyone know of a way to highlight stuff in #ifdef blocks
appropriately within emacs? at the very least if a block of code is within #if
0 ... #endif, it should be grayed out...

------
icantthinkofone
The best highlighting is no highlighting at all. Think about it.

You've read that the best programs read like a book. Now picture a book you
are reading where the title, subject, nouns and verbs were all colored in some
way. Try and read smoothly through that forest and think about highlighting
some more.

There are a number of articles about reading on the web and how you highlight
links without interrupting the flow of the reader. Should you underline links,
or make the word a different color or give it a background? No matter what is
done, it's said, you will interrupt the reader's flow and train of thought.
Here, though, people exclaim highlighting is beneficial because function
names, variables, values, and so on are highlighted and this is good!

Now someone will claim highlighting helps them find a particular value, say a
function name but isn't that what indenting is supposed to do? Others will now
say it helps with arguments but isn't that parentheses are for?

If you look at most multi-colored, highlighted page of code it looks like a
candy store, all of it begging for your attention which is exactly what you
don't want. Those with muted colors and grays are no different when you're
trying to pick out one slight variation over another and trying to determine
if it's a function or something else.

When I read a book, I want paragraphs with indentation and I can read pretty
fast that way. So can you. When you read code, you need blocks and indentation
(and parenthese/brackets/semicolons). Little else. Maybe nothing else.

~~~
qu4z-2
I like to think of syntax highlighting as a quick draft-parse. It lets you
know how the computer is parsing the code structure. I know, "Code is written
for humans to read and only incidentally for computers to execute", but you'd
be quite put out if the computer didn't execute your code.

If human languages were written for one more-or-less uniform reader, I'd love
a feature that showed how people would resolve pronouns ("Mary gave Sue her
laptop.") or ambiguous attachment in general. Granted that's semantic, and
probably closer to the feature in some editors where other instances of the
same variable are highlighted on hovering, but they are both a form of visual
feedback as to how the input token stream will be interpreted. I'd also say
it's more important to get that information with a computer, because humans
are pretty good at error recovery, and can often resolve syntax errors at the
semantic level ("This sentence doesn't make sense; presumably it's a typo and
<x> was meant, because that makes sense in context.")

In fairness, I dislike most highlighting schemes, but they definitely have a
certain value.

