Whenever syntax highlighing is being discussed, I like to plug Linus Åkesson's <i>'A Case Against Syntax Highlighting'</i>: <a href="http://www.linusakesson.net/programming/syntaxhighlighting/" rel="nofollow">http://www.linusakesson.net/programming/syntaxhighlighting/</a><p>Personally, I <i>do</i> 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.
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.<p>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.<p>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).<p>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:<p><pre><code> struct highlight_state {
struct high_frame *stack; /* Closure */
int state; /* Program counter */
unsigned char saved_s[24]; /* Local data */
};
</code></pre>
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.
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:
<a href="http://david.rothlis.net/code_presentation/distracting_syntax_highlighting/" rel="nofollow">http://david.rothlis.net/code_presentation/distracting_synta...</a>
An interesting and very clear article.<p>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.<p>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).<p>Like so <a href="http://i.imgur.com/u9UkXPN.png" rel="nofollow">http://i.imgur.com/u9UkXPN.png</a><p>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.
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).<p>This would be useful in langues that make heavy use of callbacks such as javascript or scala.<p>Not sure how hard it would be to implement though - it might require a full parse or compiler pass.
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.<p>[0] <a href="https://github.com/chrisdone/structured-haskell-mode" rel="nofollow">https://github.com/chrisdone/structured-haskell-mode</a>
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.<p>Or maybe syntax highlighting for the scope I'm in and structure for the rest.<p>I often use the folding/nesting indicators when reading code, it would be an extension of that.
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...
The best highlighting is no highlighting at all. Think about it.<p>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.<p>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!<p>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?<p>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.<p>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.