SourceForge uses Pygments to colourize source listings. Pygments main now supports COBOL, in both FIXED (the default) and FREE formats.
Normally, the forge will accept code listings when the entire chunk is indented 4 spaces. That can be a hassle when cutting and pasting code, so it also supports 6 squigglies (tilde ~) characters at the top and bottom of listings.
It's hard to show here, as it'll try and highlight, so I'm using 3 for the demonstration. but you need 6 tildes,
<some code here, assumed FIXED form, 1-6, 7, 8-72>
<some code here, in free form>
code can start in column 1 and continue past 72
As the highlighter tries to guess at what the code is, and there isn't really any clues in the sample above, it falls back to C. You will see continue colourized, but not much else.
For FIXED form, the first 6 characters are treated as sequence number and keywords won't look right, if you don't leave in the spacing. Just change the override to cobolfree for those snippets.
Example of when it's wrong. Below uses override of cobol, with the code not indented at all.
01 ws-variable pic x(20).
open input datafilename
And now with cobolfree, and no indentation
Woohoo for progress and COBOL sources in these discussions.
Especially for the "free format support" :-)
Mod edit: removed some reply-to
I'm thinking about making cobolfree the default lexer in Pygments. It handles fixed form pretty well, and it'll avoid the weirdness that shows up in the code browser (not markup, but the SVN commit browser), and it'll assist when people paste code that isn't quite indented by enough spaces. For instance, the COBJAPI code that László posts deserves better than what shows up at
As these are .cob files, they default to cobol, not cobolfree, so the first 7 columns are coloured as sequence number and comment marker fields, and well, the COBJAPI code deserves better than that. ;-)
Once the change is posted to BitBucket and the team Pocoo repos, it could be days or years before the change hits SourceForge and the other sites that use Pygments.
Changes will go in the same day once we get our own Allura site up and running. We'll also be able to experiment with colour schemes, as to try and please the most and displease the least, as I've noticed that programmers (myself included) make rather poor colour scheme choices as individuals. :-)
Any objections to cobolfree being the default, and cobol needing the "override" instead of vice versa?
How is the "override" done (in both ways)?
Good question (once I started looking at it). ;-)
Right now there are two lexers, duplication of effort. I think that needs to change to a singleton, with free form as the assumption. Plus I had made an arbitrary decision to have .cob as fixed, and .cbl as a free form trigger.
It means that the sequence number field for fixed source will highlight depending on what it matches; as numbers, or user words or keywords in the rare case. Something I think is a liveable scenario, seeing as this is a straight up context-free regex lexer, that will never be perfect anyway, and is only for visual effect.
I have a bug or two fix, a very smart optimization that I got as a hint from Georg Brandl (smart cookie that he is), plus shuffle out some reserved words from Ron and your works, Simon, since this went in for 1.1 and it marked some keywords as Inactive, which are now supported.
I'll post the changes to the Pygments repo soon. When it first went in the lexer was added to compiled.py, but Team Pocoo decided we should get our own, business.py handler. business.py. :-)
The highlighter will assume free form COBOL (which again, all fixed form loses is the sequence number fields special colour), and we won't be plagued by the weird colouring for the first 7 character on actual free form sources.
Now it'll all be free form, regardless of extension, and the SVN browser will look nicer. I'll keep both tags in the file so all the special ::cobol ::cobolfree markers will still work though. Or, maybe add a third, ::cobolfixed, will try a few things over the next few days.
It takes my brain a few hours of soak time when it comes to these complex regular expressions. The Regex-Fu is weak. Very very weak. ;-)
If it gets good to me, I may take a kick at posting code to the Vim team as well. The default COBOL support, umm, kinda blows, with hard to read dark red background error indicators everywhere. Easy to change, but I'll see about posting the changes into the Vim distribution.
Sounds like all fixed-form reference format indicators will be broken (including comment and continuation), won't they? This would be quite a severe issue for me.
As I've just recognized this: intrinsic function highlighting should not be based on the name but on name + '(?=\s*()'.
I suggest to check both with the new default highlighting on sources like https://sourceforge.net/p/open-cobol/contrib/HEAD/tree/trunk/samples/games/2048/2048-GAME.COB
I'm not sure if this is something within your reach but the lines should not be generated via div + id but via span + id (stry to validate the html currently generated).
Yeah, good point. More thinking...
I always default to free format ;-)
I vote free format.
Free form it is.
Due to the nature of upgrade cycles for websites, this may not make into the wild for a while.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.