Last modified: 2007-05-15 11:38:32 UTC
Please enable the Highlight extension. This will be an enormous value to WikiBooks as well as Wikipedia itself. Thanks.
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.
We know what it is.
*** Bug 8146 has been marked as a duplicate of this bug. ***
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.
*** Bug 9322 has been marked as a duplicate of this bug. ***
Upstream issue is reported to be fixed.
> 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.
I made the changes myself, it's now live on test.wikipedia.org.
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.
(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.
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.
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>?
Please do not add unrelated comments about changing the behavior of an existing extension on this bug.
Now enabled.
