Custom Search

Sunday, August 22, 2010

Syntax highlighting for clojure code

code for the blog hosted on blogger is:
GNU enscript.



allows me to just do:
$ ccat -E





  1. FYI, syntaxhighlighter is a semi-standard syntax highlighting framework, and there's a very well-done clojure brush for syntaxhighlighter available. Various blogging frameworks have syntaxhighlighter support built-in. I was pleasantly surprised to find that has the clojure brush installed already as well, so a simple [sourcecode language="clojure"][/sourcecode] block around clojure source applies the the brush as expected. Not so much help if you're on blogger, although if javascript includes are offered, you can reuse all of the above.

  2. Yeah, they installed the clojure brush when I asked back in January. For what I think is wrong with it, see the previous blog entry at

  3. Bah, I didn't scroll back in your blog to read your premise for the enscript-based implementation you did. My apologies. :-(

    That said, I guess we'll have to agree to disagree about whether syntaxhighlighter (or javascript-dependent rendering/formatting in general) is good or not. ;-)

  4. Just for highlighting clojure code you can use, it's a simple clojure library that highlights the code :)


  5. General problem with blogs being backwards.

    Note that my problem isn't with JavaScript based highlighting, but with client-side highlighting - it just leaves to many ways for things to break. Take the same code, add a button on the authors browser that ran it on the selected text, and you not only avoid those problems, it's easier for the author as well.

  6. I'm afraid the issue of client-side formatting sailed a long time ago. As for authoring, I put a lot of value on the ability to revise content easily, so a code formatter that was an explicit authoring action already requires more thought than I'd like to invest. Workflow stuff like this is definitely a question of taste.

  7. Chas, of course all formatting happens client side, but that issue isn't dead - authors are still trying to regain control of the presentation, and probably will always do so if they don't have it. I always figured that was a primary motivation for generating html and style code from javascript. Problem is, doing so breaks the presentation in even worse ways for some readers.

    I'm curious - you can use SyntaxHighlighter with less work than selecting the code and clicking a button or two? It certainly wasn't that easy for me!

    Heinz - highlighting clojure with clojure is of course ideal, and probably less work to get right in the corner cases. But the ability to get ansi highlighting or postscript for publication as part of the package is the win for enscript.

  8. Being in control of the presentation is a largely orthogonal issue to the workflow discussion. Javascript, CSS, canvas, etc etc. are all client-side technologies (Rhino aside for the moment), all provided to put content authors in control of presentation. In that context, syntaxhighlighter is following a very well-worn path at this point.

    I think designing for a javascript-less client is a Sisyphean endeavor -- these technologies are expected. Gracefully degradation is expected as well, but I don't think worrying about the incredibly small minority that have noscript etc. is worthwhile.

    Yeah, I find using syntaxhighlighter in wordpress *very* easy. Paste code, add a [sourcecode] tag. If I want to change the code in question, just paste again. The only way it'd get easier is if their visual editor had a language dropdown baked in.

  9. Is there a difference between what you described: baking the language dropdown into their visual editor and what I suggested: baking the dropdown into the browser their visual editor is running in?