Extension talk:SyntaxHighlight GeSHi/Archive 2015

Please do not make requests for support for languages or bug reports for highlighting errors on this page. This extension uses the GeSHi library, which is not maintained by the MediaWiki developers. Bug reports and feature requests for the highlighting should be made to the GeSHi developers.

=2011=

Border around every line when line numbers are displayed
I installed rev:50696 on MediaWiki 1.16. I followed the discussion in the 2008 archives about editing the SyntaxHighlight_GeSHi.class.php and the main.css files in order to display the usual  border and background. When I display code using the tool with only the language specification, everything works fine. But when I ask for the line numbers to be displayed, there is a border around every line, which is really ugly. Here is a printscreen of my wiki :



Any idea on how to fix this? Thanks! -- Nouklea

After help from the Support Desk, I reinstalled the extension and undo the changes I made to the skin's css files. I then added the following code to the my MediaWiki.css page (not MyWiki.css page!), and the problem was solved. Problem solved...
 * ThX Nouklea, this really helped me. But I modified the skin's css file and add above since I could not find MediaWiki.css. Fortunately, it worked.

1.0em/1.2em
The plugin for v1.16, r62591 uses aforementioned notation. Which is a rather obscure way to say "1em font-size and 1.2em line-height, please". Sadly, this fails in both FF4 and Safari 5 (which seem to consider it a division). I recommend against using it. 217.6.212.138 13:14, 20 May 2011 (UTC)
 * I proposed to get rid of this styling in Gerrit change 15781. « Saper // talk »  11:29, 17 July 2012 (UTC)

Change background color
I wanted to be able to change the background color of the highlighted code, so I took the liberty of adding the functionality. Here's the patch to apply to SyntaxHighlight_GeSHi.class.php

24a25,26 > 		static $codeAreaNumber = 0; > 		$codeAreaNumber += 1; 57a60,66 > 		// Background colors > 		if( isset( $args['backgroundcolor'] ) && $args['backgroundcolor'] ) { > 			$backgroundcolor = $args['backgroundcolor']; > 			$geshi->set_overall_style('background-color: '.$backgroundcolor, true); > 		} > 		$geshi->set_overall_id( 'codeArea'.$codeAreaNumber ); > 			 91c100 < 		$parser->mOutput->addHeadItem( self::buildHeadItem( $geshi ), "source-{$lang}" ); --- > 		$parser->mOutput->addHeadItem( self::buildHeadItem( $geshi ), "source-{$lang}-{$codeAreaNumber}" ); 363c372 < } \ No newline at end of file --- > }

If I could find information on the maintainer of this project, I'd be happy to send the patch in. After applying the patch you can then do the following:

and your code would be syntax highlighted and have the specified background color.


 * unfortunately this causes problems when you have a padded code box. you need to include in the script to colorize the entire code box 167.230.104.94 07:35, 22 September 2011 (UTC)

How to enable download of the embedded code
I extended SyntaxHighlight GeSHi so that each code fragment can be given a button to download it as a file. You can see an example on page http://freeplane.sourceforge.net/wiki/index.php/Scripting:_Example_scripts (actually this page uses an older extension GeSHiHighlight but the idea is basically the same).

Following modifications are required:

file  with following content should be uploaded into extensions/SyntaxHighlight_GeSHi

function  in file   is modified near the end. is replaced by     EOFORM; $out = $form.$out; }	wfProfileOut( __METHOD__ ); return $out; DimitryPolivaev 21:41, 5 January 2011 (UTC)

It was unclear to me how this would be called on a wiki page once implemented. All you have to do is add name="filename" to your syntax highlight tag. --Effulgent (talk) 09:19, 5 April 2012 (UTC)

Language

 * I'm disappointed MW Syntax isn't an option. Really disappointed. --67.124.37.29 20:49, 26 September 2011 (UTC)
 * The Geshi language files are easy to write - I wrote SPARQL syntax and it takes me 1 hour. If you'll write MW syntax don't forget to share it!!--Katkov Yury 12:27, 28 October 2011 (UTC)


 * Yes, strangely, the wiki language is not an option: .--Nbrouard (talk) 12:21, 12 March 2012 (UTC)
 * This should probably be reported upstream. In case anyone is interested, the documentation on how to write a language file can be found on this page. Helder 13:10, 12 March 2012 (UTC)

Using template parameters in tag.
By default it's impossible to user triple braced parameters inside sytntaxhighlight tag. If you want to use them, you need to hack an extension a bit:


 * Maybe I missunderstood but isn't that what the Magic word #tag should be used for? One can have the following on the template --Carandraug (talk) 18:48, 23 June 2012 (UTC)

In file SyntaxHighlight_GeSHi.class.php, line 23: substitute this line public static function parserHook( $text, $args = array, $parser) with these two lines: public static function parserHook( $text, $args = array, $parser, $frame ) $text = str_replace( "&lt;", '<', $text ); $text = str_replace( "&gt;", '>', $text ); $text = $parser->recursiveTagParse($text, $frame); This helped me, I hope it will help you too! Dear developers, would you mind to add these two lines to your code? --Katkov Yury 01:40, 30 October 2011 (UTC)

Alternate version
I got it working this way: substitute this line public static function parserHook( $text, $args = array, $parser) with this line: public static function parserHook( $text, $args = array, $parser, $frame )

place this: $out = $parser->recursiveTagParse($out, $frame); before return $out; at the very end of the function.


 * Please include this! Otherwise provide a user side workaround (I can't change the files of the extension!). Thanks 188.155.39.154 17:40, 2 April 2012 (UTC)

Transclusion Trick
You can bypass this flaw by simply using the Template Transclusion trick. What i did was create a Template for the source open and close tags.

Caveat:
 * if used within a documentation style container, the closing tag is not used but instead is interpreted as part of the body of the code. Thereby including it in the context of the source representation.

refer to: Template:Src as a reference. Goldbishop 17:05, 5 February 2012 (UTC)

Font size issues
We use MediaWiki 1.16.5 and the default SyntaxHighlight extension, no mods. The extension works fine but the font size in Firefox 7.0.1 is very small. In IE 7.0 it looks ok. We know there are font size issues in Firefox and Chrome when using  in MediaWiki 1.16. These should be fixed in 1.17. We can not move to 1.17 at the moment and fixed this temporary by adding the code below in shared.css /* Fix so ,

and the content of http://my.server.com/my_dir/my_source.java will be inserted and highlighted in your page.

To add this to the extension, quite simple, just add the following lines if ( isset( $args['extlink'] ) && $args['extlink'] ) { $text = file_get_contents ( $args['extlink'] ); }

in SyntaxHighlight_GeSHi.php near line 50 just above the line $geshi = self::prepare( $text, $lang );

"&lt;syntaxhighlight&gt; is recommended"
Extension:Collection (which is used to create downloadable PDFs or books from WMF pages) doesn't support &lt;syntaxhighlight&gt;, only &lt;source&gt; (see 29136). I wonder, therefore, if we should remove from this page the statement that "&lt;syntaxhighlight&gt; is recommended"? —Ruakh TALK 20:10, 28 February 2012 (UTC)
 * Reopening the bug should be enough. syntaxhighlight is still recommended, but you can use source as a workaround until the Collection extension is fixed. Reach Out to the Truth (talk) 02:18, 29 February 2012 (UTC)
 * This seems to be working now, although it fails to honour the  parameter. —Phil | Talk 17:07, 27 November 2012 (UTC)

Vote to make box and border pre the default
Personally I think geshi should look like other pre boxes, should the following be included in MediaWiki:Geshi.css by default?

div.mw-geshi { padding: 1em; margin: 1em 0; border: 1px dashed #2f6fab; background-color: #f9f9f9; }

Better still could be to remove the problem css that strips the skin default. CSS like this... .source-winbatch li, .source-winbatch pre { line-height: normal; border: 0px none white; } and .winbatch.source-winbatch .de1, .winbatch.source-winbatch .de2 { font: normal normal 1em/1.2em monospace; margin: 0; padding: 0; background: none; vertical-align: top; }

Just my thoughts. Thanks for a great extension.

I hope that maybe Gerrit change 15781 improves the situation (with empty MediaWiki:Geshi.css, which is the MediaWiki default). « Saper // talk » 11:33, 17 July 2012 (UTC)

README still suggests to use 'source' tag
README file still suggests to use "source" tag - probably should be updated --Richlv (talk) 11:06, 2 April 2012 (UTC)

Not displaying colors when formatting?
Having this issue on 1.18, anyone else experiencing this? How do I fix?


 * Whats your sample code? did you use a valid value inside of, lang?

Support for additional class
The standard gray background and dashed border looks great for most of the snippets but we have a scenario where we have examples of good and bad snippets of code. With our previous manual way of syntax highlighting code, we were able to apply a different class to highlight the code light green with a check in the upper right for good code, light red with an X in the upper right for bad code. In order to support the same functionality with this extension, we added a new attribute to the tag and had to modify SyntaxHighlight_GeSHi.class.php, line 122 to support it. Note that you may want to add the change to the other part of the condition there. In addition, we had to add !important to our CSS to get it to override the other selectors: So now we can use the new addclass attribute on the extension: Mattsmith321 (talk) 20:35, 25 August 2012 (UTC)
 * Before:
 * After:
 * I like this idea in concept, do you have a link to an example page with a few examples of this in action? ShoeMaker  ( Contributions &bull; Message )   12:15, 12 March 2013 (UTC)

Dynamic CSS styles overwrite the ones from MediaWiki:Geshi.css
Hello. With MediaWiki 1.19.1 and SyntaxHighlight 1.0.8.10 the dynamic CSS styles are added after the link to the MediaWiki:Geshi.css and MediaWiki:Common.css stylesheets. As a result most of the attributes defined in MediaWiki:Geshi.css are overwritten by Geshi and it is impossible to extensively modify the styles without modifying the php files.

This can be fixed by removing the "addHeadItem" call in SyntaxHighlight_GeSHi.class.php (line 105) but then all styles must be statically defined in MediaWiki:Geshi.css.
 * --93.182.180.21 00:13, 28 August 2012 (UTC)

Empty page as a result of highlighter's work
MediaWiki v.1.17.0

I installed SyntaxHighlight GeSHi like it is said in the manual:

1) got the extension into /extensions svn co http://svn.wikimedia.org/svnroot/mediawiki/trunk/extensions/SyntaxHighlight_GeSHi

2) edited LocalSettings.php require_once("$IP/extensions/SyntaxHighlighter/SyntaxHighlighter.php");

Then I tried to use it in example from manual:

And it gave me empty page both at preview and saved page. Like, completly empty, blank page. What do I do wrong? 195.19.36.139 17:19, 12 September 2012 (UTC)


 * Got the empty page of death too. I couldn't solve the problem and I was realy frustrated, but after updating from MW 1.17 to MW 1.19.2 the problem went away by itself. I mean, I installed the extension the same way and now it works. Abagnale OS Ubuntu 11.04; MW 1.19.2; MySQL 5.1.61; PHP 5.2.17 19:24, 27 September 2012 (UTC)

Font size small in 1.20
I had a problem with the most recent version of this extension on my installation of 1.20 MediaWiki. It being that the size of the text, being rather small. I added this to MediaWiki:Geshi.css: This seems to fix the small text. --Inops (talk) 23:45, 25 November 2012 (UTC) Oh, and I was getting the problems with the latest stable release of Google Chrome. --Inops (talk) 23:51, 25 November 2012 (UTC)

Download does not work
Hi,

trying to obtain a download from http://www.mediawiki.org/wiki/Special:ExtensionDistributor/SyntaxHighlight_GeSHi I receive the error message '''Invalid response from Extension Distributor remote client. '''.

Any help (to get the version for MW 1.17) would be appreciated!

regards

--80.149.87.126 14:05, 7 December 2012 (UTC)


 * Now it did work, must have been a temporary dysfunction.


 * --80.149.87.126 08:19, 10 December 2012 (UTC)

=2013=

How can I mimic this?
For example, if I wanted to make an extension, FooHighlight, and every instance of the word "bar" between the tags was colored purple and everything between { and } was colored green, what would I do? I am a complete newbie to PHP.

Custom User Defined Languages
Could someone make a basic how-to page to give the general idea for creating our own .css for custom languages. For example, I would like to add the ability to have it work with AHK (AutoHotKey) scripts. Thank you. -- ShoeMaker  ( Contributions &bull; Message )   14:25, 7 February 2013 (UTC)
 * Answering my own question here. The how-to create your own language documentation can be found at http://qbnz.com/highlighter/geshi-doc.html#language-files -- ShoeMaker   ( Contributions &bull; Message )   14:41, 7 February 2013 (UTC)

Request for pseudocode highlighting
Since pseudocode is typically used for explaining algorithm, it would be nice if this extension supports pseudocode highlighting by default. In my thought, it should highlight words like for, while, each, function, return, if, in, ... --Nullzero (talk) 18:25, 11 February 2013 (UTC)

Generic HTML
Why there is not a general value HTML for all types of (X)HTML? I dont see a reason to have there html4strict and html5 while highlight ways are the same. How I can highlight XHTML 1.0 Transitional, than?--Juandev (talk) 11:21, 15 March 2013 (UTC)

Wiki links
Is there not a way to include wiki links inside the code block?


 * You mean like:

Yeah - notice how the link is not rendered as a link ??? "Page_About_Options" would be the link target, "this option" would be the link text


 * Technical 13 (talk) 21:43, 10 May 2013 (UTC)


 * I now understand your question fully. &lt;syntaxhighlight> is a &lt;pre> substitute that offers highlighting.  There can be no active links inside by its very definition.  See HTML element. Technical 13 (talk) 01:54, 11 May 2013 (UTC)

lang for Mediwiki Code ?
What language in your opinion is best for rendering Mediawiki code, e.g. Wiki Syntax, templates, SMW extensions ? Or does anyone think that we could petition for someone to write a "mediawiki" module for Geshi (sorry I can't). Greetings !- Daniel K. Schneider (talk) 14:00, 12 June 2013 (UTC)
 * I personally use lang="bibtex" as it seems to be the closest to me. I have thought about writing a MWML module, but do not currently have the skills to do so or the time to invest into it. Technical 13 (talk) 12:33, 17 June 2013 (UTC)
 * Cool ! thanx a lot. Yes code is much more readable than my other attemps, e.g. JavaScript, Perl, XML, ... (see here (I am trying to learn semantic mediawiki/forms and write down as I play ...) - Daniel

Underscore not displaying properly
I noticed that the following code isn't displaying properly...

The underscore in the "print count_to" isn't displaying on en:User:Theopolisme/help/Matty.007 to me.
 * Displays just fine for me on MW and enwiki using  Theopolisme (talk) 18:39, 8 July 2013 (UTC)


 * It displays properly here for me but not on en: using the exact same code. Odd.  I'm using FF22 FWIW. Technical 13 (talk) 18:41, 8 July 2013 (UTC)

SASS
Any plan for including  and/or   source languages to the extension?

80.230.3.58 11:51, 26 July 2013 (UTC)

Use pre tags?
Is there anyway to make it automatically do syntax highlighting for code in  tags?
 * "Why would you want to do that?", would be my first question. The answer is, if you modify the php for the extension, you could make it work for any element/tag you wanted.  Problem is,   is part of the HTML standard, so your new users wouldn't be expecting that output from it, and might not want/like it (especially since it would return an undefined language error unless you created a default, which would be poor because there are so many languages and to assume that one will always be the most popular is a bad idea).  Now, I agree that   is kind of long to type out, and would request the developers of this extension to add a   alias. Technical 13 (talk) 12:05, 26 August 2013 (UTC)