Rosetta Code:Village Pump/Syntax highlighting

Discuss issues related to the Syntax Highlighting system here. The old page got huge, and it became hard to discern what problems were current.

Recent changes

2010/05/23 - GeSHi update to GeSHi 1.0.8.8

I just updated GeSHi on the server to the latest released version 1.0.8.8. There are some new languages in this release and quite a bunch of changes to other language files. Please check everything and report here as usual. --BenBE 17:12, 23 May 2010 (UTC)

2010/04/25

Uploaded a language file update for Bash, GDB, Icon/Unicon, MagikSF, Matlab, Oz, Powershell, Q and VIM. The language files for E and Algol68 have not been uploaded/updated yet - due to some issues that need to be fixed beforehand. --BenBE 21:39, 25 April 2010 (UTC)

2010/03/01

Uploaded a language file update for J by Ric that changes some behaviour with the way keywords are handled and fixes a bug with some comments being ignored, although they should get highlighted. --BenBE 23:31, 1 March 2010 (UTC)

2010/02/17 - GeSHi update to GeSHi 1.0.8.7

I just uploaded the latest GeSHi release 1.0.8.7 to the server. In addition this includes some new language files for 1.0.8.8 that aren't publically available as part of a release. As Usual: Contact me about issues with the highlighting. --BenBE 20:42, 17 February 2010 (UTC)

Which languages are added for this version? Do you have a l list or a link to release notes? --Mwn3d 22:01, 17 February 2010 (UTC)

I don't know which were added, but there's always this. --Michael Mol 23:59, 17 February 2010 (UTC)

You can find a list of changes between releases in the CHANGELOG. That also lists added languages. --BenBE 23:38, 20 February 2010 (UTC)

2010/01/06

• Updated language files: c, c_mac, cpp, cpp-qt, clojure, erlang, lisp, java5, prolog
• Parser Changes: Generally allowed .. before plain integers. Affects at least: delphi, modula3, pascal, perl and maybe some more.
  • Just fixed the changed regexp as I forgot to escape two chars which made the number highlighting behave somewhat unexpectedly --BenBE 17:25, 7 January 2010 (UTC)

2009/12/25 - GeSHi update to GeSHi 1.0.8.6

Hi folks,

I'm helping out Short Circuit with the Server and the GeSHi installation that drives the syntax highlighting of this Wiki. I therefore updated the installation of GeSHi on the RC server to the latest official release - version 1.0.8.6.

I hope nothing horribly went wrong during the update. If you notice any problems please notify me here on the Wiki Page or upstream by mail.

I'll try to work through the (highlighting-related) issues ASAP, though this might take some time.

--BenBE 01:11, 26 December 2009 (UTC)

It doesn't seem to have taken (yet?). Look at the listing in the #Language tags section below. It still says 1.0.8.3.--Mwn3d 01:37, 26 December 2009 (UTC)

Caching, most likely. I just touched the MediaWiki configuration file, so it should expire all the caches. Caches may last up to 24 hours. --Michael Mol 07:38, 26 December 2009 (UTC)

Relationship Between Rosetta Code and GeSHi

Rosetta Code first started using GeSHi for syntax highlighting a long while back, but due to our nature, we quickly discovered, and frequently continue to discover, programming languages which GeSHi does not provide highlighting functionality. Additionally, we've uncovered bugs in various releases of the software, and the GeSHi folks have been welcoming of fixes sent to them.

Due to the way language support is managed in GeSHi, it's fairly trivial for someone who can follow PHP syntax to create a PHP file that adds support for the language of their choice. GeSHi's support for Oberon-2, Modula-3 and AutoHotKey is the direct result of contributions by MBishop and Tinku99. (If you like a language, and it doesn't appear to have syntax highlighting support, I strongly suggest you follow their lead. ;-) )

I am now also part of the GeSHi project focusing for now on adding and improving support for programming languages present on Rosetta Code. As a community of language aficionados and enthusiasts, Rosetta Code is a hotbed for opportunities for improving GeSHi, and improvement of GeSHi is extremely helpful for improving the readability code on Rosetta Code. --Short Circuit 06:43, 18 June 2009 (UTC)

So how can I add a language? I have made a GeSHi file for Vedit macro language. Where can I upload it? (I can not test it myself so I don't know if it is OK). I could do a file for RapidQ quite easily, too, since I have Vedit syntax file for it.

It would be nice if there was an example GeSHi file downloadable somewhere (or perhaps even a few of them). The only one I found was at GeSHi web page. I had to cut and paste the source from the browser, and the do quite a lot editing to get newlines etc. fixed. --PauliKL 15:26, 30 June 2009 (UTC)

Email them to me at mikemol@gmail.com, and I'll get them tested, staged on RC and committed to SVN as quickly as I can. --Short Circuit 17:06, 30 June 2009 (UTC)

Or upstream to BenBE at geshi (ddoott) org --BenBE 01:15, 26 December 2009 (UTC)

If anyone else would like to make a language file, look at this explanation of the language file format from the GeSHi site: http://qbnz.com/highlighter/geshi-doc.html#language-files. --Mwn3d 19:56, 8 September 2009 (UTC)

Language tags

Due to changes I want to implement in the way processing of the lang tag is done, we need to standardize codes for all of the languages currently on Rosetta Code ASAP. Subsequently, all pages need to be scoured for code snippets.

Here is a list of the languages that currently exist on Rosetta code as I write this. Next to each language, place the code for that language. If the code is already established in GeSHi, make it bold. If no code is provided by GeSHi, and no code is currently in use for that language on the wiki, make one up. Once this list is fully populated, all the pages for each language need to be checked, and ensure that the code snippets for that language are correct. (Not sure what to do about command-line one-liners or similar yet, though.)

Note: AutoHotKey currently has two codes, ahk and autohotkey. When AutoHotKey support was added to GeSHi, it was added with the longer code. (lang codes are derived from the filename.) Since there were already code snippets on RC that used ahk for AutoHotKey, I created a symlink that allowed ahk to be used as a language code as well. This should likely be reversed, meaning instances of the ahk tag need to be replaced with the autohotkey tag. --Short Circuit 07:01, 18 June 2009 (UTC)

Recommended language tag usage

• 4D 4d
• 4DOS Batch 4dos

A

• ALGOL 60 algol60
• ALGOL 68 algol68
• APL apl
• AWK awk
• ActionScript actionscript
• Ada ada
• Agda2 agda2
• AmigaE amigae
• AppleScript applescript
• Assembly asm (for x86)
• AutoHotkey autohotkey

B

• BASIC qbasic freebasic thinbasic
• Batch File dos
• Bc bc
• Befunge befunge
• Brainf*** bf

C

• C c
• C# csharp
• C++ cpp
• Caml caml
• Clean clean
• Clojure lisp
• Cobol cobol
• ColdFusion cfm
• Common Lisp lisp
• Component Pascal pascal
• Coq coq

D

• D d
• Dao dao
• Dc dc
• Delphi delphi

E

• E e
• EC ec
• ELLA ella
• ESQL sql
• Eiffel eiffel
• Emacs Lisp lisp
• Erlang erlang

F

• F f
• F# fsharp
• FALSE false
• FP fp
• Factor factor
• Fan fan
• Forth forth
• Fortran fortran

G

• GAP gap
• Gnuplot gnuplot
• Go go
• Groovy groovy

H

• HaXe haxe
• Haskell haskell

I

• IDL idl
• Icon icon
• Io io

J

• J j
• JSON json
• JScript.NET jscript
• Java java java5
• JavaScript javascript
• JoCaml jocaml
• Joy joy
• JudoScript judoscript

K

• Korn Shell korn

L

• LSE64 lse64
• LaTeX latex
• LabVIEW labview
• Lisaac lisaac
• Lisp lisp
• Logo logo
• Logtalk logtalk
• LotusScript lotusscript
• Lua lua
• Lucid lucid

M

• M4 m4
• MAXScript maxscript
• MIRC Scripting Language mirc
• MS SQL sql
• Make make
• Maple maple
• Mathematica mathematica
• MATLAB matlab
• Maxima maxima
• Metafont metafont
• Modula-3 modula3

N

• NewLISP lisp
• Nial nial

O

• OCaml ocaml
• Oberon-2 oberon2
• Object Pascal pascal
• Objective-C objc
• Octave octave
• Omega omega
• OpenEdge/Progress openedge
• Oz oz

P

• PHP php
• PL/I pli
• PL/SQL plsql
• Pascal pascal
• Perl perl
• Perl 6 perl6
• Pike pike
• PlainTeX tex
• Pop11 pop11
• PostScript postscript
• PowerShell powershell
• Prolog prolog
• Python python

Q

• Q q

R

• R r
• REXX rexx
• RapidQ rapidq
• Raven raven
• Rhope rhope
• Ruby ruby

S

• SAS sas
• SETL setl
• SMEQL smeql
• SNUSP snusp
• SQL sql
• Scala scala
• Scheme scheme
• Script3D script3d
• Seed7 seed7
• Self self
• Slate slate
• Smalltalk smalltalk
• Standard ML sml

T

• TI-83 BASIC ti83b
• TI-89 BASIC ti89b
• Tcl tcl
• Toka toka
• Tr tr
• Transact-SQL sql
• Twelf twelf

U

• Unicon unicon
• UNIX Shell bash
• UnixPipes bash
• Unlambda unlambda

V

• V v
• VBScript vbscript
• Vedit macro language vedit
• Visual Basic vb
• Visual Basic .NET vbnet
• Visual Objects visobj

W

• Wrapl wrapl

X

• XQuery xquery
• XSLT xml
• XTalk xtalk

GeSHi extension self-report

Here is a list of the codes currently provided by GeSHi.

<lang list></lang>

Non-GeSHi-issues to take care of

Whitespace at program beginning/end

I just wanted to make sure that this problem doesn't get forgotten now that the thread moved to the archive page. --Ce 23:18, 6 July 2009 (UTC)

I think you're going to have to reiterate exactly what the problem is, and how it manifests itself under the current configuration. --Short Circuit 23:50, 6 July 2009 (UTC)

In

<lang cpp>
int main {}
</lang>

there are additional blank lines,

<lang cpp> int main {} </lang>

which don't appear in

<pre>
int main()
</pre>

which results in

int main()

Those lines shouldn't be there. Currently the only way to get rid of them is to put the beginning/end tag on the same line as the first/last line of the code, which makes editing (and especially modifying existing snippets) unnecessarily hard (especially it's easy to miss an end tag, since it's bolted onto the last line of the code). In addition, it's an inconsistency. The lang tags should work exactly like pre tags, except for syntax hilighting.

The old discussion is in Village Pump:Home/Syntax Highlighting ( archived 2009-06-18 )#Another problem with eating whitespace characters (note that the start of that discussion concerns an older state with a different problem; initially too much was removed). --Ce 10:42, 7 July 2009 (UTC)

Is there still hope that this will get fixed some day? --Ce 20:41, 7 October 2009 (UTC)

I don't know. The syntax highlighter was my top priority just before I got slammed with work months ago, and things are just settling down. An update of the highlighter is definitely in order, but it's going to result in a significant number of breakages of things that currently work. And I'm hoping for a change in some MW internals that may make the GeSHi work simpler.

In all honesty, I'm hopeful, but not expectant, of a solution that's going to work for the rest of the code examples, while at the same time working for the Whitespace language. --Michael Mol 00:45, 8 October 2009 (UTC)

Test...

<lang cpp>int main {}</lang>

Fix is simpler than it appeared. Don't put newlines between the tags. :) --Michael Mol 01:15, 8 October 2009 (UTC)

But that makes the page source worse. Especially it makes it easy to miss an end tag. (Yes, it already happened.) I strongly hope that one day, it will work correctly. --Ce 16:16, 10 October 2009 (UTC)

Yes, it does, but in the case of Whitespace, I think it's justified. Otherwise, you're putting language-significant information between the tags, and effectually asking the wiki to strip out some of your program. I don't see how that's better behavior. If copy/paste is necessary, ideally they would copy from the rendered wiki page, not the wiki source. --Michael Mol 22:14, 10 October 2009 (UTC)

IMHO, the code begins in the line after the start tag and ends at the line before the end tag (putting it in the same line is just a hack to work around the bug). Therefore IMHO currently Whitespace is broken because the GeSHi adds extra newlines at the beginning/end. Also note that this is also how the HTML pre tag works, example:

As you see, a line break directly after the pre tag is removed.

One thing I previously got wrong it that this deletion is only if there's only a newline, any extra whitespace after the pre or before the /pre causes the newline not to be removed. But then, this should simplify the algorithm considerably: Instead of general trimming, one has only to check whether the first resp. last character of the text inside tags is a newline, and if so, remove it. --Ce 08:39, 11 October 2009 (UTC)

Looking at the HTML source of the page, I now noticed several things:

* GeSHi already uses pre tags internally, but:

* it adds an additional &nbsp; to the first and last (empty) line. This space is not in the source, and I'd therefore consider it a bug in its own right.

* it replaces all newline characters by <br /> which is not only a waste of bandwidth (because pre already honors newline characters), but also defeats the pre tag handling of newlines at the beginning/end.

So the fix would probably to just remove the two latter points.

BTW, whitespace highlighting currently seems broken anyway, because it doesn't currently highlight newlines:

<lang whitespace>

  <-_just_three_spaces
  <-_a_newline,_followed_by_three_more_spaces

</lang>

(my comments apply to what I think should be highlighted; from your interpretation, you'd expect two additional newlines at the beginning/end to be highlighted) Note that the extra spaces in the extra lines (although not highlighted) will break the whitespace code when doing copy/paste, even if using your interpretation. --Ce 09:03, 11 October 2009 (UTC)

It seems like it would be nice to have the lang tag work like the pre tag, but it may not be worth the work. An easy way to catch a lot (still not all) forgotten /lang tags would be to require a preview for all edits (I think it's a MW option). Everyone should preview anyway. And you're right the newline highlighting isn't showing up. It's even easier to see if you add a blank line between the text you showed: <lang whitespace>

  <-_just_three_spaces

  <-_a_newline,_followed_by_three_more_spaces

</lang> I think they used to be red? Maybe that was tabs. --Mwn3d 17:59, 11 October 2009 (UTC)

Given the information I gathered lately (see my latest comment above), I don't think it would be much work. It would be just

• Find the code which changes newline characters to br tags and remove it (my guess is that it's also the reason why whitespace highlighting is broken; probably the GeSHi highlighting code looks for newline characters and doesn't find them because they are replaced by br tags).
• Find the code which adds the extra &nbsp; at the beginning/end and remove it.

I cannot imagine that taking a lot of time. --Ce 20:21, 11 October 2009 (UTC)

Here's the hacked-up MediaWiki extension RC is currrently using. It differs fairly significantly from the original version due to fixes and issues that were brought up since its initial use here. RC is currently using GeSHi 1.0.8.2. The latest in the 1.0.x branch is 1.0.8.4, but we encountered significant breakage when I upgraded to that months ago, I had to roll it back. I joined the GeSHi project with commit access, with the intention of adding languages, and finding and fixing issues, as well as running SVN HEAD on RC, but between ImplSearchBot issues and the StumbleUpon flood, my server (and remote backup target) at home suffering a [catastrophic hardware failure, my other computer's screen flaking out, as well as time cramps relating to family, work emergencies running fairly continually since June, and personal health issues coming to a head in the past month, I really haven't had time.

The 1.0.x GeSHi branch is no longer under active development, and I don't know how painful the transition to the 1.1.x branch is going to be. 1.1.x was supposed to be released in August when I last had the time to talk to the other members of that project, and I don't know why it's still in alpha.

Opticron has made significant headway on the ISB replacement, but has slammed into a problem that may require filing a ticket with the MW folks. I just finished getting my home server running again. Once I've got my home server pulling daily site backups again, I should finally be able to turn my attention toward the syntax highlighting again.

As an aside, I don't think anything changed in the server software between when newlines were highlighted and when they weren't. It may also be a bug brought on by a shift in browser usage. --Michael Mol 01:31, 12 October 2009 (UTC)

I think that it's not a browser problem. Inspecting the generated HTML shows there's no span created around the line breaks.

BTW, the changing of newlines to br tags is in the second-to-last line in the linked file, http://rosettacode.org/resources/gct_rcode.phps (i.e. in the return). Just replacing str_replace("\n",'<br />', $geshi->parse_code()) with $geshi->parse_code() should fix that part. However, that line also shows that my suspicion that this is responsible for the missing newline highlighting is wrong: It is only applied after highlighting.

I also see that you've added my previously suggested function prestyletrim; now it's also clear to me why it didn't work: You applied it after the parsing instead of before. But since I now recognized that the semantics would be wrong anyways, it should probably be removed. However, instead it may be modified to simply patch away the spurious &nbsp; after the fact (the cleaner way would be not to generate it, but that seems to be in $geshi->parse_code(), which is not in the file you linked to).

I think changing prestyletrim to

<lang php> function prestyletrim($text) {

 return preg_replace("/^ /","",preg_replace("/ $/","",$text));

} </lang>

should work (I'm not completely sure because I'm no PHP programmer). This modified version should be called exactly where the original is called now (i.e. while it was the wrong place for the original version, it would be the right place for the new one).

Maybe if it works, the function should also be renamed.

BTW,. I now note that the extra empty line at the end does not appear on the PHP example, so adding the spurious &nbsp; seems to be part of the programming language dependent code. --Ce 08:02, 12 October 2009 (UTC)

The extra line didn't appear because the parser was in the middle of a literal string at the end of the example. I changed the text to what I think you might have meant to put and the blank line shows up. --Mwn3d 12:11, 12 October 2009 (UTC)

Ah, thanks. However, you mis-fixed it (having the function call twice was intentional; probably it could have been done with one function call and a better regexp, but I chose the easy way, which didn't require me to dig up PHP regex info from the net again). I now replaced with the correctly corrected version (and at the same time also fixed another, unrelated bug in the function). --Ce 16:28, 12 October 2009 (UTC)

OCaml for Standard ML?

It has been suggested to use the OCaml syntax highlighting for Standard ML, and some SML code has been changed to OCaml highlighting already. While the languages are similar, they have many differences in keywords and stuff, and I feel that Standard ML should have a separate highlighting scheme. For example, SML has "datatype" keyword and OCaml does not; logical operators are "andalso" and "orelse" instead of "&&" and "||"; pattern matching is "case ... of" instead of "match ... with"; the "fn" keyword; and lots of other stuff. If I have time I could try to translate the OCaml GeSHi language file into SML; but I am reluctant to do so as I do not own a copy of the Definition of Standard ML, and so I am not confident I will get everything. --76.91.63.71 08:22, 19 July 2009 (UTC)

Sounds reasonable. Grepping around, I find that the list of keywords is this:

and abstype as case datatype else end eqtype exception do fn fun functor funsig handle if in include infix infixr lazy let local nonfix of op open overload raise rec sharing sig signature struct structure then type val where while with withtype orelse andalso

This list was extracted directly from the lexer's keyword table in the source to the SML/NJ implementation, so it should be complete and accurate. I've not categorized their meaning at all. —Donal Fellows 13:46, 19 July 2009 (UTC)

If the languages really are that similar, copy the language file, adjust it for any differences, and send it to me. I'll see that it gets added in as a proper language (and winds up in GeSHi upstream, as well.) --Short Circuit 14:47, 20 July 2009 (UTC)

Non-ASCII characters and unrecognized languages

Look at the below, then look at the source markup of this section.

A smiley face: ☺

<lang haskell>(☺) :: Mood</lang>

Have a ☺ nice day!

<lang ratatouille>Have a ☺ nice day!</lang>

The first three smiley faces come through fine, but the last is somehow corrupted. It appears that in general, if GeSHi doesn't recognize a language name, any non-ASCII characters between the lang tags get screwed up. I noticed this bug when using non-ASCII operators in Perl 6 examples. —Underscore 00:19, 7 November 2009 (UTC)

I can probably fix that by changing my "not found" code path when it looks at languages. It's using a PHP character-escaping builtin that's not Unicode-safe, as a brute method of guarding against code injection. --Michael Mol 23:48, 14 November 2009 (UTC)

For the record, this bug is now fixed. —Underscore (Talk) 01:25, 2 December 2009 (UTC)

Solved issues

Prolog

The Prolog highlighter is emitting garbage instead of hyperlinks. <lang prolog>write(X)</lang>

—Underscore (Talk) 13:49, 1 January 2010 (UTC)

This issue has been fixed on the server and upstream. Missed to forbid one character after variables. --BenBE 22:37, 1 January 2010 (UTC)

C syntax highlight

I've noticed that the "string" word is highlighted as a type in C; it shouldn't be so. --ShinTakezou 23:00, 3 July 2009 (UTC)

Removed string from plain C and C for Mac language files; yet added all the Standard Integer types from stdint.h instead. --BenBE

Small task: For the C language file the section containing the standard function names like printf is awfully empty. I'd need some guys to fill it up ;-) Basically the list should contain all the functions usually found in libc that ships twith the C compiler. --BenBE

Java5 Highlighting

The java5 highlighting removes links to classes when generics are specified for them without a space between the class name and the <. Example: <lang java5>LinkedList<T></lang> "LinkedList" should be a link. If you add a space the link shows up: <lang java5>LinkedList <T></lang> I think a lot of people leave the space out so the highlighting should put a link in with or without the space. --Mwn3d 12:35, 29 July 2009 (UTC)

Should be fixed now --BenBE 13:03, 2 January 2010 (UTC)

The java5 (and java) highlighting doesn't highlight javadoc comments as multi-line comments: <lang java5>/**

• this is a comment
• /</lang>

The style for co3 is missing. GeSHi itself already highlights it. --BenBE 13:03, 2 January 2010 (UTC)

Which style does it use for regular comments? I can copy that and change the color slightly to make sure it looks like there's a little bit of difference. --Mwn3d 19:23, 7 January 2010 (UTC)

It also doesn't highlight "import static" lines properly (this should only be in java5: <lang java5>import static SomeClass.someMethod;</lang> "import" and "static" should both be blue and bold and "SomeClass.someMethod" should be gray, bold, and italic. --Mwn3d 13:34, 23 September 2009 (UTC)

Wasn't supported until now. Added support for import static. Should work now --BenBE 13:03, 2 January 2010 (UTC)

It mostly works now. Look at this example:

<lang java5>

Map<String, Integer> </lang>

"String" should also be a link like it is in this example:

<lang java5>

Map < String, Integer > </lang>

--Mwn3d 23:27, 5 January 2010 (UTC)

Done --BenBE 00:20, 6 January 2010 (UTC)

Known bugs with GeSHi Syntax Highlighting

OCaml syntax highlighting issues

Thanks a lot, BenBE, for the corrections! Blue Prawn 23:04, 28 February 2010 (UTC)

Here are bugs in the ocaml syntax highlighting

• there is a difference between integer arithmetic and float arithmetic, for exemple:

<lang ocaml>3 + 4 (* integer addition *) 3.4 +. 1.2 (* float addition *)</lang> the point that indicates the float operation (+. *. /. -.) is caught as the separator between a module name and a function from that module: <lang ocaml>value_a +. value_b</lang> here value_a and value_b should have the same color.

• What do you need in particular? Different colors for int and float? --BenBE 00:29, 18 February 2010 (UTC)

No. The issue is now solved. Blue Prawn 23:04, 28 February 2010 (UTC)

• This problem also occurs with fields of structures:

<lang ocaml>type t = { x:int; y:int } ;; let v = {x=2; y=3} ;; print_int (v.x + v.y) ;;</lang>

• I disabled OOP Language Handling for OCaml for now. I guess there's some issue in how the magic is done inside the parser that needs to be tweaked ... But otherwise having v.x and v.y marked x and y as methods\fields is desired. --BenBE 00:29, 18 February 2010 (UTC)

About OOP method are accessed with the character '#' like this "my_obj#my_method param1 param2", but ocaml programmers don't use OO a lot (Go_Fish/OCaml is the only example on RC). Now if fields are not highlighted I don't feel this as annoying. Blue Prawn 23:04, 28 February 2010 (UTC)

• there is also something that I consider as an issue, when a function or a constructor follows a module name, these two different entities are colored in the same way, example (from there):

<lang ocaml>Unix.sleep (* function *) Unix.O_CREAT (* constructor *) Unix.LargeFile (* a sub-module *) (ref 3).contents (* the field of a structure *)</lang> also I don't find it very uniform to colorise elements that follow a module name, and not when the module is opened: <lang ocaml>open Unix (* equivalent elements, but here with different colors *) sleep O_CREAT open LargeFile { contents = 3 }</lang> so I think GeSHi should not colorise names after a dot. This would by the way fix the bug with float operations.

• Hard to be done right without contextual parsing (which GeSHi 1.0.X currently doesn't). Should be a bit better with the OOLang handling currently being disabled. --BenBE 00:29, 18 February 2010 (UTC)

• when one open a module, we can open also open a module inside another module

<lang ocaml>open Ode open Ode.LowLevel (* LowLevel is a module inside the module Ode *)</lang>

• Need contextual parsing, cf. above. --BenBE 00:29, 18 February 2010 (UTC)

• Modules that are not part of the standard library are not colorised, IMHO this is not very uniform and relevant. In editors with ocaml syntax-highlight, all modules are highlighted. (modules from the standard lib have a link to the doc, please keep this feature)
  • (identifiers (identifiers to values (often called variables) and identifiers to functions) have the first letter lower case or an underscore)
  • a name that starts with an upper-case letter is a module name or a constructor (they are capitalised)

we can make the difference between a module name and a constructor when it's followed by a dot it's a module name (maybe I'm wrong, but I can't find an example of a constructor followed by a dot) <lang ocaml>Unix.sleep (* module *) Some "text" (* a constructor *)</lang> when there is no dot after it but the keyword open before it, it is a module name: <lang ocaml>open Unix</lang> we can also open a submodule: <lang ocaml>open ExtString.String (* both modules ExtString and String should have the same color *)</lang> there can be any depth: <lang ocaml>open M1.M2.M3.M4.M5.M6.M7.M8</lang> we can also recognize a module name if there is the keyword module before it: <lang ocaml>module Attrib</lang> in all other cases it is a constructor.

• Could be done, but produces quite messy language files and mostly isn't worth the drawbacks. --BenBE 00:29, 18 February 2010 (UTC)

• I think constructors should be highlighted too (with another color than modules), (in editors constructors are highlighted).

(see previous paragraph to see when a capitalised word is a module or a constructor)

• hmmm, I'd like to keep contextual highlighting as much out of the language file as possible. The 1.1.X developement branch can do contextual highlighting\parsing, but this won't work together with the stable 1.0.X branch this site is using. --BenBE 00:29, 18 February 2010 (UTC)

• Modules from the standard library are not treated the same, some are highlighted with a link to the doc, and some other are not:

<lang ocaml>Arg Arith_status Array Array1 (* * *) Array2 (* * *) Array3 (* * *) ArrayLabels Big_int Bigarray Buffer Callback CamlinternalLazy (* TODO *) CamlinternalMod (* TODO *) CamlinternalOO Char Complex Condition Dbm Digest Dynlink Event Filename Format Gc Genarray (* * *) Genlex Graphics GraphicsX11 Hashtbl Int32 Int64 LargeFile (* !!! *) Lazy Lexing List ListLabels Make (* !!! *) Map Marshal MoreLabels Mutex Nativeint Num Obj Oo Parsing Pervasives Printexc Printf Queue Random Scanf Scanning (* * *) Scanf Set MoreLabels Sort Stack State (* * *) Random StdLabels Str Stream String StringLabels Sys Thread ThreadUnix Tk Unix (* TODO *) UnixLabels (* TODO *) Weak (* TODO *)</lang> Those tagged with TODO should be added (in particular Unix in priority), the other could be omited, those with a star are modules inside another module for example Array1, Array2, Array3 and Genarray are inside Bigarray, for a root module named Foo the url is http://caml.inria.fr/pub/docs/manual-ocaml/libref/Foo.html for a module Bar inside Foo the url is http://caml.inria.fr/pub/docs/manual-ocaml/libref/Foo.Bar.html the tags !!! are for modules which url can not be resolved because for example for the module name LargeFile, there are LargeFile modules inside several root modules in Pervasives, in Unix, and in UnixLabels.

• I've added some Modules for now. For the star-ed Modules I'd need to have the Parent Module name or the Doc-Link that I should be generating. As each Group requires some overhead I'd suggest linking only those with at least 2 or 3 Submodules in it (e.g. Array) and simply highlighting (without Link) the others. Could you compile me that list? --BenBE 00:29, 18 February 2010 (UTC)

Here are the full links of the star'ed modules:

Array1   => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.Array1.html
Array2   => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.Array2.html
Array3   => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.Array3.html
Genarray => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Bigarray.Genarray.html
Scanning => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Scanf.Scanning.html
State    => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Random.State.html

Blue Prawn 23:04, 28 February 2010 (UTC)

• not a bug nor an issue, but a suggestion: maybe we could highlight the core OCaml types:

<lang ocaml>list array int float (* !!! *) bool char string unit int32 int64 nativeint <fun> in_channel out_channel file_descr exn</lang>

• I have keep in_channel and out_channel in the list because I think we should use the same color.
• float is a type in contexts where ocaml expects a type and a function in contexts where ocaml expects a function. So we could keep it as a function, or convert it to a type. I'm not sure which is best, but in RC context it seems it is most often the function.

• Added them, left float as function. Left <fun> alone as this requires some special treatment. --BenBE 00:29, 18 February 2010 (UTC)

I think that some links could be modified:

file_descr => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Unix.html#TYPEfile_descr int32 => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Int32.html int64 => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Int64.html nativeint => http://caml.inria.fr/pub/docs/manual-ocaml/libref/Nativeint.html

Blue Prawn 23:04, 28 February 2010 (UTC)

• not a bug nor an issue, but a suggestion: maybe we could highlight labels (names with a tild before it):

<lang ocaml>let my_compare ~left ~right =

(* ... *)</lang>

I propose this style (font-weight:bold; color:#339933;): ~left

• Included in the language file, but needs a CSS Addition for class re1 (ocaml only) on RC. --BenBE 00:29, 18 February 2010 (UTC)

• not a bug nor an issue, but a suggestion: maybe we could highlight polymorphic variants (names with a backtick before it):

<lang ocaml>`left (* constructor of a polymorphic variant *)

Left (* constructor of a non-polymorphic variant *)</lang> IMHO these two kinds of constructors should be highlighted with the same color.

I suggest this style (font-weight:bold; color:#993399;): Left `left (if the highlight for names following a dot is removed as suggested above, because this is the same color)

• Included in language file but needs a CSS Addition for class re2 (ocaml only) on RC. --BenBE 00:29, 18 February 2010 (UTC)

• This bug is not related to the OCaml syntax (but affects ocaml syntax), GeSHi doesn't handle nested comments (see Comments)

<lang ocaml>(* This a comment

(* containing nested comment *) *)</lang> just a suggestion, maybe an easy way to handle this would be to match *) ... *)?

• Fixed. Now uses recursive regular expressions for comments with fallback for simple string search. --BenBE 00:29, 18 February 2010 (UTC)

This is very nice, thanks!

On the Comments page we can see other languages that use nested comments, here is the list that I can see:

• Clean
• D with /+ +/
• Haskell
• Mathematica
• Modula-3
• Pop11
• Seed7
• Standard ML
• Ursala

Also some that are not nested, but where I can see some bug:

• "perl6", see: Comments#Perl_6
• There is a bug with phpdoc in PHP: Comments#PHP
• multiline comments are not handled with Rebol: Comments#REBOL

Blue Prawn 23:04, 28 February 2010 (UTC)

• The parser brackets ([< and >]) should be completely highlighted:

<lang ocaml>parser [< e = parse_expr >]</lang> (here the character [ is colored but not <)

• Tweaked in language file but needs CSS class sy0 to be set for this to show. --BenBE 00:29, 18 February 2010 (UTC)

-- Blue Prawn 21:29, 22 January 2010 (UTC)

Regression in Tcl Syntax Highlighting

I was just looking through some examples today (notably Miller-Rabin test#Tcl) and I saw that the Tcl highlighting seems to have regressed to how it was back when I started using this site. In particular, lots of expressions are now being marked like they are some kind of vaguely comment-like thing (I've not pried in depth what it actually thinks of them...) I distinctly remember complaining about this before and something was done about it – don't remember what – but now we've gone backwards. What happened? (No, I've been too busy recently with other things so I don't know when the change occurred.) I complain because it's ugly and harder to read than before. –Donal Fellows 15:09, 2 February 2010 (UTC)

Applied a small fix for now which you can see in the upstream GeSHi SVN repository (trunk). The file has been updated on RC too and should take effect soon. --BenBE 03:29, 3 February 2010 (UTC)

MATLAB problem

MATLAB has HTML leaking into its links. Take a look at Ethiopian_multiplication#MATLAB for an example. --Mwn3d 00:29, 1 April 2010 (UTC)

Should be fixed locally for GeSHi; pending upload to RC server. --BenBE 10:43, 24 April 2010 (UTC)

k, just applied the GeSHi SVN patches on RC. Should take effect soon. --BenBE 21:42, 25 April 2010 (UTC)

ALGOL 68, AutoGeSHi

I ran http://rosettacode.org/geshi/ and it generated a script, who do I send this script to? <lang php><?php /**

* algol68.php
* --------
* Author: Neville Dempsey (NevilleD.sourceforge@sgr-a.net)
* Copyright: (c) 2010 Neville Dempsey (https://sourceforge.net/projects/algol68/files/)
* Release Version: 1.0.8.8.2
* Date Started: 2010/04/24
*
* ALGOL 68 language file for GeSHi.
*
* CHANGES
* -------
* 2010/04/24 (1.0.8.8.0)
*   - First Release - machine generated by http://rosettacode.org/geshi/
* 2010/05/24 (1.0.8.8.1)
*   - #2324 - converted comment detection to RegEx
* 2010/06/15 (1.0.8.8.2)
*   - seperate symbols from keywords - quick fix
*
*
* TODO (updated yyyy/mm/dd)
* -------------------------
*   - Use "Parser Control" to fix KEYWORD parsing, eg: (INT minus one= -1; print(ABSminus one))
*
*
*
*
*      This file is part of GeSHi.
*
*    GeSHi is free software; you can redistribute it and/or modify
*    it under the terms of the GNU General Public License as published by
*    the Free Software Foundation; either version 2 of the License, or
*    (at your option) any later version.
*
*    GeSHi is distributed in the hope that it will be useful,
*    but WITHOUT ANY WARRANTY; without even the implied warranty of
*    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
*    GNU General Public License for more details.
*
*    You should have received a copy of the GNU General Public License
*    along with GeSHi; if not, write to the Free Software
*    Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
*/

$language_data = array(

   'LANG_NAME' => 'ALGOL 68',
   'COMMENT_SINGLE' => array(),
   'COMMENT_MULTI' => array(
       '#' => '#',
       '¢' => '¢',
       '£' => '£',
       ),
   'COMMENT_REGEXP' => array(
       1 => '/\bCO((?:MMENT)?)\b.*?\bCO\\1\b/i',
       2 => '/\bPR((?:AGMAT)?)\b.*?\bPR\\1\b/i',
       3 => '/\bQUOTE\b.*?\bQUOTE\b/i'
       ),
   'CASE_KEYWORDS' => GESHI_CAPS_NO_CHANGE,
   'QUOTEMARKS' => array('"'),
   'ESCAPE_CHAR' => '"',
   'KEYWORDS' => array(
       1 => array('KEEP', 'FINISH', 'USE', 'SYSPROCS', 'IOSTATE', 'USING', 'ENVIRON'),

/* 2 => array('CASE', 'IN', 'OUSE', 'IN', 'OUT', 'ESAC', '(', '|', '|:', ')', 'FOR', 'FROM', 'TO', 'BY', 'WHILE', 'DO', 'OD', 'IF', 'THEN', 'ELIF', 'THEN', 'ELSE', 'FI', 'PAR', 'BEGIN', 'EXIT', 'END', 'GO', 'GOTO', 'FORALL', 'UPTO', 'DOWNTO', 'FOREACH', 'ASSERT'), */

       2 => array('CASE', 'IN', 'OUSE', 'IN', 'OUT', 'ESAC', 'FOR', 'FROM', 'TO', 'BY', 'WHILE', 'DO', 'OD', 'IF', 'THEN', 'ELIF', 'THEN', 'ELSE', 'FI', 'PAR', 'BEGIN', 'EXIT', 'END', 'GO', 'GOTO', 'FORALL', 'UPTO', 'DOWNTO', 'FOREACH', 'ASSERT'),
       3 => array('BITS', 'BOOL', 'BYTES', 'CHAR', 'COMPL', 'INT', 'REAL', 'SEMA', 'STRING', 'VOID', 'COMPLEX', 'VECTOR'),
       4 => array('MODE', 'OP', 'PRIO', 'PROC'),
       5 => array('FLEX', 'HEAP', 'LOC', 'LONG', 'REF', 'SHORT', 'EITHER'),
       6 => array('CHANNEL', 'FILE', 'FORMAT', 'STRUCT', 'UNION'),

/* '(', '|', '|:', ')', */

1. 7 => array('OF', 'AT', '@', 'IS', ':=:', 'ISNT', ':/=:', ':≠:', 'CTB', 'CT', '::', 'CTAB', '::=', 'TRUE', 'FALSE', 'EMPTY', 'NIL', '○', 'SKIP', '~'),

       7 => array('OF', 'AT', 'IS', 'ISNT', 'CTB', 'CT', 'CTAB', 'TRUE', 'FALSE', 'EMPTY', 'NIL', 'SKIP'),
       8 => array('NOT', 'UP', 'DOWN', 'LWB', 'UPB', '-', 'ABS', 'ARG', 'BIN', 'ENTIER', 'LENG', 'LEVEL', 'ODD', 'REPR', 'ROUND', 'SHORTEN', 'CONJ', 'SIGN'),

1. 9 => array('¬', '↑', '↓', '⌊', '⌈', '~', '⎩', '⎧'),

       9 => array(),

1. 10 => array('+*', 'I', '+×', '⊥', '!', '⏨'),

       10 => array(),

1. 11 => array('SHL', 'SHR', '**', 'UP', 'DOWN', 'LWB', 'UPB', '↑', '↓', '⌊', '⌈', '⎩', '⎧'),

       11 => array('SHL', 'SHR', 'UP', 'DOWN', 'LWB', 'UPB'),

1. 12 => array('*', '/', '%', 'OVER', '%*', 'MOD', 'ELEM', '×', '÷', '÷×', '÷*', '%×', '□', '÷:'),

       12 => array('OVER', 'MOD', 'ELEM'),

1. 13 => array('-', '+'),

       13 => array(),

1. 14 => array('<', 'LT', '<=', 'LE', '>=', 'GE', '>', 'GT', '≤', '≥'),

       14 => array('LT', 'LE', 'GE', 'GT'),

1. 15 => array('=', 'EQ', '/=', 'NE', '≠', '~='),

       15 => array('EQ', 'NE'),

1. 16 => array('&', 'AND', '∧', 'OR', '∨'),

       16 => array('AND', 'OR'),
       17 => array('MINUSAB', 'PLUSAB', 'TIMESAB', 'DIVAB', 'OVERAB', 'MODAB', 'PLUSTO'),
       18 => array('-:=', '+:=', '*:=', '/:=', '%:=', '%*:=', '+=:', '×:=', '÷:=', '÷×:=', '÷*:=', '%×:=', '÷::=', 'MINUS', 'PLUS', 'DIV', 'MOD', 'PRUS'),

1. 18 => array('-:=', '+:=', '*:=', '/:=', '%:=', '%*:=', '+=:', '×:=', '÷:=', '÷×:=', '÷*:=', '%×:=', '÷::=', 'MINUS', 'PLUS', 'DIV', 'MOD', 'PRUS'),

       18 => array('MINUS', 'PLUS', 'DIV', 'MOD', 'PRUS'),
       19 => array('THEF', 'ANDF', 'ORF', 'ANDTH', 'OREL', 'ANDTHEN', 'ORELSE'),
       20 => array('int_lengths', 'intlengths', 'int_shorths', 'intshorths', 'max_int', 'maxint', 'real_lengths', 'reallengths', 'real_shorths', 'realshorths', 'bits_lengths', 'bitslengths', 'bits_shorths', 'bitsshorths', 'bytes_lengths', 'byteslengths', 'bytes_shorths', 'bytesshorths', 'max_abs_char', 'maxabschar', 'int_width', 'intwidth', 'long_int_width', 'longintwidth', 'long_long_int_width', 'longlongintwidth', 'real_width', 'realwidth', 'long_real_width', 'longrealwidth', 'long_long_real_width', 'longlongrealwidth', 'exp_width', 'expwidth', 'long_exp_width', 'longexpwidth', 'long_long_exp_width', 'longlongexpwidth', 'bits_width', 'bitswidth', 'long_bits_width', 'longbitswidth', 'long_long_bits_width', 'longlongbitswidth', 'bytes_width', 'byteswidth', 'long_bytes_width', 'longbyteswidth', 'max_real', 'maxreal', 'small_real', 'smallreal', 'long_max_int', 'longmaxint', 'long_long_max_int', 'longlongmaxint', 'long_max_real', 'longmaxreal', 'long_small_real', 'longsmallreal', 'long_long_max_real', 'longlongmaxreal', 'long_long_small_real', 'longlongsmallreal', 'long_max_bits', 'longmaxbits', 'long_long_max_bits', 'longlongmaxbits', 'null_character', 'nullcharacter', 'blank', 'flip', 'flop', 'error_char', 'errorchar', 'exp_char', 'expchar', 'newline_char', 'newlinechar', 'formfeed_char', 'formfeedchar', 'tab_char', 'tabchar'),
       21 => array('stand_in_channel', 'standinchannel', 'stand_out_channel', 'standoutchannel', 'stand_back_channel', 'standbackchannel', 'stand_draw_channel', 'standdrawchannel', 'stand_error_channel', 'standerrorchannel'),
       22 => array('put_possible', 'putpossible', 'get_possible', 'getpossible', 'bin_possible', 'binpossible', 'set_possible', 'setpossible', 'reset_possible', 'resetpossible', 'reidf_possible', 'reidfpossible', 'draw_possible', 'drawpossible', 'compressible', 'on_logical_file_end', 'onlogicalfileend', 'on_physical_file_end', 'onphysicalfileend', 'on_line_end', 'onlineend', 'on_page_end', 'onpageend', 'on_format_end', 'onformatend', 'on_value_error', 'onvalueerror', 'on_open_error', 'onopenerror', 'on_transput_error', 'ontransputerror', 'on_format_error', 'onformaterror', 'open', 'establish', 'create', 'associate', 'close', 'lock', 'scratch', 'space', 'new_line', 'newline', 'print', 'write_f', 'writef', 'print_f', 'printf', 'write_bin', 'writebin', 'print_bin', 'printbin', 'read_f', 'readf', 'read_bin', 'readbin', 'put_f', 'putf', 'get_f', 'getf', 'make_term', 'maketerm', 'make_device', 'makedevice', 'idf', 'term', 'read_int', 'readint', 'read_long_int', 'readlongint', 'read_long_long_int', 'readlonglongint', 'read_real', 'readreal', 'read_long_real', 'readlongreal', 'read_long_long_real', 'readlonglongreal', 'read_complex', 'readcomplex', 'read_long_complex', 'readlongcomplex', 'read_long_long_complex', 'readlonglongcomplex', 'read_bool', 'readbool', 'read_bits', 'readbits', 'read_long_bits', 'readlongbits', 'read_long_long_bits', 'readlonglongbits', 'read_char', 'readchar', 'read_string', 'readstring', 'print_int', 'printint', 'print_long_int', 'printlongint', 'print_long_long_int', 'printlonglongint', 'print_real', 'printreal', 'print_long_real', 'printlongreal', 'print_long_long_real', 'printlonglongreal', 'print_complex', 'printcomplex', 'print_long_complex', 'printlongcomplex', 'print_long_long_complex', 'printlonglongcomplex', 'print_bool', 'printbool', 'print_bits', 'printbits', 'print_long_bits', 'printlongbits', 'print_long_long_bits', 'printlonglongbits', 'print_char', 'printchar', 'print_string', 'printstring', 'whole', 'fixed', 'float'),
       23 => array('pi', 'long_pi', 'longpi', 'long_long_pi', 'longlongpi'),
       24 => array('sqrt', 'curt', 'cbrt', 'exp', 'ln', 'log', 'sin', 'arc_sin', 'arcsin', 'cos', 'arc_cos', 'arccos', 'tan', 'arc_tan', 'arctan', 'long_sqrt', 'longsqrt', 'long_curt', 'longcurt', 'long_cbrt', 'longcbrt', 'long_exp', 'longexp', 'long_ln', 'longln', 'long_log', 'longlog', 'long_sin', 'longsin', 'long_arc_sin', 'longarcsin', 'long_cos', 'longcos', 'long_arc_cos', 'longarccos', 'long_tan', 'longtan', 'long_arc_tan', 'longarctan', 'long_long_sqrt', 'longlongsqrt', 'long_long_curt', 'longlongcurt', 'long_long_cbrt', 'longlongcbrt', 'long_long_exp', 'longlongexp', 'long_long_ln', 'longlongln', 'long_long_log', 'longlonglog', 'long_long_sin', 'longlongsin', 'long_long_arc_sin', 'longlongarcsin', 'long_long_cos', 'longlongcos', 'long_long_arc_cos', 'longlongarccos', 'long_long_tan', 'longlongtan', 'long_long_arc_tan', 'longlongarctan'),
       25 => array('first_random', 'firstrandom', 'next_random', 'nextrandom', 'long_next_random', 'longnextrandom', 'long_long_next_random', 'longlongnextrandom'),
       26 => array('real', 'bits_pack', 'bitspack', 'long_bits_pack', 'longbitspack', 'long_long_bits_pack', 'longlongbitspack', 'bytes_pack', 'bytespack', 'long_bytes_pack', 'longbytespack', 'char_in_string', 'charinstring', 'last_char_in_string', 'lastcharinstring', 'string_in_string', 'stringinstring'),
       27 => array('utc_time', 'utctime', 'local_time', 'localtime', 'argc', 'argv', 'get_env', 'getenv', 'reset_errno', 'reseterrno', 'errno', 'strerror'),
       28 => array('sinh', 'long_sinh', 'longsinh', 'long_long_sinh', 'longlongsinh', 'arc_sinh', 'arcsinh', 'long_arc_sinh', 'longarcsinh', 'long_long_arc_sinh', 'longlongarcsinh', 'cosh', 'long_cosh', 'longcosh', 'long_long_cosh', 'longlongcosh', 'arc_cosh', 'arccosh', 'long_arc_cosh', 'longarccosh', 'long_long_arc_cosh', 'longlongarccosh', 'tanh', 'long_tanh', 'longtanh', 'long_long_tanh', 'longlongtanh', 'arc_tanh', 'arctanh', 'long_arc_tanh', 'longarctanh', 'long_long_arc_tanh', 'longlongarctanh', 'arc_tan2', 'arctan2', 'long_arc_tan2', 'longarctan2', 'long_long_arc_tan2', 'longlongarctan2'),
       29 => array('complex_sqrt', 'complexsqrt', 'long_complex_sqrt', 'longcomplexsqrt', 'long_long_complex_sqrt', 'longlongcomplexsqrt', 'complex_exp', 'complexexp', 'long_complex_exp', 'longcomplexexp', 'long_long_complex_exp', 'longlongcomplexexp', 'complex_ln', 'complexln', 'long_complex_ln', 'longcomplexln', 'long_long_complex_ln', 'longlongcomplexln', 'complex_sin', 'complexsin', 'long_complex_sin', 'longcomplexsin', 'long_long_complex_sin', 'longlongcomplexsin', 'complex_arc_sin', 'complexarcsin', 'long_complex_arc_sin', 'longcomplexarcsin', 'long_long_complex_arc_sin', 'longlongcomplexarcsin', 'complex_cos', 'complexcos', 'long_complex_cos', 'longcomplexcos', 'long_long_complex_cos', 'longlongcomplexcos', 'complex_arc_cos', 'complexarccos', 'long_complex_arc_cos', 'longcomplexarccos', 'long_long_complex_arc_cos', 'longlongcomplexarccos', 'complex_tan', 'complextan', 'long_complex_tan', 'longcomplextan', 'long_long_complex_tan', 'longlongcomplextan', 'complex_arc_tan', 'complexarctan', 'long_complex_arc_tan', 'longcomplexarctan', 'long_long_complex_arc_tan', 'longlongcomplexarctan', 'complex_sinh', 'complexsinh', 'complex_arc_sinh', 'complexarcsinh', 'complex_cosh', 'complexcosh', 'complex_arc_cosh', 'complexarccosh', 'complex_tanh', 'complextanh', 'complex_arc_tanh', 'complexarctanh')
       ),
   'SYMBOLS' => array(
       1 => array(
           '(', '|', '|:', ')',
           '@', ':=:', ':/=:', ':≠:', '::', '::=', '○', '~', '?',
           '(', ')', '{', '}', '[', ']', '+', '-', '*', '/', '%', '=', '<', '>', '!', '^', '&', '|', '?', ':', ';', ',',
            '¬', '↑', '↓', '⌊', '⌈', '~', '⎩', '⎧', # monadic
            '+*', 'I', '+×', '⊥', '!', '⏨',
            '**', '↑', '↓', '⌊', '⌈', '⎩', '⎧', # diadic
            '*', '/', '%', '%*', '×', '÷', '÷×', '÷*', '%×', '□', '÷:',
            # '-', '+',
            '<', '<=', '>=', '>', '≤', '≥',
            '=', '/=', '≠', '~=',
            '&', '∧', '∨',
            '-:=', '+:=', '*:=', '/:=', '%:=', '%*:=', '+=:', '×:=', '÷:=', '÷×:=', '÷*:=', '%×:=', '÷::='
       )
   ),
   'CASE_SENSITIVE' => array(
       GESHI_COMMENTS => false,
       1 => true, 2 => true, 3 => true, 4 => true, 5 => true,
       6 => true, 7 => true, 8 => true, 9 => true, 10 => true,
       11 => true, 12 => true, 13 => true, 14 => true, 15 => true,
       16 => true, 17 => true, 18 => true, 19 => true, 20 => true,
       21 => true, 22 => true, 23 => true, 24 => true, 25 => true,
       26 => true, 27 => true, 28 => true, 29 => true),
   'STYLES' => array(
       'KEYWORDS' => array(
           1 => 'color: #b1b100; font-weight: bold;',
           2 => 'color: #b1b100; font-weight: bold;',
           3 => 'color: #b1b100; font-weight: bold;',
           4 => 'color: #b1b100; font-weight: bold;',
           5 => 'color: #b1b100; font-weight: bold;',
           6 => 'color: #b1b100; font-weight: bold;',
           7 => 'color: #b1b100; font-weight: bold;',
           8 => 'color: #b1b100; font-weight: bold;',
           9 => 'color: #b1b100; font-weight: bold;',
           10 => 'color: #b1b100; font-weight: bold;',
           11 => 'color: #b1b100; font-weight: bold;',
           12 => 'color: #b1b100; font-weight: bold;',
           13 => 'color: #b1b100; font-weight: bold;',
           14 => 'color: #b1b100; font-weight: bold;',
           15 => 'color: #b1b100; font-weight: bold;',
           16 => 'color: #b1b100; font-weight: bold;',
           17 => 'color: #b1b100; font-weight: bold;',
           18 => 'color: #b1b100; font-weight: bold;',
           19 => 'color: #b1b100; font-weight: bold;',
           20 => 'color: #b1b100;',
           21 => 'color: #b1b100;',
           22 => 'color: #b1b100;',
           23 => 'color: #b1b100;',
           24 => 'color: #b1b100;',
           25 => 'color: #b1b100;',
           26 => 'color: #b1b100;',
           27 => 'color: #b1b100;',
           28 => 'color: #b1b100;',
           29 => 'color: #b1b100;'
           ),
       'COMMENTS' => array(
           1 => 'color: #666666; font-style: italic;',
           2 => 'color: #666666; font-style: italic;',
           3 => 'color: #666666; font-style: italic;',
           4 => 'color: #666666; font-style: italic;',
           5 => 'color: #666666; font-style: italic;',
           'MULTI' => 'color: #666666; font-style: italic;'
           ),
       'ESCAPE_CHAR' => array(
           0 => 'color: #000099; font-weight: bold;'
           ),
       'BRACKETS' => array(
           0 => 'color: #009900;'
           ),
       'STRINGS' => array(
           0 => 'color: #0000ff;'
           ),
       'NUMBERS' => array(
           0 => 'color: #cc66cc;',
           ),
       'METHODS' => array(
           0 => 'color: #004000;',
           1 => 'color: #004000;'
           ),
       'SYMBOLS' => array(
           0 => 'color: #339933;',
           1 => 'color: #339933;'
           ),
       'REGEXPS' => array(),
       'SCRIPT' => array()
       ),
   'URLS' => array(
       1 => , 2 => , 3 => , 4 => , 5 => ,
       6 => , 7 => , 8 => , 9 => , 10 => ,
       11 => , 12 => , 13 => , 14 => , 15 => ,
       16 => , 17 => , 18 => , 19 => , 20 => ,
       21 => , 22 => , 23 => , 24 => , 25 => ,
       26 => , 27 => , 28 => , 29 => ),
   'OOLANG' => true,
   'OBJECT_SPLITTERS' => array(
       1 => 'OF'
       ),
   'REGEXPS' => array(),
   'STRICT_MODE_APPLIES' => GESHI_NEVER,
   'SCRIPT_DELIMITERS' => array(),
   'HIGHLIGHT_STRICT_BLOCK' => array()

); ?> </lang>

Test ASCII version: <lang algol68>INT sum sq := 0; FOR i WHILE sum sq /= 70*70 DO

 sum sq +:= i**2

OD</lang> Test Unicode version: <lang algol68>INT sum sq := 0; FOR i WHILE sum sq ≠ 70×70 DO

 sum sq +:= i↑2

OD</lang>

ThanX NevilleDNZ

Yeah, you're right; there need to be some followup instructions. Email to mikemol@rosettacode.org and benbe@geshi.org. --Michael Mol 16:04, 23 April 2010 (UTC)

Whoops, fixed. —Underscore (Talk) 14:57, 24 April 2010 (UTC)

> Doesn't hurt anything to have the code exposed, does it?

LOL - pinch me... I forgot I was posting to rosettacode.org. ;-)

Maybe we could/should start a page: GeSHi#ALGOL_68 etc (with the php for GeSHi, and a specimen of GeSHi#ALGOL 68 - specimen unittest code to for checking the result. Ideally any changers would be tested enough for importing directly/live into GeSHi...

BTW: The operators: '&#8804;' and '&#8805;' can be done in html as '&le;' and '&ge;' eg '≤' and '≥';

There are a few of others: ne: ≠, cent: ¢ pound: £ deg: °, and: ∧, or: ∨, not: ¬, lceil: ⌈, lfloor: ⌊, times: ×, divide: ÷ larr: ←, rarr: →, uarr: ↑, darr: ↓, and perp: ⊥ . But no HTML entities for □, ○, ⎩, ⎧ (Unicode 5.1) and "⏨" (decimal exponentiation - Unicode 5.2).

Detecting all the HTML entity defs (http://php.net/manual/en/function.htmlentities.php) is probably the easiest way of doing things.

Trivia: Standard Algol 60 required sup: ⊃, equiv: ≡, "␣" and "⏨" (decimal exponentiation - Unicode 5.2); The Soviet Algol compiler - used for the Buran Space Shuttle reentry software - even had the character: loz: ◊, together with support for °, ∅, ± and ∇ ... I could never figure out what this diamond ◊ character was used for!!! The Germans also included the unusual "᛭" (iron/runic cross), I'm not convinced it was used for multiplication. Probably something used for something mundane like printing train time tables, you would have to be German to understand. :-)

More Trivia: Most of the HTML entities appear to have arrived via Adobe fonts from an IBM Selectric typewriter font ball that was popular prior to ASCII 69 becoming a mandated US standard. Some of the HTML entities are fairly weird.

Njoy NevilleDNZ 05:43, 24 April 2010 (UTC)

The HTML escapes in that language file will probably cause some trouble with GeSHi. Could someone send me an Unicode version of that file without those HTML escapes? --BenBE 10:58, 24 April 2010 (UTC)

OK... I used mediawiki to do the conversion. :-) ... Will email U a copy too.

NevilleDNZ 13:01, 24 April 2010 (UTC)

Revised Algol68.php (Quick fix: 1.0.8.8.2) to remove errant ">" that was being injected into in code before some symbols.

211.31.53.224 07:04, 15 June 2010 (UTC)