I’ve added a proper command-line interface to gem markdown_helper.
I have put up gem markdown_helper v1.5, which supports nested include files. An included file can now include more files.
GitHub project structured_log goes public.
Soon to be a Ruby gem.
I have updated the markdown_helper gem.
- File inclusion
- mage path resolution (new)
The image path resolution replaces relative image paths with absolute image URLs.
- This matters because in the documentation for a gem (on RubyDoc.info), YARD formatting changes some file structures, which breaks relative links to images.
- The resolution to absolute URLs avoids that breakage.
The markdown_helper gem I’ve put up does (so far) one thing:
- Supports file inclusion.
I have in mind two additional features:
- Support for relative links for images (see below for why this matters).
- Support slideshow-style markdown pages (pages linked by next/prev navigation links).
Query: What else would be useful?
About relative links for images: they work fine in GitHub markdown, but when the project is formed into a gem, the links are broken in the gem’s documentation. That’s because on RubyDoc.info, YARD has rearranged some files and folders.
The workaround is to substitute absolute links to the files in
raw.githubusercontent.com. This would be very inconvenient, not to say tedious and possibly error-prone.
What I want to add to the helper is a method that replaces the relative links with absolute ones automatically. That way, we have the convenience of relative links on GitHub, and correct (absolute) links on RubyDoc.
GitHub users have for years been asking for include files in GitHub markdown pages.
I’ve just put up a new Ruby gem, markdown_helper, that implements include files.
A file can be included as:
- Highlighted code block.
- Plain code block.
- Verbatim text.
The gem has an API and a CLI. (For the very young, CLI == command-line interface.)
I have made public my GitHub repository MarkdownHelper.
The first feature is file inclusion for GitHub markdown, supporting included text as:
* Highlighted code block.
* Plain code block.
* Verbatim text.
I ran across this wonderful post by Richard Kim, largely about doing a better job on GitHub README.md files.
Changed my life. I’m doing major reworks.