Extension talk:SyntaxHighlight GeSHi/Archive 2010

Parsing hiccup for Ruby
I think the Ruby syntax highlighting of the current GeSHI version is incorrect when highlighting here documents: Correct me if I'm wrong: I think everything between the delimiting identifier should all be in string literal color. I won't enter this as a bug to bugzilla myself. Thanks, --Abdull 23:26, 27 January 2010 (UTC)
 * Fixed in upstream. And be happy I checked here. Bugs and Feature Requests that affect the language files ALWAYS should be reported upstream. --BenBE 12:30, 2 May 2010 (UTC)

Which version of GeSHi is installed?
I didn't see "R" as one of the languages recognized, and I recently read that version 1.0.8.6 will parse "R" code. -- Avi 03:43, 25 February 2010 (UTC)
 * ping. -- Avi 16:56, 17 March 2010 (UTC)
 * In case they update 1.0.8.8 would be a good starting point. --BenBE 12:31, 2 May 2010 (UTC)
 * I see rsplus for R and S+. (:-)) --Adam majewski 17:32, 2 March 2011 (UTC)

It doesn't work: Returns:

-- Avi 03:04, 14 April 2011 (UTC)

Line Wrap does not work
I tried every line parameter, but Line Wrap does not work. Any suggestions? --Laquestianne 16:08, 4 March 2010 (UTC)

Try enclose="div" --62.161.120.3 10:22, 13 July 2010 (UTC)

Make line numbers show by default
Does anyone know how to make the code show line numbers by default? I know from the documentation that I should use this source:

But I'm not sure where to place it.

--Weirdy12 19:40, 4 March 2010 (UTC)

Support for JSON format
It would be nice if you can integrate support for JSON format? Currently you can use "text" as source, but then a JSON array fills the whole line.

217.111.18.215 16:09, 17 March 2010 (UTC)


 * Wouldn't you just use "javascript" ? --98.204.58.109 07:30, 23 March 2010 (UTC)

Default pre style, revisited
I didn't like the suggested CSS fix to add back the border around pre format, because it also adds a border around div format. The following rule variation adds the border only for pre, allowing you to avoid the border by using enclose="div". A disadvantage though is that it doesn't add the border for numbered pre listings. .mw-geshi > div[class] > pre.de1 { padding: 1em; margin: 1em 0; border: 1px dashed #2F6FAB; } —GregU, 23 March 2010

Issue with Unicode Highlighting in XML (Strict Block Detection)
The following has an issue:

I don't think it's handling Unicode characters too well! - Tbsdy lives 00:47, 26 April 2010 (UTC)
 * Thanks for the note. I had a look at the example and could reproduce it locally, but IDK when I'll get around to fix this. --BenBE 12:37, 2 May 2010 (UTC)

CSS changes in new default template
The code markup displayed with the new default template looks ugly. In particular, it significantly changes the previous font-size, breaking the layout of many pages.

Compare for example:

XeTeX (using the old template and CSS)

with:

XeTeX (uding the new template and CSS)

is there a way to override the style settings for an individual code block? --90.193.89.221 20:58, 6 June 2010 (UTC)


 * If you want to bypass the grey background and related formatting set from Geshi.css at en.wikipedia you can try adding  to the GeSHi tag to disable the   on which the formatting is applied. Due to this annoying bug involving   I tried to figure out a better hack that actually allowed to override the CSS, but up to now I had no success - neither at HTML/markup level nor at user CSS level. --Duplode 04:12, 10 June 2010 (UTC)

Special:Version Broken
Since installing the plugin, the Mediawiki page Special:Version has been broken. It throws up this error:

Guy.yedwab 14:34, 1 July 2010 (UTC)


 * Fixed when class_exists check is added to the hSpecialVersion_GeSHi function in SyntaxHighlight_GeSHi.class.php. --Tom.nagels 21:23, 25 January 2011 (UTC)

/**        * Get the GeSHI's version information while Special:Version is read */       public static function hSpecialVersion_GeSHi( &$sp, &$extensionTypes ) { global $wgExtensionCredits; if(!class_exists('GeSHi')) { require_once( 'geshi/geshi.php' ); }               $wgExtensionCredits['parserhook']['SyntaxHighlight_GeSHi']['version'] = GESHI_VERSION; return true; }

Enable use within templates
Currently, you can't use wikitext inside of a

That block is right before the line

So far, so good. I've looked at $IP/includes/parser/Parser.php and the methods it makes available. I've tried using them on the $parser variable passed in to parserHook, I've tried initializing my own. Nothing I do seems to be right. Either I get no effect, the page comes back completely empty, or virtually everything gets prefixed by UNIQ...QINU, so clearly everything is going haywire.

I've spent all the time I can afford trying to spend trying to make this work. Can someone tell me what I need to insert inside that IF block that will cause the contents of $text to be converted to the value of the variable?

The line to enclose it all
Wanted to know how to do the line around the code like how they have it for code examples at the following page. see this page. Can anybody point me to the script they used? Gman124 16:17, 13 July 2010 (UTC)

A bizarre bug involving REGEXPS
I'm writing a highlighter for a language I'm working on, and anytime I try and define a regex expressions for REGEXPS it causes a strange bug for the syntax highlighter. This doesn't happen if I use the "simple" format specified in the documentation. It's the "advanced" that causes the bug. I've set up an example of the way it should look here, and the bugged version is here. The current source code is here. If anyone could provide some help, it would be much appreciated. 108.1.245.194 03:00, 29 July 2010 (UTC)

Read source from a URL
This is a new feature request.

I'd like to use the syntax highlight

You may assume the url does not require authentication.

The link=true attribute would add an external URL link to the actual URL (after the source); it is convenient but but is not necessary.

--DavidBiesack 13:58, 6 August 2010 (UTC)


 * I recently wrote a patch for this kind of feature (without the link attribute) Extension:SyntaxHighlight_GeSHi_remote -- Sascha, 3 February 2011

Automatic Syntax Highlight By Page Title
Here's some useful code so that a page that ends with, for instance, .py, it will be automatically highlighted as python code. Dunno why this hasn't been done before. It's not too hard:

/**	 * Hook into Article::view to provide syntax highlighting for * pages that end with common source-code extensions */	public static function viewHook( $parser, $text ) { global $wgSyntaxExtensions; //Check if title or not $title = $parser->getTitle; $article = new Article($title); if ($article->getContent != $text) { return false; } // Determine the language if ( preg_match( '!\.('.implode('|',$wgSyntaxExtensions).')$!u', $title, $matches ) ) { $lang = $matches[1]; if ( $lang == 'txt' ) { $lang = 'text'; } if ( $lang == 'py' ) { $lang = 'python'; } if ( $lang == 'f90' ) { $lang = 'text'; } if ( $lang == 'sh' ) { $lang = 'bash'; } if ( $lang == 'js' ) { $lang = 'javascript'; } $text = str_replace(' ';		}

static $hasRun = false; if ($hasRun) return true; $hasRun = true;

return true; }

and

$wgHooks['ParserBeforeStrip'][] = 'SyntaxHighlight_GeSHi::viewHook';

Cheers, Douglas

Template inside highlight
I made a template:

http://www.vtk.org/Wiki/Template:VTKCMakeLists

Then I tried to use this template like this:

But you can see here: http://www.vtk.org/Wiki/VTK/Sandbox/UseCMakeListsTemplate

that it does not trigger the source code to be highlighted, but rather actually includes the source tag as part of the text on the page.

Is there a way to do this?

Thanks!

Daviddoria 02:25, 17 September 2010 (UTC)

Inserting visible "&nbsp"
hey folks,

are there any known issues with the extension for inserting visible $nbsp;'s and MW 1.16? The highlight of the source code is correct, but there are several visible nbsp's in the lines.

for example: is shown as $nbsp; echo "Hello World"; the $ is the placeholder for &, just to show it here.

MW 1.16 php 5.3.3 mysql 5.1.50 ext.vers. 1.0.8.8

Thanks in advance.

CSS NCR rendered incorrectly
GeSHi says:  I would say: LI { CONTENT : " \2022 " }

The problem is reportedly fixed upstream, please upgrage GeSHi to the latest version.

--Žekřil71pl 19:19, 3 October 2010 (UTC)

Displaying linebreak
Hey, is there any way I can use linebreaks in my code? I would like to present a .css file and highlighting works fine. Nevertheless, all the information is just one batch of text, the linebreaks are not working.

Thanks

POV Ray
Hi. This must have been a massive task and it looks great, but I've just tried using tag is used to hightlight it. So what about to include it to this extension, that it might highlight the wiki syntax somehow?--Juan de Vojníkov 11:52, 11 November 2010 (UTC)
 * How can one add a new language syntax, like that of S-Lang? And how can one add a missing reserved word for an existing language, like for C# (should be bold and navy blue)? Thank you! Sae1962 10:46, 8 August 2011 (UTC)

A bug: Last line stripped off.
If you've got source code with an empty line as the last line, that last line will be stripped off. For example, the following should have three lines: This is not a Geshi bug! --Paxed 22:23, 19 November 2010 (UTC)

Alternative Hook To "syntaxhighlight"
I'm using Mediawiki and this extension for a code snippet repository and it's working great. I am finding typing "syntaxhighlight" all the time to be a little cumbersome, so I added the following to the " " in the " " function: $parser->setHook( 'sh', array( 'SyntaxHighlight_GeSHi', 'parserHook' ) ); Now I can just use "sh" in addition to "syntaxhighlight". --SLeepdepD 05:44, 3 December 2010 (UTC)

For those editing the css within the class file
In the tutorial on the page, it tells you how you can just edit the class.php file to get a border (or other things) around the box.

I'm pretty new to Media Wiki, so as I was tinkering with my css, I realized that it wasn't updating whenever I reloaded the page. (Like I hoped)

The solution: The solution I found eventually, that in order for the content to be regenerated, you need to hit the edit button then save it again. (Although this can cause problems with the page versions)

--199.126.247.197 04:57, 26 December 2010 (UTC)