Custom Search

Sunday, August 22, 2010

Syntax highlighting for clojure code

Having left people hanging last week, the tool I used to format the
code for the blog hosted on blogger is:
GNU enscript.

None of the available tools would work out of the box. GNU enscript provides the most bang for the buck. I've been using it for printing text for a while now - it has all the flexibility the "in the browser" highlighters have, at least when printing postscript. While it's natural medium is postscript, it can also output html (which I use for the blog),rtf, overstrike (for printers) and ansi terminal codes.

The latter is particularly interesting. A quick addition to my shell aliases:
alias ccat="enscript -o - --language ansi --color"

allows me to just do:
$ ccat -E foo.sh

to print foo.sh in an xterm with syntax highlighting via the ansi control codes. I expect this to be very handy.

The not working out of the box problem with GNU enscript is that it doesn't have a highlighting mode for clojure. Adopting a state file from one of the LISP language variants was straightforward. Working through the code previously posted in the blog uncovered some corner cases that were easily fixed.  That clojure is a functional language did present one interesting choice: highlight all occurrences of the builtin functions, thus highlighting variables that reused those names, or only highlight them in the function slot in s-expression, thus missing them when they were passed as values to other functions? I eventually chose the latter, as that's what emacs does.

Once you've installed GNU Enscript, you'll want to get the clojure state file from the bitbucket repo for the blog, and then install it in the share/enscript/hl directory where enscript stores the language state files. After doing that, you can use -Eclojure to get clojure highlighting.

9 comments:

  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 wordpress.com 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.

    ReplyDelete
  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 http://blog.mired.org/2010/08/on-overengineering-software.html

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

    ReplyDelete
  4. Just for highlighting clojure code you can use http://github.com/Licenser/clj-highlight, it's a simple clojure library that highlights the code :)

    regards,
    Heinz

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

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

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

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

    ReplyDelete
  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?

    ReplyDelete