Hi, I’m murphy, the developer of CodeRay. I have been busy with work and
private life in the last months, so I couldn’t answer to all emails and
tickets. But I’m still interested and willing to work on CodeRay!
The easiest way to get a syntax highlighting library with lots of
languages is to port the awesome Pygments library to Ruby. CodeRay
scanners are hand-crafted methods, while Pygments uses a clever DSL. So,
CodeRay is faster, but Pygments is easier to extend.
If we want to extend CodeRay instead of porting Pygments, I need your
help 
It’s true that I received about 20 scanner contribution over the last
years. Some of them have been included, but others were not up to the
quality standard I want to set with CodeRay. I mean no offence to the
people who want to contribute; their help is invaluable. But the
scanners just need more work. They lack:
- Example code
To be tested, a scanner needs a lot of example code. CodeRay has an
extensive test suite build around this idea:
http://svn.rubychan.de/coderay-scanner-tests/trunk/ (still under private
SVN because of open copyright questions; you can download and run the
suite simply from the git checkout with rake test:scanners.) The more
complex the language, the more example code is needed. For Lua, a dozen
files from different projects can be enough. For a language like Perl, I
think that even the PLEAC
(http://pleac.sourceforge.net/pleac_perl/index.html) is only scratching
the surface.
- Completeness
I don’t want to release a scanner that covers only 80% of a languages’
features, and call it “supported”. It’s possible to beta-test new
scanners as standalone Gems, like coderay_bash. When they reach
stability and a very good level of language coverage (see 1), I promise
to include them quickly.
- Testing in general
Some of the code I received was just buggy. That’s my own fault, because
the testing framework you need to write a good scanner is still not well
documented. (If you need any help, please contact me.)
However, stableness is critical, since some use CodeRay to highlight
user input live - no scanner should ever run into an infinite loop or
eat obscene amounts of memory because of a typo or an overlooked edge
case in the Scanner.
Thomas: The 1.1 roadmap you linked to is outdated and not realistic; it
never got updated after the 1.0 release. How about a new roadmap that
focusses on additional language support? I suggest to give:
- CoffeeScript, Sass (both used often in the Ruby community)
- Objective-C (rising star)
- Bash, Lua (often requested)
highest priority. Please comment if I’m missing anything here.
Josh: A codebrawl might be a good idea, but I think it requires better
documentation for scanner implementation. I may not find the time do
that right now.
Ryan:
Gem.find_files(“coderay/scanners/*.rb”)
CodeRay was written for Ruby 1.8, and I didn’t want to
depend on RubyGems at that time. A future version can be 1.9-only, so
maybe we can ditch the Plugin system and use RubyGems.
I will go through all unanswered mails and tickets in the next days, and
of course follow this thread. Thanks to everybody who contacted me; I
was not subsribed to ruby-talk.
