The subset of reStructuredText worth committing to memory
reStructuredText is the standard for documentation in the Python world.
It’s a bit weird. It’s like Markdown but older, more feature-filled and in my experience significantly harder to remember.
There are plenty of guides and cheatsheets out there, but when writing simple documentation for software projects I think there’s a subset that is worth committing to memory. I’ll describe that subset here.
First though: when writing reStructuredText having a live preview render is extremely useful. I use rst.ninjs.org for this. If you don’t trust that hosted version (it round-trips your documentation through the server in order to render it) you can run a local copy instead using the underlying source code.
Paragraphs work the same way as Markdown and plain text. They are nice and easy.
This is the first paragraph. No need to wrap the text (though you can wrap at e.g. 80 characters without affecting rendering). This is the second paragraph.
reStructuredText section headings are a little surprising.
Markdown has multiple levels of heading, each with a different number of prefix hashes:
# Markdown heading level 1 ## Markdown heading level 2 .. ###### Markdown heading fevel 6
In reStructuredText there is no single format for these different levels. Instead, the format you use first will be treated as an H1, the next format as an H2 and so on. Here’s the description from the official documentation:
Sections are identified through their titles, which are marked up with adornment: “underlines” below the title text, or underlines and matching “overlines” above the title. An underline/overline is a single repeated punctuation character that begins in column 1 and forms a line extending at least as far as the right edge of the title text. Specifically, an underline/overline character may be any non-alphanumeric printable 7-bit ASCII character. […] There may be any number of levels of section titles, although some output formats may have limits (HTML has 6 levels).
This is deeply confusing. I suggest instead standardizing on the following:
===================== This is a heading 1 =====================
This heading has = signs both above and below, and they extend past the text by a single character in each direction.
This is a heading 2 =================== This is a heading 3 ------------------- This is a heading 4 ~~~~~~~~~~~~~~~~~~~
If you need more levels, you can invent them using whatever character you like—but try to stay consistent within your project.
As with headings, you can use a variety of characters for these. I suggest sticking with asterisks.
A blank line is required before starting a bulleted list. * A bullet point * Another bullet point
If you decide to wrap your text (I tend not to) you must maintain the indentation on the wrapped lines:
* A bulleted list item. Since the text is wrapped each subsequent line of text must be indented by two spaces. * Second list item.
Nested lists are supported, but you MUST leave a blank line above the first inner list bullet point or they won’t work:
* This is the first bullet list item. Here comes a sub-list: * Hello sublist * Sublist two * Back to the parent list.
I only use three inline markup features: bold, italic and code.
**Bold text** is surrounded by two asterisks. *Italic text* is one asterisk. ``inline code`` uses two backticks at either side of the code.
Links are my least favorite feature of reStructuredText. There are several different ways of including them, but the one I use most often (and hence have committed to memory) is this one:
`a link, note the trailing underscores <http://example.com>`__
So that’s a backtick at the start, then the link text, then the URL contained in greater than / less than symbols, then another backtick and then TWO underscores to finish it off.
Why two underscores? Because if you only use one, the text part of the link is remembered and can be used to duplicate your link later on—see example below. In my experience this is more trouble than it’s worth.
A more complex link syntax example (documented here) looks like this:
See the `Python home page`_ for info. This link_ is an alias to the link above. .. _Python home page: http://www.python.org .. _link: `Python home page`_
I can’t remember this at all, so I stick with the anonymous hyperlink syntax instead.
The easiest way to embed a block of code is like this:
:: # This is a code example print("It needs to be indented")
:: indicates that a code block is coming up. The blank line after the
:: before the indentation starts is required.
Most renderers have the ability to apply syntax highlighting. To specify that a block should have syntax highlighting for a specific language, replace the
:: in the above example with one of the following:
There are plenty of options for embedding images, but the most basic syntax (worth remembering) looks like this:
.. image:: full_text_search.png :alt: alternate text
This will embed an image of that filename that sits in the same directory as the document itself.
In my opinion this is the key feature that makes reStructuredText more powerful than Markdown for larger documentation projects.
Again, there is a vast and complex array of options around this, but the key thing to remember is how to add a reference name to a specific section and how to link to that section later on.
Names are applied to section headings, by adding some magic text before the heading itself. For example:
.. _full_text_search: Full-text search ================
Note the format: two periods, then a space, then an underscore, then the label, then a colon at the end.
full_text_search is now associated with that heading. I can link to it from any page in my documentation project like so:
Note that the leading underscore isn’t included in this reference.
The link text displayed will be the text of the heading, in this case “Full-text search”. If I want to replace that link text with something custom, I can do so like this:
Learn about the :ref:`search feature <full_text_search>`.
This syntax is similar to the inline hyperlink syntax described above.
The definitive guide to reStructuredText is the reStructuredText Markup Specification. My favourite of the various quick references is the Restructured Text (reST) and Sphinx CheatSheet by Thomas Cokelaer.
I’m a huge fan of Read the Docs for hosting documentation—it’s the key reason I use reStructuredText in my projects. Unsurprisingly, they offer extensive documentation to help you make the most of their platform.