Feedback for SyntaxHighlightingPlugin

-- NicolasTisserand - 22 Jan 2003

This is something I've been wondering about how to approach for awhile. Thanks for writing this plugin to save me the agony.

BTW, for consistance with the "twiki way" of encoding variables it might be better to use a syntax like:

%SYNTAX{"xml"}% a bunch of xml code %SYNTAX:END%

-- MattWilkie - 22 Jan 2003

Nice job! I definitely agree with MattWilkie about the tag name, but other than that I'm quite impressed.

-- WalterMundt - 23 Jan 2003

I've attached a quick patch to change tags to case-insensitive %SYNTAX{"lang" [numbered[:START]] % ... %SYNTAX:END%

-- WalterMundt - 23 Jan 2003

Very nice. For tags, I'll ike to propose SYNTAX{"lang" [numbered]} blabla ENDSYNTAX. Be intuitive. Use RuleOne.

We already use COLOR - ENDCOLOR, and there is proposal for SUMMARY - ENDSUMMARY.

-- PeterMasiar - 23 Jan 2003

Not a bad idea. When I was whipping up the patch, I was thinking of %SEARCH{"stuff" setting=on}% and %TMPL:DEF% and %TMPL:END%. %ENDSYNTAX% does seem better -- I'll update the patch in a bit, but you can just edit it yourself pretty easily if you're impatient.

-- WalterMundt - 26 Jan 2003

GuidoBrugnara tells me that with version 1.6.2 of GNU enscript (e.g. on SUSE);

The command

enscript --color --language=html --highlight=sh -o - -q

should be changed to:

enscript --color --language=html --pretty-print=sh -o - -q

-- AndreaSterbini - 07 Aug 2003

I did some editing of the Plugins topic to avoid broken links if the Plugin is installed on a TWiki site. Feel free to take this into the next release.

-- PeterThoeny - 08 Aug 2003

The current distribution was zipped including the parent directory, so you can't do the standard plugin installation - unzip foobar.zip

-- MartyBacke - 08 Aug 2003

The plugin does not work while mod_perl is activated. The problem seams to be linked to the used open2 which does not work under mod_perl.

-- ThomasKurz - 29 Sep 2003

I kept getting Syntax Highlighting: internal error trying to use this plugin. The problem was enscript wasn't being found. So I edited /twiki/lib/TWiki/Plugins/SyntaxHighlightingPlugin.pm and changed the line

my $highlighted = pipeThru("enscript --color  ...

To

my $highlighted = pipeThru("/usr/local/bin/enscript --color  ...

Fixed the problem right up.

-- DanEdwards - 13 Oct 2004

The solution to the mod_perl problem mentioned above is to modify the module to use IPC::Run instead of IPC::Open2. The new code goes like this (replaces the call to pipeThru):

    use IPC::Run qw( run ) ;

    ...

    my @cmd = qw(enscript --color --language=html --output - --silent) ;
    push @cmd, "--highlight=$langs{lc($lang)}" ;
    my $highlighted = '' ;
    run \@cmd, \$text, \$highlighted ;

-- OllyStephens - 11 Jan 2005

I have added a couple of patches, SyntaxHighlightingPlugin.pm.patch and SyntaxHighlightingPlugin.txt.patch - these patches deal with a number of issues, including most of those listed previously on this page. I did this as a patch for data/TWiki/SyntaxHighlighting.txt and lib/TWiki/Plugins/SyntaxHighlighting.pm because of the odd way this distribution is packaged. (I couldn't decide if I wanted to do the patch against the distribution or the production files, so I did neither.) Changes:

• Tag syntax changes to =SyntaxHighlightingPlugin: Language lang is either undefined or unsupported. Check SyntaxHighlightingPlugin for more information.

... 

=

• New regex as suggested above.
• Moved to IPC::Run::run for mod_perl compat.
• Wrapped the call to enscript in eval{ ... };. Without this, a fatal error in this module takes down the entire site.
• New option CONTAINER : The html that is used to wrap the highlighted output can be configured. I wanted to use a div with a particular class instead of the default non-css'd table.
• New option ENSCRIPT_PATH : Path to enscript can be configured. Defaults to just enscript (ie, on the path)
• New option ENSCRIPT_VERSION : Earlier versions of enscript use a different syntax to do the magic. This may help with this situation. (Needs some more testing, but I don't have access to very many versions of enscript).
• Adding "xml" as a language type - though, I cheat and define it as "html". Works pretty well, however.

Thanks go to all of the contributors listed above. I wouldn't have gotten nearly as far without them.

-- BenHouston - 14 Feb 2005

checked .zip into CVS

-- WillNorris - 19 Jul 2005

how does one go about installing the patches... I'm new to TWiki and really would like to use this Plugin (i'm getting the internal error)

-- JeffPipas - 17 Aug 2005

regarding the question about how to install the patches... on Centos linux I just used "patch -b original_file patch_file"

You need to do it for both patches. The -b option just backs up the original file as .orig

-- AndrewRobinson - 31 Aug 2005

I was running 1.6.1 version of enscript and I found that my version didn't support the --highlight option. I entered my version into the SET statement on the SyntaxHighlightingPlugin page but it still didn't seem to evaluate properly in the pm script. I manually changed the --highlight to --pretty-print within the .pm file and it works brilliantly.

-- AndrewRobinson - 31 Aug 2005

I was curious if there is a specific reason for using enscript 1.6.1 vs 1.6.3?

-- EricHanson - 23 Mar 2006

I've attached a cumulative patch that contains the changes from all previous attached patches, in the standard unified diff format: SyntaxHighlightingPlugin.2005-02-14.patch.

Works fine in TWiki 4.0 if:

• you move the SyntaxHighlightingPlugin.txt from data/Plugins/ to data/TWiki/
• install the IPC::Run Perl module
• turn it on using configure...

For the lazy, I've also attached a zipfile ( SyntaxHighlightingPlugin.twiki04.zip) with fully patched SyntaxHighlightingPlugin and SyntaxHighlightingPlugin.txt moved to data/TWiki/ :

-- AleksanderAdamowski - 03 May 2006

Thanks for updating this Plugin for TWiki 4. This Plugin has a PleaseFeelFreeToModify policy. Feel free to update the zip file in the Plugin topic (using the identical SyntaxHighlightingPlugin.zip name).

Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 04 May 2006

The installation guide needs to be updated to include the requirement of IPC::Run. This CPAN module needs to be installed with the patched version. It can be found here: http://search.cpan.org/~rsod/IPC-Run-0.80/lib/IPC/Run.pm

-- SamMingolelli - 20 May 2006

I still have an issue with the error:

enscript: option `--highlight=cpp' is ambiguous
Try `enscript --help' for more information.

I see this fixable above, I was wondering if the change to --prety-preint or --color could be made in future zips/tars.

-- EricHanson - 09 Aug 2006

Follow up: It seems that it is checking for version, however the code does not work properly. When it calls:

    my $enscriptPath    = &TWiki::Func::getPreferencesValue("SYNTAXHIGHLIGHTINGPLUGIN_ENSCRIPT_PATH" )    || "enscript";
    my $enscriptVersion = &TWiki::Func::getPreferencesValue("SYNTAXHIGHLIGHTINGPLUGIN_ENSCRIPT_VERSION" ) || 1.63;

It is not actually picking up the values from the page. Not sure how this should work, I even tried changing the page values to be start wiht the SYNTAXHIGHLIGHTINGPLUGIN_ but with no luck.

-- EricHanson - 09 Aug 2006

To PeterThoeny: Hi Peter, I made an update to this plugin which is not compatible with the old syntax %begin ... but with %SYNTAX and optional %CODE. Its now

%SYNTAX{ [language=]"code type" numbered="on|true|line number to start" numstep="inc line numbers" }%

put code here


%ENDSYNTAX%

also there a some new setting to configure enscript coloring and html as well as some additional formats.

the last config option is to be compatible to BeautifierPlugin which enables per default !%CODE {}%.

My question is now: Should I drop the old Plugin and add the new code and documentation to the same name or should I create a new Plugin like SyntaxHighligthing2Plugin or YetAnotherSyntaxHighlightingPlugin.

Please let me know your decision.

Thanx, Tom

-- ThomasFreudenberg - 20 Nov 2006

I cannot make a decision on behalf of plugin authors NicolasTisserand, NicolasBurrus, and Perceval Anichini. I recommend to contact them by e-mail if you do not get a reply within the next few days. This plugin is not maintained for a number of years, and the modification policy is not even set. If you do not get a reply I recommend to replace the current zip file with your new version.

-- PeterThoeny - 21 Nov 2006

So I will wait here for end of November if anyone will give me a different reply.

-- ThomasFreudenberg - 21 Nov 2006

BTW, thank you for picking up this plugin, this is open source spirit!

-- PeterThoeny - 21 Nov 2006

Hi Peter, could you please give me a hint for the settings inside the Plugin Description Topic.

I have exported all kind of formatting stuff so that it could be set by pluginTopic, TWikiPref bla bla bla

The format optin could contain some html stuff, it works but it look funny to awfull when you look at the topic, because the line are formatted through the html stuff. I played around with different nop's but none worked. So all I got is to use an html comment but then you could see the options only in raw view. I am sure there is a better solution but I do not know it

So Plugin Code is:

$opt_format_prepend        = &TWiki::Func::getPreferencesValue( "SYNTAXHIGHLIGHTINGPLUGIN_FORMAT_PREPEND" ) || "<pre>";
$opt_format_append         = &TWiki::Func::getPreferencesValue( "SYNTAXHIGHLIGHTINGPLUGIN_FORMAT_APPEND" )  || "</pre>";

and Topic Text should be (for here its inside verbatim)

   * Format settings
      * Set FORMAT_PREPEND = <table width="100%" border="0" cellpadding="" cellspacing="0"><tr><td bgcolor="#FFFFFF"><pre><font color="#000000">
      * Set FORMAT_APPEND = </font></pre></td></tr></table>
      * Set FORMAT_LINENUMBERS = <font color="#555555">%05d</font>   

Thanks for any help

-- ThomasFreudenberg - 22 Nov 2006

Put the settings in verbatim tags, such as:

* Format settings
<verbatim>
* Set FORMAT_PREPEND = ...
* Set FORMAT_APPEND = ...
* Set FORMAT_LINENUMBERS = ...
</verbatim>

-- PeterThoeny - 22 Nov 2006

Hi Peter, thanx for your answer. Thats really strange, because when I saw your hint I thought myself: hmmm if have already checked it this way but give it a try ( cause its from peter ). So I did and it worked and won't understand this world but did some more tries and now I am not sure if this is a bug or a feature:

When I ( and I always like to format my codes ) try to indent the settings like:

* Format settings
<verbatim>
* Set FIRST = ...
* Set MORE = ...
* Set LAST = ...
</verbatim>

following situation happens: Always the last parameter (in the example LAST) will have also an additional linebreak code in its value, that means the value is junked with the next line until tag <verbatim> starts. When I append one additional empty line, no problem even with indent of <verbatim> tag. Is this what it should be? Btw this causes my problem and my question from last night, I have always test with indent verbatim tags.

-- ThomasFreudenberg - 22 Nov 2006

In preparing to change this Plugin with a new version, I have attached latest changes to SyntaxHighlightingPlugin.pm and .txt. Everyone is interested please have a look.

Peter, please have a look at my last comment, if it is correct or a bug.

-- ThomasFreudenberg - 24 Nov 2006

This is spec. Settings can span multiple lines if followup lines are indented. In your case the closing vebatim tag is considered a followup line of the last setting.

-- PeterThoeny - 26 Nov 2006

Peter, I agree to spec, when a setting is going on next line that it will junked and appended to the parameter, but when the next line is filled with spaces only, they won't be appended. So in this case, I would say, that the value ending by a tag like </verbatim> should be trimmed as it would be when it is only a next line with some empty spaces.

-- ThomasFreudenberg - 28 Nov 2006

Right - can we have a summary again on how i would use and install this plugin on 4.1.2?

I am keen to try it, but have no idea what i am doing, its not quite in the same format as the other plugins i have used.

-- TerryRankine - 20 Mar 2007

Works nicely in 4.0.5 (ThomasFreudenberg's version). Renders emacs colours beautifully.

-- MikkoLaakso - 28 Mar 2007

Works also in 4.1.2, just extract the attached https://twiki.org/p/pub/Plugins/SyntaxHighlightingPluginDev/SyntaxHighlightingPlugin.zip to your twiki folder and change owner and access rights appropriately.

-- MikkoLaakso - 16 Apr 2007

Bug !!!

%begin javascript%
<script language = JavaScript>
if (document.images) 
{
img1 = new Image();
img2 = new Image();
img1.src = "Image-Name-1.gif";
img2.src = "Image-Name-2.gif"
}
</script>
%end%

-- HieuLeTrung - 19 Jun 2007

There appears to be a bug with the 24 Nov 2006 version of this plugin - if the first line of text within the %SYNTAX% tags is indented, it does not get indented in the resulting HTML. This problem does not occur with other lines, just the first line. Has anyone else seen this?

-- KyleGetz - 24 Jul 2007

Does anybody have an idea of how to add php to this plugin?

-- MarijanaPrusina - 04 Oct 2007

For anyone wanting to add php check out; http://home.raxnet.net/article_viewcvs_php.php

It shows you how to add php to the enscript library.

-- MarijanaPrusina - 05 Oct 2007

I've just found out that enscript invoked from this plug-in is not wait'ed, which results in zombie enscript processes under mod_perl and other persistent process settings.

Applying the following patch to SyntaxHighlightingPlugin.zip resolves the problem.

--- lib/TWiki/Plugins/SyntaxHighlightingPlugin.pm       2006-11-24 12:14:43.000000000 +0900
+++ lib/TWiki/Plugins/SyntaxHighlightingPlugin.pm.patched       2008-01-29 10:13:43.000000000 +0900
@@ -159,6 +159,7 @@
     close( Writer );
       my $enscript_result = join("", <Reader>);
     close( Reader );
+    waitpid $pid, 0;
 
     # check if we got a result
     if ($enscript_result =~ s/.*\<PRE\>\n(.*?)\n?\<\/PRE\>.*/$1/os)

-- HideyoImazu - 29 Jan 2008

I added HideyoImazu 's patch and a fix for a number/string clash in the https://twiki.org/p/pub/Plugins/SyntaxHighlightingPluginDev/SyntaxHighlightingPlugin.zip , below.

I think this version should replace the current version. Todo list:

• Script to convert the old, broken, tags into the new %SYNTAX{}% tags in the whole wiki
• Come up with an agreeable way of presenting the prettified result. The proposed formatting (with FORMAT_PREPEND) using a table right now is ugly HTML and should be integrated into the PatternSkin better. I propose a simple classed <pre> tag that the site's CSS then formats as needed. As for the linenumbers a classed <span> will do the same.

-- WoutMertens - 30 Jan 2008

You know, I really think that TWiki.org should get discussion forums. Then I could take the formatting issue to a "look'n'feel" forum and people would get notified about the new topic etc.

The current topic change notification system just isn't working very well, from a usability point of view. It'd be great if TWiki got a proper comment system, but until it does someone should install forum software and prominently advertise it.

-- WoutMertens - 01 Feb 2008

Having a look at this plugin as we are upgrading our version of TWiki and used the previous version. As I understand it from the comments above, there is a version attached to this page that works with TWiki 4.x, but has a different syntax. Is this correct?

If so, I don't mind taking the zip from here and releasing it properly. However, as it has a different syntax people will need a script to convert their existing syntax. Does anyone have such a script already? If not, I can look into making one as time permits.

Also, there are three other syntax highlighters available. None of these support all the languages this does, but are all maintained. So I wonder if its worth keeping this one alive? Another thing about the others is they all use =SyntaxHighlightingPlugin: Language language is either undefined or unsupported. Check SyntaxHighlightingPlugin for more information.

... 

=, so maybe this plugin should use the same? This would make them largely interchangeable.

• DpSyntaxHighlighterPlugin
• BeautifierPlugin
• SourceHighlightPlugin

-- AndrewRJones - 04 Sep 2008

I have uploaded a new version with various improvements and a change of syntax. See Bugs:Item5995 for more.

-- AndrewRJones - 11 Sep 2008

After removing the -T switch from the configure script, I was able to successfully install this Plugin on TWiki-5.0.1. However, I keep getting an internal error when trying to use the plugin: "TWiki.SyntaxHighlightingPlugin - Internal error. Notify you administrator at ..." I checked the dependencies: enscript and CPAN:IPC::Run are both installed. So I am guessing that this plugin simply doesn't work on TWiki 5.0.1 yet...? Any hints? Is there a way to debug this error and fix the plugin? Would be nice to have syntax highlighting available in TWiki 5.0.1. Thanks

-- AndreasKeil - 2010-10-24

We tested over 120 extensions for TWiki-5.0, this plugin is pending.

The internal error means that there is more info in the Apache error log. It usually tells you the file and line number where the error occurs.

-- PeterThoeny - 2010-10-24

I found the problem: enscript changed the naming of one of its crucial parameters with version 1.6.3 from --pretty-print to --highlight. Since the server I'm running TWiki on only has enscript 1.6.1 installed, the enscript call didn't work. Upgrading enscript to a newer version should resolve this issue. Sorry for the spam...

-- AndreasKeil - 2010-10-24

Thank you Andreas. I check-marked the 5.0 checkbox in the plugin topic. I'll update the plugin to list the dependency with version number.

-- PeterThoeny - 2010-10-24

Plugin doc is now updated, and new plugin is uploaded.

-- PeterThoeny - 2010-10-24

I just installed enscript 1.6.5.2 and the plugin generally works. However, there is one issue with the way TWiki handles edits:

Entering source code between %CODE% and %ENDCODE% in the raw editor works, because it keeps the line breaks intact. Further edits, however, remove these line breaks in the WYSIWYG editor and even switching to the raw editor subsequently doesn't change that behavior. The lost linebreaks then destroy the whole code markup.

There seem to be only two workarounds to this:

• Setting the raw editor as default (I guess, not tested).
• Enclosing the code snippets in <pre> tags.

The former option severely restricts TWikis capabilities, the latter not only has to be remembered by users every time they insert a code snippet but also results in huge extra spacing before and after each code block.

Is there any better way for preventing TWiki from removing the line breaks inside code blocks?

-- AndreasKeil - 2010-10-24

The WYSIWYG has known issues to munch content. You can enclose text you do not want to be touched by the WYSIWYG editor in <sticky>...</sticky> tags.

-- PeterThoeny - 2010-10-24

Ah, that works, thanks. That resolved at least the problem with excessive spacing (compared to using pre-tags). However, it's still an extra step to be remembered by users - but an acceptable one

-- AndreasKeil - 2010-10-24

I just updated the plugin's documentation and surrounded all examples with <sticky> tags.

-- AndreasKeil - 2010-10-24

Thanks Andreas. I folded the doc improvement back into SVN and re-released the plugin.

-- PeterThoeny - 2010-10-24

Seems to be a problem with strings like <code></code> and <code></code> being replaced with links and there doesn't seem to be any way to get around it. <verbatim> prevents the linking but also breaks the highlighting.

-- BradMace - 2012-08-29

Any chance of Ruby support?

-- Todd Yamakawa - 2013-12-11

Todd: I just updated the plugin to auto-discover the supported languages. Please update the plugin. If needed, install the latest enscript, it supports Ruby.

-- Peter Thoeny - 2013-12-12

Hi guys, curious, I'm runnning TWiki-5.1.4, and tried to install this plugin, but everytime I goto the "FindMoreExtensions" app in the configure script, it doesn't appear to recognize that it's installed, however in the configure script itself, if I goto the "Plugins" section it appears there and I check the box to enable it, but it doesn't appear to work. I've checked and made sure that enscript is installed. Sorry if it's posted in the wrong section, trying to find the best place for this.

-- Dorien Takeshi - 2014-01-29

Best to open a Support question.

-- Peter Thoeny - 2014-01-29

Does anyone know any way to make it so you can display the numbers, but be able to select and copy just the code snippet (and not the line number) ?

Tried setting

numstyle="display:inline-block;  border-right: 3px solid #e0a95c;  color: #333;margin: 0 0.6em 0 -0.6em;  padding: 0 0.3em;  background-color: #eed6b4; -webkit-touch-callout: none; -webkit-user-select: none;  khtml-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none;"

... but the user-select CSS only works for selecting within a single range...

Then thought of javascript to toggle visibility of the numbering, but the numbers aren't elements with an id, so not easy to select and manipulate. Ideally, the numbers would be a true column inside a table..

-- Jon Hertzig - 2014-06-03

Good point on unwanted line numbers on a copy & paste. I can imagine an enhancement where the line numbers can be toggled on and off similar to a TwistyPlugin twisty. That toggle would change the display CSS from inline-block to none and back.

A two column table layout would not work because a long code line might wrap, which would add an offset to the line numbers if only one cell is used for the line numbers and one for the code. It would be possible to have a table row per code line, but then a copy would catch the line numbers as well...

-- Peter Thoeny - 2014-06-03

That's what I was thinking with the display toggle -- but I don't know enough javascript to be able to select just those numbers based on their CSS alone.... might ask Stack Overflow ... will report back.

-- Jon Hertzig - 2014-06-04

If there were a CSS class for the numbers, it would be easy -- something like

<input type="button" value="Toggle" onclick="twiki.JQueryPlugin.toggle('#CodeNumbers', 'toggle')" />

-- Jon Hertzig - 2014-06-04

Ended up using an include page with javascript, like so:

<head>
<style>
.Num {display:block;}
.noNum {display:none;}
</style>
<script type="text/javascript">
var toggleNumDiv = (function(){
   function toggle(cl){
       var els = document.getElementsByClassName(cl);
       for(var i=0; i<els.length; ++i){
          var s = els[i].style;
          s.display = s.display==='none' ? 'block' : 'none';
       };
   }
   return function(cl){
      if(cl instanceof Array){
         for(var i=0; i<cl.length; ++i){
            toggle(cl[i]);
         }
      }else{
         toggle(cl);
      }
   };
})();
var toggleNoNumDiv = (function(){
   function toggle(cl){
       var els = document.getElementsByClassName(cl);
       for(var i=0; i<els.length; ++i){
          var s = els[i].style;
          s.display = s.display==='block' ? 'none' : 'block';
       };
   }
   return function(cl){
      if(cl instanceof Array){
         for(var i=0; i<cl.length; ++i){
            toggle(cl[i]);
         }
      }else{
         toggle(cl);
      }
   };
})();
</script>

<div class="Num">
<div style=float:left><input type="image" src="%ATTACHURL%/nonum.png" class="Num" onclick="toggleNumDiv('Num');toggleNoNumDiv('noNum');"></div>
%CODE{"python" num="1"}%
%MYCODE%
%ENDCODE%
</div>
<div class="noNum">
<div style=float:left><input type="image" src="%ATTACHURL%/num.png" class="noNum" onclick="toggleNumDiv('Num');toggleNoNumDiv('noNum');"></div>
%CODE{"python"}%
%MYCODE%
%ENDCODE%
</div>

-- Jon Hertzig - 2014-06-05

I've made parameterized variables in the page that includes it, so you can just do:

%NUMCODE% <your code> %ENDNUMCODE%

where %NUMCODE% calls the include -- the one caveat is that the code snippet can't have any double quotes in it (") -- not sure how to get around that, escaping it didn't work...

-- Jon Hertzig - 2014-06-05

As per Support.SID-01932, I think it is better to enhance the plugin to toggle the line numbers.

-- Peter Thoeny - 2014-06-09

Agreed, thanks Peter!

-- Jon Hertzig - 2014-06-09

It would be nice to be able to pass a width option to enscript, or have the css wrap the text. Often I want to display very long lines and have them wrap.

-- Brian Egge - 2014-06-23

Good point, the plugin could be enhanced with an option to wrap long lines.

-- Peter Thoeny - 2014-06-23

Hi I can't figure out how to avoid this plugin from breaking numbered lists, any suggestion?

   1 Prova<br /> <sticky>%CODE{ lang="sql" }% 
select * from dual;
%ENDCODE%</sticky>
   1 Prova

-- Andrea Giovacchini - 2016-05-13

With numbered lists it is possible to have multiple lines for a single bullet; followup lines need to have leading spaces. This plugin likely produces multiple lines without leading space. It could be enhanced for your needs.

-- Peter Thoeny - 2016-05-13

This has long frustrated me about this plugin. The '</li></ul>' ends up before the <pre> after rendering.

I would like to see it work like <verbatim> does. Briefly looking at the perl code it looks like there's a takeOutBlocks/putBackBlocks pattern that would need to be employed and I'm not sure how that works.

...

Riffing on your suggestion about leading spaces, I added a space before the <pre> tag in the code and now it works exactly as I expect it to.

diff SyntaxHighlightingPlugin.pm.orig SyntaxHighlightingPlugin.pm     
152c152
<                 . "<pre class='syntaxHighlightingPlugin' style='$style'>"
---
>                 . " <pre class='syntaxHighlightingPlugin' style='$style'

-- Gerald Skerbitz - 2016-08-30