MediaWiki talk:Geshi.css

From Wikipedia, the free encyclopedia

The documentation for the Extension is here. There is, as yet, no list of CSS classes: maybe someone could help with that? TIA HAND —Phil | Talk 15:19, 20 May 2007 (UTC)

Contents

[edit] Turning off GeSHi coloring

If you don't want GeSHi coloring at all, you can make all source code render in black-on-white by adding these two lines to Special:Mypage/monobook.css:

pre.source, pre.source * {color: black !important}
Questions. Why not also font-weight:normal; font-style:normal? Is this going to work in all browsers (it's !important vs. more specific selectors)? Is it going to work after !important is already used in Geshi.css? Alex Smotrov 19:13, 3 June 2007 (UTC)

[edit] Experimenting?

Is there any way for non-admins to experiment with different GeSHi settings? I gather that I can associate my own colors with the GeSHi-default token categories, but is there a way for me to define my own token categories? For example, take a look at GeSHi's default C tokenizer, in "geshi/geshi/c.php" in the GeSHi Sourceforge download. It's so far from correct, it's beyond laughable. I'd like to fix it, but I don't know how to get a new "c.php" into Wikipedia's innards, and even if I did, I'd like to be able to test it in a sandbox first. (I don't have access to any other Web host with PHP support; otherwise, I'd do my playtesting there.) Thanks, --Quuxplusone 20:15, 20 May 2007 (UTC)

Well, I thought I could change colors via Special:Mypage/GeSHi.css, but that doesn't seem to work. Any ideas on either topic: parsing or coloring? --Quuxplusone 20:37, 20 May 2007 (UTC)

You can experiment through your Special:Mypage/monobook.css. Note, however, thay you must use !important or pre. for your changes to take effect. AmiDaniel (talk) 02:13, 21 May 2007 (UTC)

[edit] Consistent syntax coloring guidelines

In the interests of correctness, consistency, and readability, here are some guidelines for administrators updating GeSHi's parser and coloring descriptions. I'm more than willing to help out, if there's anything I can do without already being an admin. --Quuxplusone 00:17, 21 May 2007 (UTC)

  • Comments should be green. [1] [2] [3]
  • Keywords should be blue. [4] [5] [6] [7] [8]
  • In Pascal-style languages (including Algol and Python), keywords should be bold (as well as blue). [9] [10] Nothing should be bolded in C-style languages.
  • Literal constants should be red or magenta. [11] [12]
  • In some languages, it may be appropriate to distinguish between string literals and numeric literals. In other languages, such as C and C++, it is not appropriate. Regardless, no color distinction should ever be made between integer numeric literals and floating-point numeric literals.
  • No text should ever be italicized; italics are hard to read.
  • No text should ever be colored lighter than #808080. High contrast is important for readability.
  • No text should ever be underlined; on the Web, underlining means a hyperlink, and any other use is irresponsible and annoying.
  • No text that is not a comment should be colored green (the color of comments). This includes preprocessor directives in C and Pascal. If syntax coloring is being applied, the reader should be able to tell at a glance whether a line of code is executable or not.
  • The "default" color for any text is black (#000000). If GeSHi's parser cannot cope with the syntax of a particular language, such as Perl, then every token in that language should be rendered in plain black text, rather than risk an incorrect coloring.
  • In general, the only colors that should be used in code samples are black, blue (keywords), green (comments), dark red (literals), magenta magenta (an optional second class of literals), and optionally cyan or gray (standard library functions, preprocessor directives, regexes, set literals, or whatever else a particular language wants a new color for). Colors beyond these few should not be used, or code samples will end up with too many competing and clashing colors, and both readability and consistency will suffer.
Alright, sounds good to me -- more or less what I had in mind. Unfortunately these changes have to be made for _every_ language, so it may take some time, but I will get right on it. Thank you for your input. AmiDaniel (talk) 00:21, 21 May 2007 (UTC)
Just to check, have you read the GeSHi documentation to confirm the options which are actually available? I'm not completely convinced that this particular extension is flexible enough to cope with all the demands you want to put to it: bear in mind that it is designed to be able to cope with as many languages as possible which dictates certain limitations. Also, some of your restrictions above seem to go rather too far: "no text should ever be italicized", for example, is entirely your opinion, and other opinions are equally valid. HTH HAND —Phil | Talk 13:03, 21 May 2007 (UTC)
Yes, I've read quite a bit of the docs (although I won't claim all of them :) and GeSHi should be up to the challenge, except possibly the embedding of wikilinks. That's certainly possible too, but I think it would require a pre-pass over the source code to extract the links, and then a second pass to do the coloring, and then a third pass to put the links back in. Something like that.
Re "'no text should ever be italicized', for example, is entirely your opinion, and other opinions are equally valid": no, they're not. Other opinions may exist, but they are not equally valid. :) My specific color choices were pretty arbitrary, though; I had to sift a lot of search results to find those example links supporting my prejudices. ;) --Quuxplusone 03:43, 22 May 2007 (UTC)

[edit] Talk:Consistent syntax coloring guidelines

Regarding points:

  • Re: In Pascal-style languages (including Algol and Python), keywords should be bold
  • Re: No text should ever be italicized; italics are hard to read.
  • Re: No text should ever be underlined; on the Web, underlining means a hyperlink

The following points apply all ALGOLs and SIMULA Key-point: The ALGOL Bulletin was distributed for 30 years, and they underlined keywords throughout these 3 decades. Check out this complete repository:

The text "underlining means a hyperlink and any other use is irresponsible and annoying." needs retoning.

Moreover the original ALGOL language specification specifies underlines:

Having said the above, when these reports were published in industry journals, the first thing the publishers did was bold the keywords (with helvetica font). But ironically variables were italised. Example:

Visability is important (esp in ALGOL where bolding dictates syntax), compare the following:

Style Using standard browser font using the <code> tag
Bolded main:begin integer x; ³ main:begin integer x;¹
Italics x:=arc sin(pi/2);² x:=arc sin(pi/2);²
Big stdio.printf("Hello World"); main² stdio.printf("Hello World"); main¹
Big Bold sys.exit(0)³ sys.exit(0);³
Underline end main³ end main³

Key: - my observation.

  • Barely noticeable (¹) - Should be avoided.
  • Visible noticeable (²) - Useful only where difference is of cosmetic importance, eg variables.
  • Clear noticeable (³) - Needed when bolding/underlining affects syntax.

Maybe someone else (using ie6&Vista) can add their observations. (I'm using std Firefox on std SuSE). But when using the <code> tag, only "Big Bold" and "Underline" are useful.

If we cannot use underlining for code, AFAICS the only choice left is exit for keywords.

Maybe ALGOL is odd (together with other pre-ansi_x3.4-1968 languages like APL and SIMULA). Indeed (aside from bolding/underlines being part of ALGOLs syntax) ALGOL is full of non-ASCII characters: ¢, £, ×, ÷, ↑, →, ↓, ∧, ∨, ¬, ≠, ⊥, ⌈, ⌊, ╭, ╰, ≡, ⊃, ∇, ◊, °, ₁₀, ✠, ○ and ⎕!

¢ APL even has/had it's own programming keyboard. [13] ¢

NevilleDNZ 14:21, 22 June 2007 (UTC)

Odd, bold is clearly visible for me (Firefox, Ubuntu). Guess we have different fonts. But almost anything should be better than the current random colours. Jeltz talk 20:50, 8 July 2007 (UTC)

[edit] Samples

These are some samples of various languages, so that we can observe how they are rendered. Please add to this list.

vb
Private Sub Form_Load()
   Dim i%, s$
   Dim bob As Integer
 
   'This is a comment.
 
   bob = 9
   For i = bob To -1 Step -1
       If (i < 0) Then
           Exit For
       ElseIf (i < bob) = True Then
           Debug.Print "Hello, world!"
       Else
           MsgBox "Hello, world!"
       End If
   Next i
End Sub
java
/**
 * This is a javadoc comment.
 *
 * @author Bob
 */
public class HelloWorld {
   public static final String text = "Hello, world!";
 
   /**
    * This is another javadoc comment. This method makes a new HelloWorld and says hello.
    *
    * @param args Arguments.
    */
   public static void main(String[] args) {
       HelloWorld h = new HelloWorld();
       h.sayHello();
   }
 
   public HelloWorld() {
       // This is a ctor with an inline comment.
   }
 
   public boolean sayHello() {
       System.out.println(text);   
       return true;
   }
}
C#
// Hello World in Microsoft C# ("C-Sharp").
 
using System;
 
class HelloWorld
{
#region The main function.
    public static int Main(String[] args)
    {
        Console.WriteLine("Hello, World!");
        return 0;
    }
#endregion
}
php
<?php
  // Hello World in PHP
  echo 'Hello World!';
?>

-- AmiDaniel (talk) 02:21, 21 May 2007 (UTC)

C
#include <stdio.h>
 /* Hello, World! in C */
 
 void function()
 {
     puts("Hello, world!");
 }
 
 int main(void)
 {
     function();
     return 0;
 }

Wow, that looks ugly at the moment. I wonder why 'int' is a different colour from 'return'? --ais523 11:03, 23 May 2007 (UTC)

The "c.php" coloring description file is totally broken; it doesn't recognize a lot of keywords, and thinks some things are keywords that aren't (such as "function"). I don't know who has permissions to change that file, though. That's why I recommend not using <source> in articles yet. --Quuxplusone 05:03, 24 May 2007 (UTC)
Update: I see the "c.php" description file is still broken. I'll nudge AmiDaniel and try to find out what's going on. --Quuxplusone 08:34, 4 June 2007 (UTC)
Python
def main():
    """Lots of useless code here."""
    if True:
        print "Hello, world!"
        return None # Explicitly returning None!
    else:
        raise Exception
 
if __name__ == "__main__":
    main()

There seems to be no highlighting of reserved words in Python. (kw1 is not highlighted for some reason) Jeltz talk 23:44, 3 June 2007 (UTC)

Ah, I see now that the style sheet is far from finished. Jeltz talk 23:56, 3 June 2007 (UTC)

[edit] GeSHi whitespace bug

Ooh, this is annoying. Compare the nowiki version to the source-tagged version below:

<source lang="pascal">
   procedure ImIndented;
   begin
   end;   
</source>

procedure ImIndented;
   begin
   end;

It looks like the <source> tag is stripping off all the whitespace at the beginning of the first line of any code. It's also stripping all the whitespace at the end of the final line of any code, although you can't see that unless you start getting nosy and highlight the text above.

This bug isn't likely to confuse many readers of Wikipedia, but it's still totally unprofessional, and probably trivial to fix on the PHP side. Also, it's preventing us from using the <source> tag more widely. Anyone interested in fixing it? --Quuxplusone 07:59, 22 May 2007 (UTC)

Well, give us a link to this bug on bugzilla, and we'll vote for it Alex Smotrov 19:13, 3 June 2007 (UTC)
Phil Boswell beat me to the punch by more than a month. :) Give me a link to bugzilla, and I'll report it. But "request Bugzilla link, go to Bugzilla, vote for bug, wait two months, check Bugzilla, wait two months, check Bugzilla,..." sounds like way more bother than "fix bug". I'll give you a link to the fixed PHP code when I have it, and you can vote all you like at that point. HTH, HAND. --Quuxplusone 09:26, 4 June 2007 (UTC)

[edit] Suggestions

Please fix font-style: bold, this is simply incorrect. Then please combine selectors together to compact the code, e.g.

pre.source-c .kw1, pre.source-c .kw2, pre.source-c .kw3 { color: #009 !important; }

Alex Smotrov 19:13, 3 June 2007 (UTC)

[edit] Who's in charge here?

How did this GeSHi package get installed on the English Wikipedia — magical gnomes in the night? It's full of bugs that would be easy to fix if we could find the person who installed it, get access to the PHP files that do the highlighting, and just fix them. I'm volunteering to do the work. I can even make a fixed copy of the entire GeSHi distribution, zip it back up and stick it on a Web site — but we'd still need somebody to install it on Wikipedia. Would the person who originally installed the buggy version please stand up, so I know who to ping when a non-buggy version is ready? --Quuxplusone 09:03, 4 June 2007 (UTC), annoyed

Oh, and the non-buggy "c.php" is here. --Quuxplusone 09:10, 4 June 2007 (UTC)
bugzilla:7163; Tim Starling reported that it was installed, and so is likely to have been the person to have installed it. --ais523 14:13, 4 June 2007 (UTC)

[edit] Syntax Highlighting on Wikipedia/Mediawiki

I am working on some of the more historic languages, specifically the ALGOLs, and I would be happy to create a filter/plugin for these.

Where can I sand box these new filters for missing languages? I suspect I need to get involved in the actual mediawiki project??

Thanᚷ NevilleDNZ 23:30, 20 June 2007 (UTC)

NevilleDNZ 23:43, 20 June 2007 (UTC)

[edit] "font-style" causing warnings

{{sudo}}

The font-style: bold and font-style: normal declarations don't appear to be valid, and are causing warnings; Firefox's error console reports "Error in parsing value for property 'font-style': Declaration dropped."

The correct property for setting the font weight is font-weight, which does not cause warnings. Replace font-style: bold with font-weight: bold and font-style: normal with font-weight: normal wherever they appear. Thanks – Gurch 11:52, 21 June 2007 (UTC)

Mmm… #Suggestions section above? Well, I forgot the {{editprotected}} though… ∴ Alex Smotrov 16:13, 21 June 2007 (UTC)
Hi Gurch. Thing is, there are two lines in there which contain font-style: and they both also have font-weight: so it may be a belt-and-braces way of ensuring cross-compatibility. Thoughts? - Alison ☺ 18:37, 21 June 2007 (UTC) (welcome back, BTW)
Let me clarify:
  • font-style: normal   (2 times) is ok, clearly intention was to disable any italic text
  • font-style: bold   (5 times) is simply incorrect, and should be replaced by font-weight:bold
∴ Alex Smotrov 19:00, 21 June 2007 (UTC)
I changed five instanced of font-style: bold to font-weight: bold. — Carl (CBM · talk) 01:04, 22 June 2007 (UTC)

[edit] problems with underline in <code> tag_block </code>

void new_line(){printf("\n"); }
/* comment */  (Actual example with "_" in place!!) 

Actual Code: <code> 
 void new_line(){printf("\n"); }
 /* comment */</code>

Currently <code>output (note missing an underscore) manually created as it appears in mediawiki preview:

void new line(){printf("\n"); } 
/* comment */

eg.

Where do I go next to fix this? NevilleDNZ 06:06, 22 June 2007 (UTC)

Use text-decoration: underline rather than <u>:
<code> void <span style="text-decoration: underline">new_line</span>(){printf("\n"); } </code>
which produces
void new_line(){printf("\n"); }
This also solves your issue with underscores – Gurch 12:08, 24 June 2007 (UTC)

the tag <span style="text-decoration: underline"> has the same problem:

  • Example with underlines:
1) Actual source:
  void <span style="text-decoration: underline">new line 1</span>(){printf("\n"); } 
2) Resulting output:
  void new line 2(){printf("\n"); } 
/* comment */
3) Manually recreated (defective) output:
  void new line 3(){printf("\n"); } 
/* comment */
4) Desired output:
  void new line 4(){printf("\n"); }

In reality, this is Off Topic, as it is not a bug in <source>, but a bug in <code>. I will transfer this bug report to <code>... (When I find code's Project page). NevilleDNZ 00:05, 25 June 2007 (UTC)

This edit shows how to fix the problem in a way that's not Right, but at least it's closer to Right than screwing around with "text-decoration:underline". If any magical gnomes are listening, could they please make <code> display underscores correctly by default? --Quuxplusone 02:34, 15 September 2007 (UTC)

[edit] Pale color scheme for Scheme code examples

{{editprotected}}

User:Ais523 suggested I ask here after I had asked on the help desk.

Currently, keywords in Scheme code examples are displayed with a very pale yellow/green color that I find very hard to read on the white background that is given by the monobook skin I use (see for example here or here). Could some administrator please create an entry for in the stylesheet to fix this? Something simple like

.source-Scheme .kw1 { color: #009; }
.source-Scheme .co1 { color: #069; }

should be enough. Thanks. — Tobias Bergemann 11:33, 10 September 2007 (UTC)

I've added the keyword fix. The comment change doesn't seem consistent with the other languages; there's an all-language colour code of #080 given as for comments in the source file, which this would be different to. However, the all-language fix doesn't seem to work at present, because 'source' is missing as a class in the list of classes in <source>-tagged code. (I may have to contact devs about that to get the comments fixed as well, then.) To see the keyword fix, bypass your cache. --ais523 12:08, 10 September 2007 (UTC)
Thanks for the quick response. — Tobias Bergemann 12:46, 10 September 2007 (UTC)

[edit] All-language styling

To take a language where there isn't any language-specific styling defined in the Geshi.css, consider the following GeSHi-styled CSS:

/* This is a comment. */
elem.class {property:value; }

Here's the resulting HTML generated from that:

<div dir="ltr">
<pre class="source-css">
<span class="coMULTI">/* This is a comment. */</span>
elem<span class="re1">.class</span> <span class="br0">{</span>property<span class="re2">:value</span>; <span class="br0">}</span>
</pre></div>

Note that the CSS example shows the comment in grey and italic, rather than green and non-italic (as the associated project page would require). The problem seems to be that the class "source" is missing from the <pre>, although it was present at one time, which is causing comments to show incorrectly in several languages. One possible workaround would be to use [class^=source-] as the selector rather than .source, but I suspect that there are browsers which couldn't cope with this. I'll report this to devs (it seems to be a regression); this message is simply to let people know what's going on in the meantime. --ais523 12:26, 10 September 2007 (UTC)

I've submitted bugzilla:11274 about this. --ais523 12:32, 10 September 2007 (UTC)