Extension talk:SyntaxHighlight GeSHi/Archive 2008

From mediawiki.org

Syntax highlighting <syntaxhighlight> tags

Is there a way to syntax highlight <syntaxhighlight></syntaxhighlight> tags themselves?

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

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <syntaxhighlight>1.5</source​>
                <target>1.5</target>
            </configuration>
        </plugin>
    </plugins>
</build>

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

I edited your example above by adding zero width space between <syntaxhighlight and >. One way to do it is to type something like !&#x200b;! 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 <source> word. P.S. There still might be a better way to do it ∴ AlexSm 17:52, 22 January 2008 (UTC)Reply
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)Reply
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)Reply

Update: I just found out that #tag magic word is supposed to help you, used somewhat like this: {{#tag:source|lang="xml"|... ...}}. I couldn't get it to work though, you might have better luck. Look for #tag at meta: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:ExpandTemplatesAlexSm 19:06, 6 February 2008 (UTC)Reply

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 <syntaxhighlight> tag, it adds the line numbers, but the dotted box and colored background surrounding the code segment is no longer there. I would really like to keep that effect as it helps the code segments to stand out on the page from the non-code text.

Does anyone have any suggestions?

--Kursplat 05:11, 24 January 2008 (UTC)Reply

Try to put enclose="div" parameter in first source tag, it works for me. (I think it's some kind of bug with default pre enclose)
78.0.66.69 05:53, 1 August 2008 (UTC)Reply

About set_comments_style() function

I'm trying to configure the colors for certain data types. I've read the documentation here and found that this can be done invoking this function "$geshi->set_comments_style($group, $styles");. 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 $wgExtensionCredits['parserhook']['SyntaxHighlight_GeSHi'] 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 ) -IP 28 January 2008

haskell support

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)Reply

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

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)Reply

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)Reply
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)Reply
The fix works. Any further problems I'll report in the GeSHi Tracker. --Ccornell 11:28, 28 April 2008 (UTC)Reply

<source> in a List

I want to put a <source> 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)Reply

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?? --IP 2 April 2008

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)Reply

Alternatively, you could apply the following patch:
In the file SyntaxHighlight_GeSHi.class.php, before the defintion of the function initialise(), add the following function:
  private static function loadMessages() {
        static $messagesLoaded = false;
        global $wgMessageCache;
        if ( !$messagesLoaded ) {
                $messagesLoaded = true;

                require( dirname( __FILE__ ) . '/SyntaxHighlight_GeSHi.i18n.php' );
                foreach ( $messages as $lang => $langMessages ) {
                        $wgMessageCache->addMessages( $langMessages, $lang );
                }
        }
        return true;
  }
Then, in the same file, in the function initialise(), replace the call wfLoadExtensionMessages( 'SyntaxHighlight_GeSHi' ); by the following:
  if (function_exists('wfLoadExtensionMessages'))
        wfLoadExtensionMessages( 'SyntaxHighlight_GeSHi' );
  else
        self::loadMessages();
And lo and behold, things work again...
Cheers! Lexw 09:02, 27 May 2008 (UTC)Reply

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

mv src geshi

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)Reply

< and > converted in &lt; and &gt; and not shown properly.

Hi, I'm trying to highlight some XML but the result is very hard to read.

see for example www.wikijava.org/wiki/Sibling_Check_in_XSLT

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)Reply

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)Reply
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 (www.wikijava.org/wiki/Sibling_Check_in_XSLT) 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)Reply
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)Reply
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)Reply

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)Reply

It's already there. Just use set_overall_class, set_overall_id or set_overall_style ... --BenBE 12:09, 10 May 2008 (UTC)Reply
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)Reply
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)Reply
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)Reply

Delphi Syntax Highlighting

Please add two keywords into Delphi programming language highlighting scheme:

library
exports

--Arseniy.bocharov 07:24, 22 May 2008 (UTC)Reply

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)Reply

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:

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

Any clues? Thanks in advance, --Flominator 09:29, 28 May 2008 (UTC)Reply
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)Reply

GeSHi background problem

I'm using this extension on a wiki of mine, and I ran into a problem: when using the <source> 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:

//I'm just going to use C++ syntax for this:
#include <iostream>

int main()
{
    int bloop = 1;
    std::cout << "The value of bloop is [bloop]." << std::endl;
    //This would do the same thing as this bit of code:
    //std::cout << "The value of bloop is " << bloop << "." << std::endl;

    return 1;
}

In that code, I would like the "[bloop]" 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)Reply

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)Reply
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)Reply
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)Reply
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)Reply

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)Reply

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 --IP 19 August 2008

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? --IP 20 August 2008
It does work for me with the following snapshot:
SyntaxHighlight_GeSHi-MW1.12-r31252.tar.gz
--IP 20 August 2008
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 --IP 20 August 2008

The problem can be fixed by editing file "SyntaxHighlight_GeSHi.class.php". Go to line 262, 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. --KKreuzwieser 21 August 2008

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! --IP 26 September 2008

  • Thank you for the answer, but the line did not fix the css problem. --IP 28 August 2008
  • 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) $ --IP 2 September 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)Reply
  • 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. --IP 28 October 2008

If you want to see <syntaxhighlight> blocks highlighted and with dotted box, you may install SyntaxHighlight_GeSHi revision 37495 (get it from SVN repository). This is exactly the same version which is set at www.mediawiki.org and wikipedia and so on (you can see it e.g. at the page Special:Version). It solved the problem for me (I use WM 1.13.0).
I think the key to the problem is that GESHI_HEADER_PRE_VALID mode of GeSHi doesn't want to display with dotted box (I dont know why...), though it makes pre tags. So you need to use GESHI_HEADER_PRE (or GESHI_HEADER_DIV if you have line numbers). This is what revision 37495 does! You can read about it here http://qbnz.com/highlighter/geshi-doc.html#the-code-container also. --Vitvlkv 10 September 2008

  • 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? --IP 19 November 2008
Try GeSHi 1.0.7.21, not the higher ones. this one works. I think wikipedia is using that version. --IP 17 December 2008
  • I fixed this (only tested in Firefox) by changing my skin's "main.css" to include the "!important* directive on the various attributes for pre, ie:
pre {
	padding: 1em !important;
	border: 1px dashed #2f6fab !important;
	color: black;
	background-color: #f9f9f9 !important;
	line-height: 1.1em !important;
}

-- Automatist 22:31, 4 March 2009 (UTC)Reply

This alteration to monobook/main.css also seems to work for me with Safari v4b ViktorHaag 15:25, 21 April 2009 (UTC)Reply


The fix didn't quite work for me either, there was twice the normal blank space around the code. I commented out the lines redefining <pre> and <li> and now it works fine:
$css[] = '<style type="text/css">/*<![CDATA[*/';
$css[] = ".source-$lang {line-height: normal;}";
//$css[] = ".source-$lang li, .source-$lang pre {";
//$css[] = "\tline-height: normal; border: 0px none white;";
//$css[] = "}";
$css[] = $geshi->get_stylesheet( false );
$css[] = '/*]]>*/';
$css[] = '</style>';
This is with MediaWiki 1.13.5 on FF 3.5b4 and Google Chrome.
But why are they overridden in the first place? -- 99.185.243.218 21:22, 15 May 2009 (UTC)Reply


Actually, to fix this problem without getting the larger than normal space problem just metionned, I did the following change in file "SyntaxHighlight_GeSHi.class.php" at line "222"

Changed from:
$css[] = "\tline-height: normal; border: 0px none white;";
To:
$css[] = "\tline-height: normal; border: 1px dashed #2f6fab;";
It works perfectly!
You may as well remove the border info since that the default value. And that ways, if the WikiMedia theme changes, the syntax highlighted code will change with it.
$css[] = "\tline-height: normal;";
99.185.243.218 17:50, 28 May 2009 (UTC)Reply

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)Reply

I looked around a bit more on the fact that it wasnt working for the code tag either and found the answer.
Project:Support desk
88.151.1.10 12:15, 11 September 2008 (UTC)Reply

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)Reply

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:
  static function getEncloseType( $args ) {
		// Since version 1.0.8 geshi can produce valid pre, but we need to check for it
		if ( defined('GESHI_HEADER_PRE_VALID') ) {
			$pre = GESHI_HEADER_PRE_VALID;
		} else {
			$pre = GESHI_HEADER_PRE;
		}

		// "Enclose" parameter
		$enclose = $pre;
		if ( isset( $args['enclose'] ) ) {
			if ( $args['enclose'] === 'div' ) {
				$enclose = GESHI_HEADER_DIV;
			} elseif ( $args['enclose'] === 'none' ) {
				$enclose = GESHI_HEADER_NONE;
			} elseif ( $args['enclose'] === 'table' ) {
				$enclose = GESHI_HEADER_PRE_TABLE;
			}
		}

		if( isset( $args['line'] ) && $pre === GESHI_HEADER_PRE ) {
			// Force <div> mode to maintain valid XHTML, see
			// http://sourceforge.net/tracker/index.php?func=detail&aid=1201963&group_id=114997&atid=670231
			$enclose = GESHI_HEADER_DIV;
		}

		return $enclose;
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) --IP 28 October 2008

If you read GeSHi documentation this is expected. SyntaxHighlight GeSHi shouldn't use GESHI_HEADER_PRE_VALID by default, because it will use <div> as a code container and wiki doesn't put border around <div> section.

Vchepkov 16:13, 21 January 2009 (UTC)Reply

Newer versions of GeSHI very purposefully suppress the pre borders. This is expected. In Wikimedia's older version that they show is a bug, apparently. Splarka 12:34, 17 February 2009 (UTC)Reply


I'm sorry, but has someone actually suggested a way to enable borders here? Is that what the above code is supposed to do? If not, how can I enable borders?

solution is above in "Problem with CSS: Default style for pre is overwritten"

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)Reply

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

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)Reply

Yes, it should as I will not take care to produce stable source in the branch. --BenBE 16:33, 28 January 2009 (UTC)Reply

huge problem after installing

After I followed the installation instructions my wiki looks like this: screenshot. Can anyone please help me? --IP 3 November 2008

You've downloaded the wrong file.
You've downloaded [1] 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: [2]
-- MichaelFrey 17:05, 4 November 2008 (UTC)Reply

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)Reply

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)Reply

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. 20 January 2009
Frankk74, I just had a similar problem and was about to take your advice and restart apache, when I made a small amendment to the entry I was testing on, it fixed all the formatting bits an pieces I had been attempting. MW must be caching these pages assuming nothing is changing on the backend. I am a bit more comfortable now. - ChrisKing. 9 February 2009