For information on exactly what dp.SyntaxHighlighter is, please see it's code-site on Google Code. Due to theme compatibility I've had to make some moderate changes to the original CSS of the SyntaxHighlighter package (for better, not for worse), there are no actual visual differences from the examples given in the original package (well, there shouldn't be anyhow, that's what my modifications were for, but this is a first release / test version).

I've always preferred the markup that the SyntaxHighlighter script from Dream Projections (now hosted on Google Code) created over GeSHi's output. Although when using GeSHi the code itself is made "pretty", it's not a necessity, so I feel that the use of JavaScript and CSS would be better served for this purpose than using server-side techniques as GeSHi does. This is where dp.SyntaxHighlighter comes to the rescue, and it handles it wonderfully!

What would the output look like using this script/plugin?
Example without JavaScript enabled:
Using a PRE tag:
<?php
    //the infamous Hello World
    echo "Hello World!";
?>

Using a TEXTAREA tag:

With JavaScript/plugin enabled (either PRE or TEXTAREA):


You'll have to read on to see supported languages and usage information.
What can I do to help?!
I really need people to test this on various themes (that support the frontend_header and frontend_footer hooks) to test the CSS compatibility. I made various efforts to modify the original CSS to force it not to break, but I got tired after fixing it on three different themes and was too afraid to test it in even more. I'm also hoping that my efforts will fix all of them by default. :-P

Currently, SyntaxHighlighter supports the following languages:
  • C#
  • CSS
  • C++
  • Delphi
  • Java
  • JavaScript
  • PHP
  • Python
  • Ruby
  • SQL
  • VB(.NET)
  • XML
...and is extendable.

All the above languages are incorporated in this plugin. I may or may not incorporate Brian Beck's modified Python styles with my plugin. I think it's more Python-esque, but I've yet to make a decision.

Cool!! Where and how can I get my hands on it?!?!
To test out the plugin and offer feedback, you'd obviously need to be using Serendipity, or Supersized.org as your blog of choice, you'd also need to download the plugin, and understand how to use it as the interface has not been modified from the original package, unlike a particular Wordpress plugin does. For now, the plugin download resides on my server, with luck it will eventually be placed in to the Spartacus repository for Serendipity.

To update this plugin, if I lag behind, simply replace the JS/CSS files in the plugin directory with the ones from the downloadable package on Google Code.

Note on Usage: Because the script expects a "name" tag whether you use PRE or TEXTAREA elements to wrap your code, if you use PRE you'll have invalid HTML. However, if you use TEXTAREA and have multiple entries on a page, you'll still have invalid HTML since you'll have duplicate elements with the same name property.

For a quick rundown on its usage, here's an example:


Also, be aware that you'll probably want to enable the NL2BR plugin's ability to not add BRs within TEXTAREA or PRE tags as this script will handle that automatically. You will not be able to use this plugin in the WYSIWYG editor, however, as the HTML elements require manipulation. If you're a coder, however, I doubt you would be using that anyway.

If you use any other markup plugins, there may be compatibility problems (such as emoticons, Serendipity's Textile type markup of *'s, etc...) due to how code is written. For instance: /* this is a comment */ <-- the asterisks would be converted to <strong> tags using the Serendipity markup plugin. Just be aware of issues such as these. It's not an issue with this plugin, but merely what the other plugins' purposes are.

Trackbacks


Trackback specific URI for this entry
    No Trackbacks

Comments


    #1 Mgccl on 06/05/07 at 08:17 AM [Reply]
    I would like to use GeSHi better since it does not require user to use Javascript.
    It is not as uncommon as we might want to think, there is a small amount of users who don't enable Javascript in their browser.

    Non of the current ways for syntax highlighting is ideal.

    Sometime in the next few years the syntax highlighting will became part of browser's built in function because it's wasting so much CPU power of servers and then waste CPU power of the clients(parse a huge HTML doc).
    Javascript way is slow and CPU intensive.

    Maybe someone should write a extension for firefox do just that.
    So there will be only one parsing (Client) and less data transferring around the internet.
    #1.1 Brendon Kozlowski on 06/05/07 at 01:21 PM [Reply]
    I agree that JavaScript is slow and that it should not be relied upon. However, the reason I prefer this syntax highlighting is that it doesn't add any unnecessary HTML markup to the actual underlying data, whereas GeSHi does -- and depending on the plugin and/or CMS, GeSHi may not be called on during saving, but on displaying! Talk about CPU resources being used improperly! :D ...although, I would have to imagine that this only occurs in some home-brew CMSs or poorly designed plugins that aren't supported.

    Regardless, code held in a TEXTAREA or PRE tag still retains its original formatting, and is still easily viewable by people that do not have JavaScript turned on. In fact, a TEXTAREA contains unmodified data during a copy-to-clipboard action, whereas with a PRE tag, the copy may (depending on the browser) grab extra whitespace. GeSHi could easily confuse a browser/OS copy action in to grabbing much more data than necessary.

    I will admit, however, that if a user has JavaScript enabled that this copying process isn't perfect either (unless you "view plain", and a new window with a textarea pops up). ;)

    Thanks for the comment!
    #2 kleinerChemiker on 10/03/07 at 10:01 AM [Reply]
    Hi,

    maybe you can add in your css-file a row like this:

    textarea.php, textarea.javascript, textarea.html {width: 100%; height: 400px; overflow: auto;}

    Than the textarea isn't soooo small anymore.

    tia

    MIK
    #2.1 Brendon Kozlowski on 10/05/07 at 11:47 AM [Reply]
    Thank you, but unfortunately this will not work as expected unless a CSS class is also included along with the HTML name property. I have, however, just begun testing the new SyntaxHighlighter version (1.5.1) with this plugin and am now just checking rendering compatibility. (There were no problems of functionality seen.)
    #3 David on 07/06/09 at 02:23 PM [Reply]
    Hey Brendon,
    Congrats on the release of the plugin. It's great to have the competition and alternative to the geshi plugin. I do think that the argument about embedded styles employed by geshi is in fact a strength of it's approach because it is very self contained and rarely runs afoul of things people are doing in there themes.

    With that said, the javascript approach does unleash some neat tricks inherent in Alex's library, like the copy to clipboard feature. I considered adding a few of these things to the geshi plugin, but I decided it was better not to add in complexity, so now people can choose what appeals to them, and whether or not they want to go with a serverside approach or a client/javascript approach.
    #4 Brendon Kozlowski on 07/06/09 at 04:15 PM [Reply]
    Thank you, David. Congratulations on the release of your plugin (quite some time ago) as well! I wouldn't necessarily consider us competitors (even though I suppose we are) since we more or less built plugins that fill a need. Some people prefer server-side, some prefer client-side. Some prefer the power of GeSHi, some prefer the simplicity of SyntaxHighlighter. We simply offer the full gamut. :) ...and by full, I mean that in a completely fictional (yet meaningful) sense.

    Thank you for your comment. I was going to reply in one of your GeSHi for Serendipity topics on your blog, but from what I could see on Google's site search, they were all pretty old. Much older than mine, in fact.

    However, perhaps I should get on the ball and test the new code with Alex's version 2.0 of his Syntax Highlighter, which fixes many of the problems people have had (such as broken HTML compliancy when using multiple code boxes on the same page with his code).
    #5 Markus on 08/25/09 at 08:28 AM [Reply]
    Hi.
    At first thanks for this plugin.
    Now my question: How can I support perl with this plugin? I got some perl scripts, bur with class="Perl" there is no highlighting.
    #5.1 Brendon Kozlowski on 08/25/09 at 02:03 PM [Reply]
    Hello Markus,

    There is no documentation on how to create extendable language support "brushes" for use with SyntaxHighlighter; to do so, you have to get your hands dirty in the other current brushes, understand how they work, and then implement your own. There have been some community efforts, and a couple Perl brushes in the Google Group comments: http://code.google.com/p/syntaxhighlighter/wiki/Languages

    Hopefully that will be of some help to you.

    As for version 2.0 of SyntaxHighlighter and my plugin, I'm still uncertain if I want to support it unless I alter the default CSS styles. I really don't like that the new icons hover over the actual code text.

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

BBCode format allowed