That is:
def function:
"""
This is a comment
with _lots_ of leading
space! OMG!
"""
pass
Will parse into:
[
[
[ "This is a comment",
"with _lots_ of leading",
"space! OMG!"
],
...
]
]
Block comments are parsed out, but the commentchar removal isn't working
yet. I'll refactor that code out of it's current home, and move it into
`parse`, as I need to know what _kind_ of comment it is that I'm
stripping. Carrying that metadata around doesn't make any sense, so
I'll just convert the comment on the fly into a set of non-comment
strings.
I'm a bit loath to change the rendering entirely without talking to
Ryan, but I'd really prefer to replicate Docco's CSS file generation
rather than hotlinking out to the GitHub-hosted version. Offline
support would require it, if for no other reason...
Closes GH-23. Thanks to [Myles Byrne](http://www.myles.id.au/)
In the same way that it makes sense to skip the shebang (#!) line in
scripts, it makes sense to skip the encoding definition in Python files
(described by [PEP 263][p]) and Ruby 1.9 files (similar enough syntax
that it's not worth worrying about.
[p]: http://www.python.org/dev/peps/pep-0263/
Adding comment characters for bash, c, c++, coffee script, java, javascript, lua, python, ruby, and scheme. Paving the way for block-comment parsing later on...
Closes issue #20.
`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
Added:
* `docs?`: True if `docs` contains text of any sort, False if
it's empty.
* `code?`: True if `code` contains text of any sort, False if
it's empty.
* `empty?`: True if both `code` and `docs` are empty. False
otherwise.
* `header?`: True if `docs` contains _only_ a HTML header. False
otherwise.
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.
Rocco uses the Docco CSS directly, so when they make an update to the
HTML/CSS, Rocco needs to play along. In this case, Docco changed from
`#` to `¶`, and changed classnames as well (in
[f8a88d66b381a1c04358][]).
This commit migrates that change to Rocco.
[f8a88d66b381a1c04358]:
f8a88d66b3
