From: Kornelius Kalnbach <lists@...>
Date: 2012-06-19T21:30:31+09:00
Subject: Re: Syntax Highlighter

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:

1) 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.

2) 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.

3) 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.

- [murphy]

-- 
Posted via http://www.ruby-forum.com/.