`pygmentize` 1.0+ has an `-N` option that attempts to match a file (via
the extension) to a language lexer. If `pygmentize` is installed, we'll
run it with this option to get a language.
If no language is detected, `pygmentize -N` returns `text`. In that case,
we'll first look for a user-provided language to use as a fallback. If no
language was provided, highlight using `ruby` as a reasonable default.
Closes issue #19.
This closes issue #10, in theory, but I'm not completely happy with the
behavior. The output for both UTF-8 and ISO-8859-1 sources is arguably
correct, but I think it'd be better to do some autodetecting of the file
encoding, and explicitly convert everything to UTF-8 on input. One
option is the [`chardet` gem][gem], but I'm loath to add another
dependency to Rocco...
[gem]: http://rubygems.org/gems/chardet/versions/0.9.0
In v0.5, the Mustache template is hardcoded as
`./lib/rocco/layout.mustache`. This makes it quite difficult to
style generated content as one must edit the layout file inside the
gem itself to make changes.
I propose leaving that file as a sensible default, but allowing the user
to specify an absolute or relative (to the current working directory)
path to a mustach template of her choosing. That's implemented in this
commit.
The following works in Docco, but not in Rocco:
Level 1 Heading
===============
Level 2 Heading
---------------
Happily, the fix is trivial. In Docco, the regex for comments is:
# Does the line begin with a comment?
l.comment_matcher = new RegExp('^\\s*' + l.symbol + '\\s?')
Changing Rocco's comment pattern to:
@comment_pattern = Regexp.new("^\\s*#{@options[:comment_chars]}\s?")
Solves the problem for me.
Rocco splits against `<span class="c.">`, which works fine for Ruby
where the `span` has a class of `c1`, but fails for Bash (and probably
other languages), where the `span` has a class of `c`. The fix is
trivial.
