4 ms·

Truth is, I picked CodeRay for two reasons. It's fast and it's pure ruby. Pygments is great and I spent some time on a version that used it but CodeRay just fit

by twoism 16y ago

Truth is, I picked CodeRay for two reasons. It's fast and it's pure ruby. Pygments is great and I spent some time on a version that used it but CodeRay just fits better within our app. It's pure ruby, supports most languages I thought we should start with, it's extensible and has a roadmap for things that I could see our users asking for.

nex3 16y ago
From a user's perspective, at least, I would think that language coverage would trump most other things when considering different highlighters.
- twoism 16y ago
  True. However, working within our architecture and finding a good fit for most use cases was what trumped all else for the feature launch. I like the library we chose and hope it gains traction as a pure ruby highlighting lib but if for some reason it doesn't fit our users needs, we can certainly find a way to accommodate them.
- patio11 16y ago
  From a user's perspective, if your language is covered, you don't care about that guy on the Internets going all nerdrage on you because you do not support an obscure variant of Cobol with all commands written in romanized Arabic. Language popularity, like popularity for just about everything else, is a zipf distribution. Twenty languages probably covers well in excess of 99% of the people who will actually try to use this. You can't ever please him, and he's most likely to say "Pah, this isn't exactly what I want, I'm going to roll my own blog." (P.S.: the hard bitten product manager in me thinks that, from a user's perspective, the user can't program and this feature means nothing to her either way, and every second spent thinking about it is a second the business never gets back.)
greyman 16y ago
Nice. Now please allow ads displaying and your service will be perfect.
scorpion032 16y ago
Why not just slap in the google code highlighter javascript, if the page contains code. http://code.google.com/p/syntaxhighlighter/ http://code.google.com/p/syntaxhighlighter/ Simpler and cleaner that way.
- Torn 16y ago
  +1. Is there a way for us to userscript / greasemonkey this in in the meantime?

by twoism 16y ago

nex3 16y ago

From a user's perspective, at least, I would think that language coverage would trump most other things when considering different highlighters.

twoism 16y ago
True. However, working within our architecture and finding a good fit for most use cases was what trumped all else for the feature launch. I like the library we chose and hope it gains traction as a pure ruby highlighting lib but if for some reason it doesn't fit our users needs, we can certainly find a way to accommodate them.
patio11 16y ago
From a user's perspective, if your language is covered, you don't care about that guy on the Internets going all nerdrage on you because you do not support an obscure variant of Cobol with all commands written in romanized Arabic. Language popularity, like popularity for just about everything else, is a zipf distribution. Twenty languages probably covers well in excess of 99% of the people who will actually try to use this. You can't ever please him, and he's most likely to say "Pah, this isn't exactly what I want, I'm going to roll my own blog." (P.S.: the hard bitten product manager in me thinks that, from a user's perspective, the user can't program and this feature means nothing to her either way, and every second spent thinking about it is a second the business never gets back.)

greyman 16y ago

Nice. Now please allow ads displaying and your service will be perfect.

scorpion032 16y ago

Why not just slap in the google code highlighter javascript, if the page contains code. http://code.google.com/p/syntaxhighlighter/ http://code.google.com/p/syntaxhighlighter/ Simpler and cleaner that way.

Torn 16y ago
+1. Is there a way for us to userscript / greasemonkey this in in the meantime?