Extension talk:SyntaxHighlight GeSHi/Archive 2015

download problems
The download link doesn't exist. IS this the correct link? http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi/ 21:01, 4 April 2007 (UTC)


 * It was renamed a few days ago, thanks for catching this. -- Duesentrieb ⇌ 23:58, 4 April 2007 (UTC)

Installation, calls, and initial blank wiki screen of death
The text states that geshi.php is created, but the require once code talks about SyntaxHighlight_GeSHi.php, should that be geshi.php in the require once? --12.148.245.61 14:26, 19 September 2007 (UTC)

-


 * peblusto says:
 * no, there are two different calls to the two different downloaded and installed program groups.
 * we should have at least this directory / file structure:


 * .../ourwiki/...
 * .../ourwiki/LocalSettings.php


 * .../ourwiki/extensions/...
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/...
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.i18n.php
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php


 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/geshi/...
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/geshi/geshi.php
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/geshi/contrib/...
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/geshi/docs/...
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/geshi/geshi/...


 * then, in
 * .../ourwiki/LocalSettings.php
 * put the call to the extension
 * and in the extension support file,
 * .../ourwiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php
 * make sure there's an accurate call to the program supporting the extension
 * make sure there's an accurate call to the program supporting the extension


 * then if we get the initial blank wiki page / screen of death syndrome, try opening each php source file in a text editor and re-saving each again as text. i found that windows notepad saw no formatting inside the downloaded php files.  windows wordpad did bring them on screen okay, properly formatted.  so, after re-saving each of the main php files above from within wordpad as text, then notepad also saw the files formatted as text.  also, most important, the wiki screens came back to life.  we may have translation goofs between systems causing the source php files to loose their structure when exported and imported from system to system.
 * - peblusto 19:15, 18 October 2007 (UTC)

Fatal error: Call to undefined method
Fatal error: Call to undefined method ParserOutput::addHeadItem in ...\wiki\extensions\SyntaxHighlight\SyntaxHighlight_GeSHi.php on line 113

I'm work with windows apache2 & php5, and i have already tried to take some older versions, but nothing changed.

I think ParserOutput::addHeadItem was added quite recently - so the current version of this extension only works with the current development trunk. You will have to use an older version with MW 1.9. -- Duesentrieb ⇌ 11:25, 5 April 2007 (UTC)

Yea, try this version: -- Duesentrieb ⇌ 11:28, 5 April 2007 (UTC)

DSig
I originally downloaded the current version of SyntaxHighlight_GeSHi.php pointed at by the article. I put the php into the extensions directory. I unzipped the current GeSHi. it created a GeSHI-1.0.7.19 directory with geshi directory inside of it. I then moved the geSHi directory into the extensions directory.

so we have

extensions (dir) SyntaxhHighlight_GeSHi.php geshi (dir) (everything under geshi)

I modified the LocalSettings.php to point to the correct location require_once("extensions/SyntaxHighlight_GeSHi.php");

I got a couple of errors on require so using echo i worked out directories but then i get

Fatal error: Call to undefined function efSyntaxHighlightMessages in C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\wikiSanMar\extensions\SyntaxHighlight_GeSHi.php on line 65

I have tried both the originally posted code and then the older code noted above.

Ideas? I am sure it is something to do with where I have located it all as I doubt that this would have been posted without it working. SO fire away .. where have I gone all wrong

Thanks

213.186.1.162 10:47, 13 April 2007 (UTC) Try changing efSyntaxHighlightMessages to efSyntaxHighlight_GeSHiMessages. Worked for us!


 * This worked great .. thanks --Dtsig 19:02, 24 April 2007 (UTC)

I gave up
For those that just want highlighting without jumping through hoops, I ended up using this GeSHi extension on my 1.7+ wiki:

GeSHiHighlight.php

Fatal error: Call to undefined method - Has there been a resolution to this yet?
I was having the same issue as above:

Fatal error: Call to undefined method ParserOutput::addHeadItem in ...\wiki\extensions\SyntaxHighlight\SyntaxHighlight_GeSHi.php on line 113

Attempted this:

Yea, try this version: -- Duesentrieb ⇌ 11:28, 5 April 2007 (UTC)

which led to:

PHP Fatal error: require_once [function.require]: Failed opening required '/var/www/html/devwiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight.i18n.php' (include_path='/var/www/html/devwiki:/var/www/html/devwiki/includes:/var/www/html/devwiki/languages:.:/usr/share/pear') in /var/www/html/devwiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php on line 59

Is there any updates on this or am I going to have to use a different extension for this?

remember to download all the files here >>> http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi/

One Solution - rename files and variables to match calls to them
You need to rename the file "SyntaxHighlight.i18n.php" to "SyntaxHighlight_GeSHi.i18n.php"

Then inside either file make sure the names:

"efSyntaxHighlightMessages"

"efSyntaxHighlight_GeSHiMessages" Match, pick one, and rename it and your away, not sure what version we are playing with here but its now working for me, all I care about.

Yes, It works for me
Thank you, who written the message above. The steps are followed

In SyntaxHighlight_GeSHi.php

First, rename the file "SyntaxHighlight.i18n.php" to "SyntaxHighlight_GeSHi.i18n.php"

Second, find this require_once( dirname( __FILE__ ) . '/SyntaxHighlight.i18n.php' ); change to require_once( dirname( __FILE__ ) . '/SyntaxHighlight_GeSHi.i18n.php' );
 * and find this

foreach( efSyntaxHighlightMessages as $lang => $messages ) change to foreach( efSyntaxHighlight_GeSHiMessages as $lang => $messages )

--Roc michael 03:54, 30 June 2007 (UTC)
 * Mediawiki 1.9.2
 * The AppServ Open Project - 2.5.7 for Windows
 * Apache Web Server Version 2.2.3
 * PHP Script Language Version 5.1.6
 * MySQL Database Version 5.0.24a
 * phpMyAdmin Database Manager Version 2.9.0.2

What about further version of mediawiki?
I try it with 1.9.3 and the latest highlight-files and get an error that look similar: "Fatal error: Call to undefined method ParserOutput::addHeadItem in /opt/lampp/htdocs/labbook/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.php on line 127"

Why it is so sensitive to the used version.

What is the alternative extension, to highlight bash and perl, which is more stable?

Inline usage
Is there a way to highlight a small piece of code inline, i.e. make &lt;source> into &lt;span>? I tried enclose=none but it doesn't work (while enclose=div does work) -- Alex Smotrov 16:54, 21 May 2007 (UTC)

References use in comments
hi,

It seems we can't use the tag in comments. (sorry for my really poor English). 82.226.213.114 00:57, 29 May 2007 (UTC)

solution for me - Replaced the $parser
Replaced the $parser->mOutput->addHeadItem( ... )-Code with:

$out = "/*<![CDATA[*/\n". ".source-$lang {line-height: normal;}\n". ".source-$lang li {line-height: normal;}\n". $geshi->get_stylesheet( false ). "/*]]>*/ \n$sitecss".$out;

It is very VERY ugly and not valid, but FF2 and IE7 seem to show it properly.

1.9.3 and character parsing in SyntaxHighlight
This works great with the following exception.

Characters like < > get changed to their html equiv &lt etc

These characters are *kind of* important in source :)

I would have thought that this extension should bypass wiki/html parsing .. yes? As we see above a PRE protects the angle brackets .. shouldn't source

fyi .. This same behavior is found in 1.10.0 ..

Has anyone else seen this? Thanks --Dtsig 15:20, 5 June 2007 (UTC)


 * If you allow stuff like <> then you open a big hole for things like javascript ....
 * And what's possible with javascript is (do say it friendly) not nice (phishing, steal passwords ...).
 * If you need the "nacked" code use &action=raw&ctype=text/javascript&dontcountme=s example:
 * Anyway: I don't see you're problem, because with copy&past "highlighted" sources work well.
 * -- MichaelFrey 15:42, 5 June 2007 (UTC)


 * '.. don't see you're problem .. ' I am not sure what you are saying here. What source did you copy&paste?   The fact that a < becomes &lt is a problem.  I will look at the link you posted. --208.214.103.202 20:30, 5 June 2007 (UTC)
 * hmmm German .. sorry I do not understand it. --Dtsig 20:33, 5 June 2007 (UTC)


 * Why or when is the &lt a problem for you?
 * I mean all actual Browsers like FF 2.0 and IE 7.0 render the source code correct.
 * You say, "PRE protects the angle brackets" but when I look at into the HTML source of that talk page, I see also the html equivalents of.
 * Anyway, sorry that my link was wrong, her 2 correct examples:
 * Again: If the extension bypass things like < > it is a hole for Cross-site scripting and similar things.
 * -- MichaelFrey 15:44, 6 June 2007 (UTC)

Language that doesn't work yet
Hi,

I participate in writing the Wikibook about Haskell.

GeSHi doesn't support Haskell yet, but it might in the near future (see the feature request).

In the meantime, if i try to write  or something else.

Is it possible to modify this extension for that?

If this is not the right place to propose it, please tell me what is the right place.

Thanks in advance. --Amir E. Aharoni 16:55, 8 June 2007 (UTC)


 * I entered a feature request in Bugzilla: 10201 Allow showing code in an unsupported language with a warning. Come on and vote for it if you like it :) --Amir E. Aharoni 18:27, 8 June 2007 (UTC)


 * It should be supported in GeSHi 1.0.7.20. Can we have that updated here please? 62.181.57.12 04:37, 21 August 2007 (UTC)

Undefined method addHeadItem
I just tried installing this extension, and I'm pretty sure I followed the directions exactly, but I'm getting the error:

[04-Apr-2007 21:01:29] PHP Fatal error: Call to undefined method ParserOutput::addHeadItem in ...\extensions\SyntaxHighlight_GeSHi\SyntaxHighlight_GeSHi.php on line 113

--159.140.254.10 02:09, 5 April 2007 (UTC)


 * yes, I'm getting this one to – just that now it's line 144. Might it be that the PHP version is not sufficient? My PHP version is 4.4.4 - what is the minimum version required for SyntaxHighlight GeSHi? --Leo141 15:05, 29 June 2007 (UTC)
 * Oops, how could I oversee that there are some answers on this here ... The workaround at works for me too. --Leo141 17:08, 29 June 2007 (UTC)

Error when passing parameters from templates
As GeSHi doesn't have any functionality for in-line syntax highlighting yet, I figured I could create a template for that:

I'm a sys-op, so I can edit the CSS files and add the .inline_code class. But the GeSHi plugin complains about not getting a lang="" parameter.

My guess is that MW runs the stuff before it's passing the parameters from the template. Not sure at all, just guessing.

See the error and a brief explanation on http://no.wikibooks.org/wiki/Bruker:August/GeSHi_issues ( I tried no:wb:Bruker:August/GeSHi issues but that linked to wikipedia, not sure about the syntax).

Regards, August Lilleaas, sysop @ norwegian wikibooks.


 * Just made myself an account here, in case someone needs to contact me directly that's a bit more convenient now. --Leethal 12:39, 4 July 2007 (UTC)

I don't have an answer to your template parameter problem, but as for inline &lt;source>: So the only way so far I could make it inline requires putting the whole paragraph inside &lt;div>: div.inline_code * {display:inline} &lt;div class=inline_code> Your text &lt;source enclose=div lang=javascript>document.write&lt;/source> your text again &lt;/div> I think the better solution is to request inline source on bugzilla: Alex Smotrov 16:38, 5 July 2007 (UTC)
 * block elements are not supposed to be inside &lt;span>, so in html Mediawiki moves your &lt;span> inside &lt;pre>
 * Mediawiki encloses all text before and after block elements into &lt;p> tags
 * CSS:
 * wiki:

Graceful death?
When there are improper source tags the script generates a large error box, could you remove that. It should display nothing if broken. see:
 * Without linenumbers

2. And could someone add Estonian translation, to SyntaxHighlight_GeSHi.i18n.php /* Estonian et:Kasutaja:M2s17 */ 'et' => array( 'syntaxhighlight-specify' => 'Sa pead täpsustama keelt nõnda:', 'syntaxhighlight-supported' => 'Süntaksi esiletoomise on toetatud järgnevates keeltes:', 'syntaxhighlight-err-loading' => '(toetatud keelte loetelu laadimisel esines viga)', 'syntaxhighlight-err-language' => 'antud keel on mittekehtiv', 'geshi.css' => '/* CSS mis on asetatud siia, määrab GeSHi süntaksi esiletoomise stiili */', ), --88.196.91.126 22:42, 20 July 2007 (UTC)


 * Localisation added in r24296, thanks. As to the first question, I'm not sure if I understand, but I'll give it a bash.


 * The question, as I understand it, is why everything looks a bit different when using line numbers. As you'll spot in the HTML source, when line numbers are in use, we have to use a &lt;div&gt;, rather than &lt;pre&gt;, which means that the grey background and dashed border don't show up. If you'd like this, then you can style the surrounding &lt;div&gt; elements to look the same, using some CSS in MediaWiki:Monobook.css:


 * Hope this helps. robchurch | talk 01:18, 21 July 2007 (UTC)

== internal links within // Request WinSendMsg(hwndWnd,blabla...
 * }

Using messages highlighting and internal links may be great thing for programmer's wiki --Evgen 11:56, 27 July 2007 (UTC)
 * Using internal links is possible with simply adding a keyword group in the appropriate language file and telling it the documentation URL is your Wiki. Please note the comment on external links mentioned above. --217.93.203.194 10:12, 26 April 2008 (UTC)


 * 1) There is no "external links mentioned above" easy to find.
 * 2) I backed out of using it on Manual:Wiki family as one has to ask somebody to configure something to even link to Manual:$wgLogo style names here on . Jidanni 01:33, 27 December 2008 (UTC)

Support for Mediawiki markup
Can we work with the GeSHi developers and add our wiki markup to the supported languages? Then we can provide examples of our own code much more easily. 71.167.62.22 00:34, 10 August 2007 (UTC)


 * peblusto asks: do you mean other than  ? - peblusto 19:15, 18 October 2007 (UTC)

Fatal error: Call to undefined method ParserOutput - after install
I have installed the GeSHi Syntax Highlighter,

now on save an edit i got the following Error:

Fatal error: Call to undefined method ParserOutput::addHeadItem in /var/www/slr_wiki/extensions/SyntaxHighlight_GeSHi/SyntaxHighlight_GeSHi.class.php on line 66

Greetz Phillip

I'm having the exact same problem... any solution? metasim

I need an old and stable version
Hello,

I need an OLD but STABLE version of this extension that works with these settings:

* MediaWiki: 1.6.7 * PHP: 4.3.10 (apache2handler) * MySQL: 4.1.10a

(I can't explain it, but) there is NO WAY to update one of these settings!!!!!!!

I did try to find the right extension-version by combining the information of the extension-page-history with the subversion repository but nearly gave it up.

Might this one be the right one for me? http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Highlight/?pathrev=19695

What about 20985? I can't evaluate the position :-(

Can someone help me?

Post-install PHP Warning: call_user_func_array
After installing (as per the main page), when I try to test by including a some source (for example by copying any of the sample code directly) I get nothing on the screen (e.g. it does not render at all, the wiki page just skips that line). When checking /var/log/httpd/error_log I get something like:

PHP Warning: call_user_func_array [function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'SyntaxHighlight_GeSHi::parserHook' was given in /var/www/mediawiki/includes/Parser.php on line 436, referer:

Any suggestions would be greatly appreciated. --M0nstr42 16:51, 22 August 2007 (UTC)

I am having the same issue. --Snapper67 11:09, 5 September 2007 (UTC)

I had almost the same problem. After some investigations, I found that the problem comes from some incompatibilities with PHP 4. So, if you are using php 4 like me, you need an old version of this extension.

Try getting the revision 23537 :

svn co -r 23537 http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi

And then apply the workaround. --omar.belkhodja 21:38, 13 October 2007 (UTC)

I have the same problem and am running php5. Any assistance? -- Robert
 * You are probably using an old version of PHP5; try changing the 'SyntaxHighlight_GeSHi::parserHook' to array('SyntaxHighlight_GeSHi', 'parserHook') Bryan 19:12, 25 July 2008 (UTC)

I have still the same problem (MediaWiki 1.5.5/PHP 5.1.2) -- Michael PHP Warning: call_user_func_array [<a href='function.call-user-func-array'>function.call-user-func-array</a>]: First argument is expected to be a valid callback, 'SyntaxHighlight_GeSHi::parserHook' was given in /srv/www/htdocs/mediawiki/includes/Parser.php on line 427, referer: Parser.php on line 427 is ... if ( $render ) { $ext_content[$tag][$marker] = call_user_func_array( $callback, array( $content, $params, &$this ) );; } else { $ext_content[$tag][$marker] = "$full_tag$content</$tag>"; } ... SyntaxHighlight_GeSHi.php ... function efSyntaxHighlight_GeSHiSetup { global $wgParser; $wgParser->setHook( 'source', array( 'SyntaxHighlight_GeSHi', 'parserHook' ) ); return true; } ...

Change the background color?
Is there a way to change the background of the rendered code table? I know that I can change it in the lang.php file but I'd expect there is a way to have a default background shared by all. I noticed that it creates a css class called "source-lang". Should I just create one myself in my wiki css file (I suppose there is one, somewhere :D) or is there some magic parameter that I can set? Thanks! -Adal
 * If you can do it by altering the CSS class, you might find this extension useful, which allows a parser function to dynamically load a css article that is on the wiki rather than a css hard coded into the mediawiki file system --Zven 23:45, 28 August 2007 (UTC)
 * I now remember putting some notes up on bioperl wiki which are useful as well --Zven 04:27, 29 August 2007 (UTC)

Upgrading to 1.11.rc1
Hi, after updating to MW 1.11.rc1 i get the following error.

'''Detected bug in an extension! Hook syntaxHighlightLoadMessages failed to return a value; should return true to continue hook processing or false to abort.'''

The top of the code box is getting chopped off in IE
I just installed this extension on my site, and it looks great in Firefox, but in IE the top of the code box is getting chopped off. The code is formatted correctly, but the first few lines don't have the background box, and the top border is missing. I checked your site as well, and I get the same behavior -- looks great in FF, not so much in IE. As much as I'd love to tell everyone to use FF, my site is a corporate site where IE is the standard. Any ideas? Thanks --ColinLittle 20:33, 28 September 2007 (UTC)
 * This is apparently not a problem in IE7. I'm using IE6 -- ColinLittle 21:15, 28 September 2007 (UTC)
 * For those still using IE6: It appears to be a problem with GeSHi's    block element being put inside a     element without anything else in the div. To fix this, look for the following line in SyntaxHighlight_GeSHi.class.php:

return ' '. $out. ' '; and change it into return ' &amp;nbsp;'. $out. ' '; and the block element will render correctly. If anybody can come up with a way to insert a character without taking real space on the page, that would be nice though. Dannyh 23:20, 1 April 2008 (UTC)

Doesn't work on 1.9.2
I tried and tried to get this one to work on my wiki. I have installed several extensions and am not new to this, but I could not make this work. I even tried using some of the suggestions on this page, but nothing worked.

I tried this GeSHi extension and it worked right out of the box. http://www.mediawiki.org/wiki/Extension:GeSHiCodeTag

Just thought I would post this for others who can't get this to work for them.

Installation Instructions - Line does not exist
If needed, change the following line in SyntaxHighlight_GeSHi.class.php to suit the path of your geshi.php file require_once( 'geshi/geshi.php' );

That line does not exist there ! --Arcy 19:34, 14 October 2007 (UTC)


 * peblusto says: i searched for "require" in my text editor and found it okay in the current version r24298 (July 21, 2007) - peblusto 19:15, 18 October 2007 (UTC)

This lines work for me (Mediawiki 1.11.0)
Just Add // change directory >> /usr/local/src/geshi/ << according to your geshi installation include_once('/usr/local/src/geshi/geshi.php'); $languagesPath = "/usr/local/src/geshi/geshi";

to the top of SyntaxHighlight_GeSHi.php

--Arcy 18:57, 15 October 2007 (UTC)

Translating an attribute style=""
Hello, i don't know if its the right place, but... I would like to know if its possible to add a function to this extension. At fr.wikipedia.org, we use for the tag  the style. It will be very nice if the tag  translate the style into is first element. With it we can easily change the height of the code, background, or border, text size...

For example, , with it we can change the height of the code, our  add scroll if need. Thanks a lot. fr:user:bayo 14:37, 17 October 2007 (UTC)

It doesn't work for me
Hello, I tried everything I get no error messages whatsoever but I can't get any highlighting either.

my pages look like:

including AND showing the using space to divide parameters is not a wiki standard, the standard is dividing by |.
 * Personally, I don't see any value in this additional syntax. Besides,  is mostly used in templates, and this is a tag, not a template Alex Smotrov 22:34, 18 December 2007 (UTC)

Language Specific Tags
For a site I'm working on most of the code is in one language, so I wanted a simpler tag. I added an extra parser hook: Which allowed me to use tags. Thought someone else might find it useful. It might be nice to have an option to list languages and have it add short tags like this. --Haarg 08:16, 19 December 2007 (UTC)

== Syntax highlighting tags themselves?

I need to highlight the following snippet of XML code, but the embedded tag indicates that syntax highlighting should end. Encoding the tag (for ex: &lt;/source>) won't work either, since this is interpreted literally (ex: translated to &amp;lt;).

--Shelley 17:01, 22 January 2008 (UTC)


 * I edited your example above by adding zero width space between  and  . One way to do it is to type something like   in wikitext, click "Show preview", copy the result from preview into wikitext and then remove exclamation signs. This worked in Firefox 1.5. You can "feel" this symbol in your example above if you move the text cursor through the   word. P.S. There still might be a better way to do it ∴ AlexSm 17:52, 22 January 2008 (UTC)
 * While the result looks fine in Firefox and Opera, unfortunately IE (at least IE6) actually displays this Unicode character, so I guess this wasn't a good solution :( ∴ AlexSm 17:56, 22 January 2008 (UTC)
 * Thanks for the idea. This enables the appropriate formatting in the browser (at least Firefox2 & IE7), but unfortunately, I would like to be able to enable copy-and-paste of the source for reuse outside of the browser. When copying this text, the white space character is also copied (which, in the case above, results in invalid XML). Any other ideas would be appreciated! --Shelley 17:01, 23 January 2008 (UTC)

Update: I just found out that #tag magic word is supposed to help you, used somewhat like this:. I couldn't get it to work though, you might have better luck. Look for #tag at Magic words, note that it seems it also depends on the new parser (now enabled on en.wp and test.wp), and you can also try to experiment in Special:ExpandTemplates ∴ AlexSm 19:06, 6 February 2008 (UTC)

Line numbers and formatting
I just installed this extension and it works fine. I noticed, however, that if I add the "line" argument to the. The problem is that I don't know where I have to put it.

Another question, although I'm setting the key 'line' to true in the array  inside SyntaxHighlight_GeSHi, line numbers doesn't seem to apper. Does anyone know why ?

If someone can help me with this I'll be very grateful :)

(sorry about my English :P )

haskell
The svn-repository for GeSHi doesn't include support for haskell, however, the latest release (download here) includes that file (and it works fine in my wiki, see here). As far as I can tell, Haskell is the only language that is not included in the svn-repo, so you might want to add a note? -- Mati 13:48, 30 January 2008 (UTC)


 * An update was requested with Bug 10967 (2007-08-17). Raymond 18:48, 31 January 2008 (UTC)

Empty delimiter errors
I am using this extension on the OpenOffice.org wiki, and everywhere we are using the oobas lang, we are getting loads of "Empty Delimiter" errors:

Warning: stristr [function.stristr]: Empty delimiter. in space/mediawiki-1.11.0/extensions/SyntaxHighlight_GeSHi/geshi/geshi.php on line 2127

An example on the live wiki... http://wiki.services.openoffice.org/wiki/UNO_registery_and_Bootstrapping

This only seems to happen with lang=oobas. What can I do to fix this other than going through thousands of Wiki pages and changing lang=oobas to something else? --Ccornell 09:13, 13 March 2008 (UTC)
 * The mystery deepens.... sometimes the error shows, and other times, the page looks perfect, with no edits between a broken page display and a correct page display. Any assistance with tracking this error down would be appreciated. --Ccornell 12:39, 13 March 2008 (UTC)
 * The bug is related to an error in the oobas language file. After the keyword 'mod' there's an empty keyword specified, that causes the trouble. Fixed in next stable. Feel free to report such bugs to the official GeSHi tracker at SourceForge --217.93.203.194 11:39, 26 April 2008 (UTC)
 * The fix works. Any further problems I'll report in the GeSHi Tracker. --Ccornell 11:28, 28 April 2008 (UTC)

Memory usage huge?
I was happy of the extension until... I tried a source lang=diff of 2300 lines and it died after having exhausted the available memory (told me about failed allocation of 135Mb of RAM) and a source lang=diff of 520 lines, when saving the page the display page died with a "script didn't return after 30s"

2300 lines is big, ok, but does it justify 135Mb of RAM??

&lt;source&gt; in a List
I want to put a &lt;source&gt; in a ListEntry (* ...) and below a ListEntry (: ...). So that the source-Block doesn't start at the beginnig at the line. How to do that? 217.91.56.172 15:44, 1 April 2008 (UTC)

Last version from SVN does not work with MediaWiki 1.10
The current head version of SyntaxHighlight_GeSHi.class.php use the function "wfLoadExtensionMessages" that is introduce in 1.11. You have to use previous SVN revision (28481) to get this extention working with mediawiki 1.10.x. --62.147.241.233 12:28, 3 April 2008 (UTC)
 * Alternatively, you could apply the following patch:
 * In the file, before the defintion of the function  , add the following function:


 * Then, in the same file, in the function, replace the call   by the following:


 * And lo and behold, things work again...
 * Cheers! Lexw 09:02, 27 May 2008 (UTC)

Latest GeSHi: Don't link against trunk!
Although http://geshi.svn.sourceforge.net/svnroot/geshi/trunk/geshi-1.0.X/src/ is reasonably stable most of the time it may or may not work properly at all times. Please use http://geshi.svn.sourceforge.net/svnroot/geshi/branches/RELEASE_1_0_7_STABLE/geshi-1.0.X/src/ instead as this will only get patches that will end up in the release and thus will always include a running version of GeSHi.

Side note: After checking out to src you simply can do a instead of softlinking\hardlinking those two directories. This will save you some trouble as Apache sometimes causes problems with stuff being crosslinked in the filesystem.

--BenBE 12:00, 26 April 2008 (UTC)

converted in &amp;lt; and &amp;gt; and not shown properly.
Hi, I'm trying to highlight some XML but the result is very hard to read.

see for example this page.

Any idea how to show this properly?

I've
 * geshi 1.0.7.21
 * SyntaxHighlight GeSHi r24298 (July 21, 2007)

thanks,

--DonGiulio 20:49, 1 May 2008 (UTC)
 * That's at least not the fault of GeSHi, but seems a problem that somehow escaped HTML is passed to GeSHi. Please make sure that only unescaped HTML get's passed.


 * Maybe you should try updating the SyntaxHighlight_GeSHi extension to a more recent revision.


 * --BenBE 11:13, 2 May 2008 (UTC)


 * I just uploaded the SVN version of the extension. and I still get the issue. I believe that it is caused from the fact that source is called using a template. having a better look on the page I realized that in the page (this one) some "less than" are corrected some other no, in particular the broken ones are generated using the template. How could I solve that?


 * Thank you very much,


 * --DonGiulio 12:18, 2 May 2008 (UTC)


 * I believe the problem is caused by the tag extension. Using the tag #tag that was needed for proper conversion of the template attribute into its value. I don't know what would be best, if to fix the tag extension or the geshi highlight in order to fix this problem. Maybe a different extension would fix the problem? Does anyone have experience about it?


 * thanks --DonGiulio 00:59, 10 May 2008 (UTC)


 * As mentioned before: It's not a bug in GeSHi, but in one of the extensions you use. Crap in --> Crap out. --BenBE 12:11, 10 May 2008 (UTC)

Adding a general style
Something I've hacked into my local copy of this is adding the class "highlighted-source" to the div enclosing the output from geshi. This allows me to have a format for all source code styles, whether they include line numbers or not. This seems like a good thing to add to the base code. Haarg 22:49, 9 May 2008 (UTC)


 * It's already there. Just use set_overall_class, set_overall_id or set_overall_style ... --BenBE 12:09, 10 May 2008 (UTC)


 * Of course you can do anything you want if you modify the extension code. The point of the modification though is to simplify formatting code blocks using MediaWiki:Common.css or MediaWiki:Geshi.css.  I've already made the changes needed for me, but I think they would be useful to others using this extension.  I initially tried to use set_overall_class to do what I wanted, but couldn't see any way to have it use multiple classes (highlighted-source and source-$lang). — Haarg 01:21, 11 May 2008 (UTC)


 * IIRC classes in CSS are separated by using spaces. thus you'd probably use class="class1 class2" for two classes (Unchecked, but if I remember the CSS specs right, should do). Have a look at http://www.frontpagewebmaster.com/m-134791/tm.htm for some details on multiple CSS classes for one element. --BenBE 16:13, 12 May 2008 (UTC)


 * They are separated with spaces in HTML, but not in CSS. geshi uses the classes given for both the HTML and the CSS it generates, and isn't expecting multiple classes.  Giving it 'highlighted-source source-$lang' would result in invalid CSS.  The output from geshi is already being wrapped in a div, so the simplest thing is to just add a class to that div. — Haarg 09:41, 13 May 2008 (UTC)

Delphi Syntax Highlighting
Please add two keywords into Delphi programming language highlighting scheme: --Arseniy.bocharov 07:24, 22 May 2008 (UTC)
 * Actually this is an issue with GeSHi, not this plugin. I added the suggested ones (and some other ones I just happened to come accross. Feel free to report other missing keywords directly to the developement page of GeSHi at SourceForge.net. --BenBE 23:00, 25 May 2008 (UTC)

Bash problem
I have a weird problem highlighting bash source code with this extension. When I try to highlight this one:

echo "$(date +%c) :: $LOADAVERAGE :: $CPULAST" >> ${LOGFILE}; echo "$(date +%c) :: $LOADAVERAGE :: $CPULAST" >> ${LOGFILE_ALL};

it turns into this (note the pipe symbols "|"):



My installation of Serendipity using GeSHi as well, on the other hand, does it do the right way:



I thought it was a problem with this extension, but then I realized that this installation here on mw.org does it do correctly, as well:

Any clues? Thanks in advance, --Flominator 09:29, 28 May 2008 (UTC) PS: My configuration is noted at Image:Geshi mediawiki.png, I use r35333 of this extension.


 * There has been added a feature recently that highlights symbols in the source. As this feature partly overrides already highlighted regular expressions there will be an addition soon, coming with GeSHi release 1.0.7.22. (There also the mentioned behaviour is fixed again). --BenBE 19:13, 1 June 2008 (UTC)

GeSHi background problem
I'm using this extension on a wiki of mine, and I ran into a problem: when using the &lt;source&gt; tags, I can't figure how to have the gray canvas background that is there normally. I've already asked for help on MWUsers.com, to no avail. If I'm not explaning this well, I have an example set up here. The first example isn't using GeSHi, and it has the canvas background. The second one does use it and, while the spaces are there, no background shows up. I haven't made any chances to the code, though I have added one additional language file.

Also, while I'm here, is there any way to have this highlight something inside a string? This language has embedded expressions in strings (if you don't know what that is, look below, as I don't know how many languages even use these) and I'd like to have them highlighted so their more visible. For example: In that code, I would like the "[bloop]</tt>" bit to be a different color.

Any help on either of these would be much appreciated!

24.145.19.247 00:37, 14 August 2008 (UTC)
 * The feature regarding highlighting special bits inside a string is not yet supported in the form you are trying to use it, but I was thinking about about implementing something like this in some upcoming version of GeSHi, although this might still take some time. You'll find a not on the GeSHi changelog as son as it is implemented. --BenBE 21:18, 16 August 2008 (UTC)
 * Preliminary support for Escape Regexps has just been committed to trunk in Revision r1772-r1774. See the PHP language file for details on usage. Please report any bugs regarding this feature to the GeSHi-devel mailing list. --BenBE 00:22, 17 August 2008 (UTC)
 * Okay, sorry for sounding like a complete idiot, but where is that? I looked at the few places I can think of and I can't find it. =/ 24.145.19.247 09:07, 23 August 2008 (UTC)
 * Checkout http://geshi.svn.sourceforge.net/svnroot/geshi/trunk/geshi-1.0.X/src/ with an SVN client (just as said on the main page) and look into geshi/php.php for an example. --BenBE 12:28, 25 August 2008 (UTC)

Strict Mode Parameter meaning
I'm unsure about how the strict paramter for the source tag is supposed to be used, as GeSHi 1.0.8 adds another strict type GESHI_MAYBE while replacing false and true with GESHI_NEVER and GESHI_ALWAYS. Some more information on the exact usage (maybe an example) would be appreciated. --BenBE 21:18, 16 August 2008 (UTC)

Problem with CSS: Default style for pre is overwritten
Hi, the generated output contains CSS classes which overwrite the default pre stlye rules.

How can I change the renedered classes rules? (In my case .source-csharp li, .source-csharp pre and .csharp.source-csharp .de1, .csharp.source-csharp .de2) A quick fix was to declare the base CSS class rules as important, but that's only a hack.

Thanx for help in advance. PJ

Same problem here. Code is highlighted, but without background box, because default pre style is overwritten.

MediaWiki 	1.12.0 PHP 	5.2.0-8+etch11 (apache2handler) MySQL 	5.0.32-Debian_7etch6-log

Any idea?

-> It does work for me with the following snapshot:

SyntaxHighlight_GeSHi-MW1.12-r31252.tar.gz - Thanks for the feedback. I will try the snapshot. But I'd still like to know how I can change the generated CSS class wich is causing the trouble. I found some lines in geshi.php, but not the right one. Perhaps some expert does know how to do it. PJ

The problem can be fixed by editing file "SyntaxHighlight_GeSHi.class.php". Go to line 192, which should look like $css[] = ".source-$lang {line-height: normal;}"; Change this to $css[] = ".source-$lang {padding: 1em; border: 1px dashed #2f6fab; color: black; background-color: #f9f9f9; line-height: 1.1em;}"; and you have restored the pre css formatting.

Addition to the point above (2008-09-27): Please note that this didn't take effect for me immediately, it appears PHP caches the class. After making the change to the class as above, comment out the include from LocalSettings.php and refresh your page. Then un-comment out the include and refresh. Worked perfect here, good luck!

Thank you for the answer, but the line did not fix the css problem.

It did fix my problem, which wasn't doing pre tags for any language. I am using MW 1.11.0, geshi 1.0.8, syntaxhighlightgeshi $LastChangedDate: 2008-07-10 08:45:20 -0400 (Thu, 10 Jul 2008) $

The fix is not needed for MSIE, but does not work in FF 3.0.1. See my Test page and my MediaWiki version (MW 1.13.1, geshi 1.0.8.1). I tryed SyntaxHighlight_GeSHi MW1.13-r37906, trunk-r40401 and trunk 40580. --Milan Keršláger 13:59, 7 September 2008 (UTC)

This fix works for me using MSIE(2008-10-28), thanks a lot. The trick is ''comment out the include from LocalSettings.php and refresh your page. Then un-comment out the include and refresh.''

If you want to see in   does not change in trunk so Special:Version lie about current version. Even that r37495 nor r40968 does not work. One should debug CSS to find where correct attributes are lost. --Milan Keršláger 01:08, 18 September 2008 (UTC)

I tried the code change mentioned above and it fixed this problem in IE6 and FF3. I am using the download link listed in the original instructions (http://geshi.svn.sourceforge.net/svnroot/geshi/branches/RELEASE_1_0_X_STABLE/geshi-1.0.X/src/) and MW 1.12. R590

I tried the code change and it works for FF3. However, IE6 is still not behaving properly. I am using Mediawiki 1.13.2 and Geshi 1.0.8.1 with SyntaxHighlight_GeSHi.php from 9-28-2008.

Any suggestions?

Try GeSHi 1.0.7.21, not the higher ones. this one works. I think wikipedia is using that version.

(RESOLVED)Problem with code overflowing page width and no scroll bars
I have recently installed this extension on a new wiki at my work place.

I can see the highlighted code syntax correctly.

If there is a long line of code it flows past the border on the right of the page and looks pretty bad.

On the examples in this extension page, if i resize the page to make it narrow the code does not overflow, a horizontal scrollbar appears.

How do i make this scrollbar appear on my wiki?

The same thing happens when i use the code tag. Any info would be appreciated. Thanks

Danny 88.151.1.10 12:08, 11 September 2008 (UTC)

I looked around a bit more on the fact that it wasnt working for the code tag either and found the answer.

http://www.mediawiki.org/wiki/Project:Support_desk#.28RESOLVED.29_No_scrollbar_for_source_code

88.151.1.10 12:15, 11 September 2008 (UTC)

Border error
Hi! Why my standard installation of "SyntaxHighlight GeSHi" in MediaWiki software not produce border. I've Perl test sytntax:

Test syntax: http://i38.tinypic.com/biq7om.png

This's produce code without border: http://i38.tinypic.com/2a8qlnp.png

Page source: http://i35.tinypic.com/xmilc3.png

Please Help Me! :)

--Danny373 14:04, 3 October 2008 (UTC)

Also experiencing this issue with no border showing by default. I tried using the enclose tags to no avail.

Also wanted to suggest the following to allow use of the GESHI_HEADER_PRE_TABLE:

I would also like to suggest to expand on the usage within the README file to make it clear which $args are valid and how to use them. I found pointing to the Geshi documentation not that helpful.

--alexsch8 11:10 AM, 28 Oct 08 (EDT)

SVN "relocated"
If I check http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi/, I can see the files fine. However, if I try to check it out from SVN or TortoiseSVN, I get the message

"svn: Repository moved permanently to '/viewvc/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi/'; please relocate"

As far as I can tell, that's the exact same path as in the URL I pasted. Any thoughts?--SarekOfVulcan 18:03, 9 October 2008 (UTC)


 * Use /svnroot/ instead of /viewvc/. -- Sayuri 19:10, 9 October 2008 (UTC)

README
Should the README file be updated to reflect the stable branch svn URL of GeSHi rather than the trunk path? NSK Nikolaos S. Karastathis 01:15, 27 October 2008 (UTC)

huge problem after installing
After I followed the installation instructions my wiki looks like this: screenshot. Can anyone please help me?


 * You've downloaded the wrong file.
 * You've downloaded instade of open this link.
 * When you've opended this link, choice a revision and click on the download link.
 * Same procedre for the other files:
 * -- MichaelFrey 17:05, 4 November 2008 (UTC)

internal bookmarks
I administrate a wiki about programming, and some of its content is source code. I would like to link from the documentation of each element to the element itself in the source on the same page. I've figured out how to break out of the tags to insert an id'ed span element, but this forces readers to tediously highlight the source one small segment at a time. Does GeSHi support bookmarks yet? If not, can they be supported? Thanks! --Jesdisciple 05:16, 12 November 2008 (UTC)

Border/css/pre Problem is back
Guys is it possible that the Quarterly MW release 1.13 broke this extension? I am running 1.13.3. Only the CSS hack above fixed the problem (combined with apache restart as well). Could this is be a parameter passing issue as well? Thanks everyone! Frankk74 05:12, 29 December 2008 (UTC)

I confirm that the border problem is present in the latest version of GeSHi (as of 20-Jan-2009). The above CSS hack worked wonders. Thanks! liyf.

Not using external stylesheet
The documentation for GeSHi states:

in particular, if you’re making a plugin for a forum/wiki/other system, using an external stylesheet is a good idea!

Still, this extension outputs the CSS for used classes inline, in the  function. This is inelegant (includes presentation information in HTML code), wasteful (a block of CSS for every page request) and redundant (in case an installation also uses the MediaWiki:Geshi.css page).