Extension talk:SyntaxHighlight GeSHi/Archive 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 <pre> border and background. When I display code using the <syntaxhilight> 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.

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

Problem solved... — Preceding unsigned comment added by Nouklea (talk • contribs) 16:27, 1 November 2011‎

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. — Preceding unsigned comment added by 59.172.234.163 (talk • contribs) 09:53, 14 December 2011‎

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:

 <syntaxhighlight lang="cpp" backgroundcolor="#FFAAAA">
  ...code...
 </syntaxhighlight>
 

and your code would be syntax highlighted and have the specified background color. — Preceding unsigned comment added by EliRibble (talk • contribs) 21:30, 11 May 2011‎

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 download.php with following content should be uploaded into extensions/SyntaxHighlight_GeSHi

<?php
	header("Pragma: no-cache");
	header("Expires: 0");
	if (isset($_POST["text"]) && isset($_POST["filename"])) {
	header("Content-type: application/octet-stream");
	header("Content-Disposition: attachment; filename=" . $_POST["filename"]);
	echo urldecode($_POST["text"]);
	}
	else{
		echo "Data not found";
	}
?>

function parserHook in file SyntaxHighlight_GeSHi.class.php is modified near the end.

	wfProfileOut( __METHOD__ );
	return $out;

is replaced by

 	if(isset($args['name'])){
		global $wgScriptPath;
		$encodedText = urlencode($text);
		$filename = $args['name']. "." . $lang;
		$form = <<<EOFORM
<p><code>$filename</code></p>
<form action="$wgScriptPath/extensions/SyntaxHighlight_GeSHi/download.php" method="post">
<input type="hidden" name="text" value="$encodedText" />
<input type="hidden" name="filename" value="$filename" />
<input type="submit" value="download script" />
</form>
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.

<syntaxhighlight lang="sas" name="example">... youre code</syntaxhighlight>

--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: <source lang=wiki>Some 'wiki' text </source>.--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 {{#tag:syntaxhighlight|Your content goes here|attribute1=value1|attribute2=value2}} --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( "<", '<', $text );
 $text = str_replace( ">", '>', $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. — Preceding unsigned comment added by 109.173.64.113 (talk • contribs) 08:50, 19 December 2011‎

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 <pre> 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 <tt>, <code>, and <pre> display in a suitable size in firefox, chrome, etc */
tt, code, pre {
    font-size: 1.25em;
}

There is a bug mentioning the problem Bug 26204 but it does not become clear to me if the problem can be fixed. Before we start putting energy in a solution does anybody know if there is a fix?

Jongfeli 13:47, 3 November 2011 (UTC)

Is there an established fix / workaround for this? If so, please add it. Thank you. GeneZ 16:15, 14 January 2012 (UTC)

I hope that maybe Gerrit change 15781 improves the situation.  « Saper // talk »  11:33, 17 July 2012 (UTC)

Dashed border is close to code

I just installed this extension (r90546) on my wiki (v1.18). I tried enabling the dashed border in common.css, but this didn't work. After any change I made I commented out the require... code on LocalSettings.php and refreshed my wiki page. Next I tried getting the dashed border by changing SyntaxHighlight_GeSHi.class.php and this worked, but the dashed border is very close to my text. In all the examples, there is some space between the border and text. Also, I tried enabling the Default DIV Based Rendering as shown, but then there was no dashed border, so I undid this change. — Preceding unsigned comment added by Scott216 (talk • contribs) 02:02, 18 January 2012‎

Also seeing this. Any fixes? Using the new editor if you click preview it appears fine in there. --86.14.89.140 00:24, 15 February 2012 (UTC)

Resolved this now. I followed the link given in method 2. Used the code change given there to resolve it. Had to disable, refresh, enable the extension before it would work though --86.14.89.140 00:51, 15 February 2012 (UTC)