Header sections will get a descriptive hash anchor: rather than
`section-1`, the section will be given an id containing the header text
with spaces stripped and replaced with `_`. `section-Header_Goes_Here`
for instance.
Thanks to [Luke Andrew][1] for the initial work on this patch.
[1]: https://github.com/zyx
Adding a dependency on `Pathname`, which provides the excellent
`relative_path_from` method. That happens to be exactly what's needed
to fix the pathnames for the source jumplist issue that [Topfunky][]
reported.
Closes GH-26.
[Topfunky]: https://github.com/topfunky
Languages without single-line comments (CSS) explode when running
through `highlight`, as the `DIVIDER` mechanism doesn't deal well with
`nil` comment characters. I've reworked the mechanism such that it
uses multi-line comments when single-line comments aren't available.
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.
