Last modified: 2007-05-15 11:38:32 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9163, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 7163 - Install SyntaxHighlight_GeSHi extension on Wikimedia wikis
Install SyntaxHighlight_GeSHi extension on Wikimedia wikis
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal enhancement with 14 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: shell
: 8146 9322 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-29 15:53 UTC by Yuri Astrakhan
Modified: 2007-05-15 11:38 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Yuri Astrakhan 2006-08-29 15:53:02 UTC
Please enable the Highlight extension. This will be an enormous value to
WikiBooks as well as Wikipedia itself. Thanks.
Comment 1 Yuri Astrakhan 2006-08-30 18:33:06 UTC
Clarification: The highlight extension allows source code to be
color-highlighted depending on the programming language. A wiki text:

<source lang="c">
 int a = 10;
</source>

will highlight int as a keyword, and show 10 as a constant, based on the rules
of the C language.
Comment 2 Rob Church 2006-08-30 19:03:12 UTC
We know what it is.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-05 05:10:59 UTC
*** Bug 8146 has been marked as a duplicate of this bug. ***
Comment 4 Tim Starling 2007-03-28 16:00:35 UTC
It needs the following changes:

1. Efficiency fix:
https://sourceforge.net/tracker/?func=detail&atid=670231&aid=1688864&group_id=114997
2. Defer loading of geshi.php until the hook is called. Deferring message
initialisation would also be advisable.
3. Use strings for the "line", "case" and "header" parameters instead of
requiring numeric input. Numeric input deprecated and undocumented.
Comment 5 Tim Starling 2007-03-28 16:01:32 UTC
*** Bug 9322 has been marked as a duplicate of this bug. ***
Comment 6 Tim Starling 2007-04-01 11:42:34 UTC
Upstream issue is reported to be fixed.
Comment 7 Ramir 2007-04-01 11:53:40 UTC
> Upstream issue is reported to be fixed.

So… is there hope now that the extension will be installed within the next couple of years?

I actually would like to know this, since we at ru.wikibooks have started to make an ugly JavaScript workaround 
for this.
Comment 8 Tim Starling 2007-04-03 23:10:02 UTC
I made the changes myself, it's now live on test.wikipedia.org.
Comment 9 Ramir 2007-04-04 10:23:24 UTC
Great! Does this mean that this'll work on the real thing 
soon? Thanks a lot, anyway.

May I give two modest suggestions:
1. To use <code>, a valid HTML tag, instead of <source>. 
The idea is to encourage the use of <code>, even if 
without syntax highlighting. Why? To be able to make 
distinct CSS styling for the whole blocks of source code: 
make a grey background, a different margin/border or 
whatever.

2. To make the highlighting (colours and fonts) 
customisable through the Common.css file.
Comment 10 Phil Boswell 2007-04-04 10:38:38 UTC
(In reply to comment #9)
> 1. To use <code>, a valid HTML tag, instead of <source>.

This would be a nightmare because <code> is already used in many places. It is, as you 
say, a valid HTML tag, allowed by the software, and has well-defined behaviour. 
Changing that behaviour would have unseen and unseeable consequences and would 
basically annoy a whole lot of people for no good reason.

If you are going to define a new behaviour, use a new tag.
Comment 11 Ramir 2007-04-04 10:52:42 UTC
As far as I know, its "well-defined behaviour" is to 
render the tag as it is, with no changes.

Under my proposition, wherever the <code> tag is used 
now, that behaviour will not change unless you add 
the "lang" attribute (e. g. lang="ruby"). And even then:
1. The <code[ ...]> tag, as before, would be rendered as 
is, except for the removal of the lang="..." attribute.
2. The highlighter parser will add tags to each syntax 
element.
The OVERALL behaviour of the block of <code> will not be 
affected.
Comment 12 Yuri Astrakhan 2007-04-04 15:27:33 UTC
I like the idea of the <code> tag. The extension will need a minor modification
to allow the missing lang attribute to mean "do nothing".

Current implementation (as installed on test) produces 

<pre class="source source-csharp">
<span class="kw4">int</span> i; <span class="co1">// comment</span>
</pre>

   from the wiki markup:

<source lang="csharp">
int i; // comment
</source>

Thus, the extension should output the <code> tag instead of <pre>.  Will we have
to redefine the <code> tag in for all wikies' css to look like <pre>?
Comment 13 Brion Vibber 2007-04-05 13:44:55 UTC
Please do not add unrelated comments about changing the behavior of an existing
extension on this bug.
Comment 14 Tim Starling 2007-05-15 11:38:32 UTC
Now enabled.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links