The Agony And Ecstasy Of syntaxhighligher; Or, Why You Shouldn’t Fix What Ain’t Broke
WordPress just keeps getting better.
Release 2.6 includes a several new features, such as wiki-style version control for posts, a toolbar-based “blog this” control, support for Google Gears (which promises to be a major breakthrough in Web development), native word counts, native image captioning, SSL support, and bubble notification when a plug-in has been upgraded. Plus a bunch of other features and bug fixes.
While I was reading the WordPress blog entry about Version 2.6, I noticed that they have a really, really cool syntax highlighting script: Not only is it clear, and not only does it do an excellent job of segmenting the various aspects of code, it included plain-text view and copy-to-clipboard links, right in the header.
So I decided to find out what it was and use it. And, simply enough, the plug-in is called “Google Syntax Highligher For WordPress” and it leverages the JavaScript-based syntaxhighligher hosted at Google Code.
Now, I had previously been using WP-Syntax, which is based on GeSHi and is based entirely server-side, and had been happy with it. But the syntaxhighlighter code looked cleaner and offered amenities, so I decided to make the change.
And in all honesty, I wish I had stuck with WP-Syntax. But once I made the change, it was way too late to go back.