Live data from Hacker News

The Definitive Guide to Syntax Highlighting

wilfred.me.uk

11–20 of 24 posts

Re: The Definitive Guide to Syntax Highlighting

#11
post #4

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…

Parsing is easy to do incrementally, but you could get there just by matching braces. I think Python-like offside rules are better for highlight purposes, however; e.g. see:

http://research.microsoft.com/en-us/projects/liveprogramming...

Re: The Definitive Guide to Syntax Highlighting

#12
post #2

Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's 'A Case Against Syntax Highlighting' : 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.

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.

Re: The Definitive Guide to Syntax Highlighting

#13
post #2

Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's 'A Case Against Syntax Highlighting' : 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.

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 a…

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.

Re: The Definitive Guide to Syntax Highlighting

#14
post #4

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…

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...).

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

* http://www.vim.org/scripts/script.php?script_id=4748

* https://github.com/mazurov/sublime-levels

* https://github.com/daniellmb/JavaScript-Scope-Context-Colori...

Re: The Definitive Guide to Syntax Highlighting

#15
post #2

Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's 'A Case Against Syntax Highlighting' : 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.

Anecdotally, I've found that disabling syntax highlighting encourages me to pay more attention to how I structure my code as I'm writing it. I feel more aware of sections of code that may be getting messier as I work.

I still turn on syntax highlighting when I'm reading code though, whether my own or somebody else's.

Re: The Definitive Guide to Syntax Highlighting

#17
post #2

Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's 'A Case Against Syntax Highlighting' : 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.

> Personally, I do find syntax highlighting to be useful, but I think it is an interesting dissenting opinion that is worth mentioning.

I just think that syntax highlighting is usually executed really badly, often emphasizing even the least interesting parts of code in the most distracting colors.

The analogy to prose is quite adequate. Randomly highlighting the different word classes in a dozen flashy colors would distract me like crazy; but nobody would argue against using a larger font for headings and a smaller one for footnotes.

If I was programming all day, I would probably spend considerable time creating very subtle syntax highlighting themes for different languages (something like: slate function names, white strings, everything else grey, italic variable names). But I don't, so I usually just turn off syntax highlighting entirely.

Re: The Definitive Guide to Syntax Highlighting

#18
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.

Re: The Definitive Guide to Syntax Highlighting

#19
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.

Re: The Definitive Guide to Syntax Highlighting

#20
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

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.

Post reply on HN