Skip to main content

Testing with VirtualBox on OS-X

I am using OS-X as a development platform for a web application (Apache, Django, Satchmo, etc.). Active development is done with Chrome, Firefox, and Safari, but I need to test and debug with various IE versions as well.

To do this on a single machine (my iMac), I installed Oracle's Virtualbox virtual machine software. I then installed Windows XP as a guest OS on virtualbox.

If I'm running Apache and my application on my iMac, how to configure Virtualbox/XP so that IE can access my OS-X application? The default install uses NAT, which means that XP can't see my OS-X machine.

To remedy that, go to the Virtualbox Network configuration. Change the attachment mode ('Attached to:') to 'Bridged Adapter'. Then select the active network adapter on OS-X. I am connected using wi-fi, so under 'Name:' I choose 'en1:Wi-Fi (AirPort)'. Once this is done, IE in XP can access my web server.

Use ifconfig to determine the IP address of the OS-X network adapter you are using. Use this IP address in the URL you use in IE. You can, of course, update /etc/hosts (or whatever) on Windows XP to point to this address, which will allow you to use your desired domain name in the URL instead of an IP address.

If you have problems check your console log to see what's going on. You'll have to be sure that you have web sharing enabled in your OS-X settings, or the OS-X firewall will not let IE connect to Apache.

Using Pandoc with Problematic UTF-8 Files

I recently used pandoc to convert some html files to reST. Initially, there were numerous errors about invalid characters. Here is the brute-force solution I arrived at to get the job done while attempting to reasonably convert offending characters into something reasonable.

Read more…

Converting MS Word DOCX Document to reStructuredText

A client has a substantial body of written work that began life as MS Word documents. They also created many derivative documents in various formats (including HTML, PDF, Dreamweaver, MS Front Page, etc.) for different use cases. Our recommendation was that, going forward, they should create content once, in a canonical format, from which they could generate documents in whatever format they need(HTML, PDF, etc.). That subject is beyond the scope of this note. This note is focused on a quick and dirty method to access their assets in MS Word format and convert them into something more widely useful.

Read more…

A reStructuredText Primer

Author: Richard Jones
Version: 5801
Copyright: This document has been placed in the public domain.

The text below contains links that look like "(quickref)". These are relative links that point to the Quick reStructuredText user reference. If these links don't work, please refer to the master quick reference document.


This document is an informal introduction to reStructuredText. The What Next? section below has links to further resources, including a formal reference.


From the outset, let me say that "Structured Text" is probably a bit of a misnomer. It's more like "Relaxed Text" that uses certain consistent patterns. These patterns are interpreted by a HTML converter to produce "Very Structured Text" that can be used by a web browser.

The most basic pattern recognised is a paragraph (quickref). That's a chunk of text that is separated by blank lines (one is enough). Paragraphs must have the same indentation -- that is, line up at their left edge. Paragraphs that start indented will result in indented quote paragraphs. For example:

This is a paragraph.  It's quite

   This paragraph will result in an indented block of
   text, typically used for quoting other text.

This is another one.

Results in:

This is a paragraph. It's quite short.

This paragraph will result in an indented block of text, typically used for quoting other text.

This is another one.

Text styles


Inside paragraphs and other bodies of text, you may additionally mark text for italics with "*italics*" or bold with "**bold**". This is called "inline markup".

If you want something to appear as a fixed-space literal, use "``double back-quotes``". Note that no further fiddling is done inside the double back-quotes -- so asterisks "*" etc. are left alone.

If you find that you want to use one of the "special" characters in text, it will generally be OK -- reStructuredText is pretty smart. For example, this lone asterisk * is handled just fine, as is the asterisk in this equation: 5*6=30. If you actually want text *surrounded by asterisks* to not be italicised, then you need to indicate that the asterisk is not special. You do this by placing a backslash just before it, like so "\*" (quickref), or by enclosing it in double back-quotes (inline literals), like this:



Think of inline markup as a form of (parentheses) and use it the same way: immediately before and after the text being marked up. Inline markup by itself (surrounded by whitespace) or in the middle of a word won't be recognized. See the markup spec for full details.


Lists of items come in three main flavours: enumerated, bulleted and definitions. In all list cases, you may have as many paragraphs, sublists, etc. as you want, as long as the left-hand side of the paragraph or whatever aligns with the first line of text in the list item.

Lists must always start a new paragraph -- that is, they must appear after a blank line.

enumerated lists (numbers, letters or roman numerals; quickref)

Start a line off with a number or letter followed by a period ".", right bracket ")" or surrounded by brackets "( )" -- whatever you're comfortable with. All of the following forms are recognised:

1. numbers

A. upper-case letters
   and it goes over many lines

   with two paragraphs and all!

a. lower-case letters

   3. with a sub-list starting at a different number
   4. make sure the numbers are in the correct sequence though!

I. upper-case roman numerals

i. lower-case roman numerals

(1) numbers again

1) and again

Results in (note: the different enumerated list styles are not always supported by every web browser, so you may not get the full effect here):

  1. numbers
  1. upper-case letters and it goes over many lines

    with two paragraphs and all!

  1. lower-case letters
    1. with a sub-list starting at a different number
    2. make sure the numbers are in the correct sequence though!
  1. upper-case roman numerals
  1. lower-case roman numerals
  1. numbers again
  1. and again
bulleted lists (quickref)

Just like enumerated lists, start the line off with a bullet point character - either "-", "+" or "*":

* a bullet point using "*"

  - a sub-list using "-"

    + yet another sub-list

  - another item

Results in:

  • a bullet point using "*"
    • a sub-list using "-"
      • yet another sub-list
    • another item
definition lists (quickref)

Unlike the other two, the definition lists consist of a term, and the definition of that term. The format of a definition list is:

  Definition lists associate a term with a definition.

  The term is a one-line phrase, and the definition is one or more
  paragraphs or body elements, indented relative to the term.
  Blank lines are not allowed between term and definition.

Results in:

Definition lists associate a term with a definition.
The term is a one-line phrase, and the definition is one or more paragraphs or body elements, indented relative to the term. Blank lines are not allowed between term and definition.

Preformatting (code samples)


To just include a chunk of preformatted, never-to-be-fiddled-with text, finish the prior paragraph with "::". The preformatted block is finished when the text falls back to the same indentation level as a paragraph prior to the preformatted block. For example:

An example::

    Whitespace, newlines, blank lines, and all kinds of markup
      (like *this* or \this) is preserved by literal blocks.
  Lookie here, I've dropped an indentation level
  (but not far enough)

no more example

Results in:

An example:

  Whitespace, newlines, blank lines, and all kinds of markup
    (like *this* or \this) is preserved by literal blocks.
Lookie here, I've dropped an indentation level
(but not far enough)

no more example

Note that if a paragraph consists only of "::", then it's removed from the output:


    This is preformatted text, and the
    last "::" paragraph is removed

Results in:

This is preformatted text, and the
last "::" paragraph is removed



To break longer text up into sections, you use section headers. These are a single line of text (one or more words) with adornment: an underline alone, or an underline and an overline together, in dashes "-----", equals "======", tildes "~~~~~~" or any of the non-alphanumeric characters = - ` : ' " ~ ^ _ * + # < > that you feel comfortable with. An underline-only adornment is distinct from an overline-and-underline adornment using the same character. The underline/overline must be at least as long as the title text. Be consistent, since all sections marked with the same adornment style are deemed to be at the same level:

Chapter 1 Title

Section 1.1 Title

Subsection 1.1.1 Title

Section 1.2 Title

Chapter 2 Title

This results in the following structure, illustrated by simplified pseudo-XML:

        Chapter 1 Title
            Section 1.1 Title
                Subsection 1.1.1 Title
            Section 1.2 Title
        Chapter 2 Title

(Pseudo-XML uses indentation for nesting and has no end-tags. It's not possible to show actual processed output, as in the other examples, because sections cannot exist inside block quotes. For a concrete example, compare the section structure of this document's source text and processed output.)

Note that section headers are available as link targets, just using their name. To link to the Lists heading, I write "Lists_". If the heading has a space in it like text styles, we need to quote the heading "`text styles`_".

Document Title / Subtitle

The title of the whole document is distinct from section titles and may be formatted somewhat differently (e.g. the HTML writer by default shows it as a centered heading).

To indicate the document title in reStructuredText, use a unique adornment style at the beginning of the document. To indicate the document subtitle, use another unique adornment style immediately after the document title. For example:

 Document Title

Section Title


Note that "Document Title" and "Section Title" above both use equals signs, but are distict and unrelated styles. The text of overline-and-underlined titles (but not underlined-only) may be inset for aesthetics.



To include an image in your document, you use the the image directive. For example:

.. image:: /images/rest/nikola.png

results in:


The /images/rest/nikola.png part indicates the filename of the image you wish to appear in the document. There's no restriction placed on the image (format, size etc). If the image is to appear in HTML and you wish to supply additional information, you may:

.. image:: /images/rest/nikola.png
   :height: 100
   :width: 200
   :scale: 50
   :alt: alternate text

See the full image directive documentation for more info.

What Next?

This primer introduces the most common features of reStructuredText, but there are a lot more to explore. The Quick reStructuredText user reference is a good place to go next. For complete details, the reStructuredText Markup Specification is the place to go [1].

Users who have questions or need assistance with Docutils or reStructuredText should post a message to the Docutils-users mailing list.

[1] If that relative link doesn't work, try the master document:

A reStructuredText Reference

Quick reStructuredText

Copyright: This document has been placed in the public domain.

The full details of the markup may be found on the reStructuredText page. This document is just intended as a reminder.

Links that look like "(details)" point into the HTML version of the full reStructuredText specification document. These are relative links; if they don't work, please use the master "Quick reStructuredText" document.

Inline Markup


Inline markup allows words and phrases within text to have character styles (like italics and boldface) and functionality (like hyperlinks).

Plain text Typical result Notes
*emphasis* emphasis Normally rendered as italics.
**strong emphasis** strong emphasis Normally rendered as boldface.
`interpreted text` (see note at right) The rendering and meaning of interpreted text is domain- or application-dependent. It can be used for things like index entries or explicit descriptive markup (like program identifiers).
``inline literal`` inline literal Normally rendered as monospaced text. Spaces should be preserved, but line breaks will not be.
reference_ reference A simple, one-word hyperlink reference. See Hyperlink Targets.
`phrase reference`_ phrase reference A hyperlink reference with spaces or punctuation needs to be quoted with backquotes. See Hyperlink Targets.
anonymous__ anonymous With two underscores instead of one, both simple and phrase references may be anonymous (the reference text is not repeated at the target). See Hyperlink Targets.
_`inline internal target` inline internal target A crossreference target within text. See Hyperlink Targets.
|substitution reference| (see note at right) The result is substituted in from the substitution definition. It could be text, an image, a hyperlink, or a combination of these and others.
footnote reference [1]_ footnote reference 1 See Footnotes.
citation reference [CIT2002]_ citation reference [CIT2002] See Citations. A standalone hyperlink.

Asterisk, backquote, vertical bar, and underscore are inline delimiter characters. Asterisk, backquote, and vertical bar act like quote marks; matching characters surround the marked-up word or phrase, whitespace or other quoting is required outside them, and there can't be whitespace just inside them. If you want to use inline delimiter characters literally, escape (with backslash) or quote them (with double backquotes; i.e. use inline literals).

In detail, the reStructuredText specification says that in inline markup, the following rules apply to start-strings and end-strings (inline markup delimiters):

  1. The start-string must start a text block or be immediately preceded by whitespace or any of  ' " ( [ { or <.
  2. The start-string must be immediately followed by non-whitespace.
  3. The end-string must be immediately preceded by non-whitespace.
  4. The end-string must end a text block (end of document or followed by a blank line) or be immediately followed by whitespace or any of ' " . , : ; ! ? - ) ] } / \ or >.
  5. If a start-string is immediately preceded by one of  ' " ( [ { or <, it must not be immediately followed by the corresponding character from  ' " ) ] } or >.
  6. An end-string must be separated by at least one character from the start-string.
  7. An unescaped backslash preceding a start-string or end-string will disable markup recognition, except for the end-string of inline literals.

Also remember that inline markup may not be nested (well, except that inline literals can contain any of the other inline markup delimiter characters, but that doesn't count because nothing is processed).

Escaping with Backslashes


reStructuredText uses backslashes ("\") to override the special meaning given to markup characters and get the literal characters themselves. To get a literal backslash, use an escaped backslash ("\\"). For example:

Raw reStructuredText Typical result
*escape* ``with`` "\" escape with ""
\*escape* \``with`` "\\" *escape* ``with`` "\"

In Python strings it will, of course, be necessary to escape any backslash characters so that they actually reach reStructuredText. The simplest way to do this is to use raw strings:

Python string Typical result
r"""\*escape* \`with` "\\"""" *escape* `with` "\"
 """\\*escape* \\`with` "\\\\"""" *escape* `with` "\"
 """\*escape* \`with` "\\"""" escape with ""

Section Structure


Plain text Typical result
Titles are underlined (or over-
and underlined) with a printing
nonalphanumeric 7-bit ASCII
character. Recommended choices
are "``= - ` : ' " ~ ^ _ * + # < >``".
The underline/overline must be at
least as long as the title text.

A lone top-level (sub)section
is lifted up to be the document's


Titles are underlined (or over- and underlined) with a printing nonalphanumeric 7-bit ASCII character. Recommended choices are "= - ` : ' " ~ ^ _ * + # < >". The underline/overline must be at least as long as the title text.

A lone top-level (sub)section is lifted up to be the document's (sub)title.



Plain text Typical result

This is a paragraph.

Paragraphs line up at their left
edges, and are normally separated
by blank lines.

This is a paragraph.

Paragraphs line up at their left edges, and are normally separated by blank lines.

Bullet Lists


Plain text Typical result
Bullet lists:

- This is item 1
- This is item 2

- Bullets are "-", "*" or "+".
  Continuing text must be aligned
  after the bullet and whitespace.

Note that a blank line is required
before the first item and after the
last, but is optional between items.

Bullet lists:
  • This is item 1
  • This is item 2
  • Bullets are "-", "*" or "+". Continuing text must be aligned after the bullet and whitespace.

Note that a blank line is required before the first item and after the last, but is optional between items.

Enumerated Lists


Plain text Typical result
Enumerated lists:

3. This is the first item
4. This is the second item
5. Enumerators are arabic numbers,
   single letters, or roman numerals
6. List items should be sequentially
   numbered, but need not start at 1
   (although not all formatters will
   honour the first index).
#. This item is auto-enumerated

Enumerated lists:
  1. This is the first item
  2. This is the second item
  3. Enumerators are arabic numbers, single letters, or roman numerals
  4. List items should be sequentially numbered, but need not start at 1 (although not all formatters will honour the first index).
  5. This item is auto-enumerated

Definition Lists


Plain text Typical result
Definition lists:

  Definition lists associate a term with
  a definition.

  The term is a one-line phrase, and the
  definition is one or more paragraphs or
  body elements, indented relative to the
  term. Blank lines are not allowed
  between term and definition.
Definition lists:
Definition lists associate a term with a definition.
The term is a one-line phrase, and the definition is one or more paragraphs or body elements, indented relative to the term. Blank lines are not allowed between term and definition.

Field Lists


Plain text Typical result
    Tony J. (Tibs) Ibbs,
    David Goodger

    (and sundry other good-natured folks)

:Version: 1.0 of 2001/08/08
:Dedication: To my father.

Authors: Tony J. (Tibs) Ibbs, David Goodger
(and sundry other good-natured folks)
Version: 1.0 of 2001/08/08
Dedication: To my father.

Field lists are used as part of an extension syntax, such as options for directives, or database-like records meant for further processing. Field lists may also be used as generic two-column table constructs in documents.

Option Lists


Plain text Typical result

-a            command-line option "a"
-b file       options can have arguments
              and long descriptions
--long        options can be long also
--input=file  long options can also have
/V            DOS/VMS-style options too

-a command-line option "a"
-b file options can have arguments and long descriptions
--long options can be long also
--input=file long options can also have arguments
/V DOS/VMS-style options too

There must be at least two spaces between the option and the description.

Literal Blocks


Plain text Typical result
A paragraph containing only two colons
indicates that the following indented
or quoted text is a literal block.


  Whitespace, newlines, blank lines, and
  all kinds of markup (like *this* or
  \this) is preserved by literal blocks.

  The paragraph containing only '::'
  will be omitted from the result.

The ``::`` may be tacked onto the very
end of any paragraph. The ``::`` will be
omitted if it is preceded by whitespace.
The ``::`` will be converted to a single
colon if preceded by text, like this::

  It's very convenient to use this form.

Literal blocks end when text returns to
the preceding paragraph's indentation.
This means that something like this
is possible::

      We start here
    and continue here
  and end here.

Per-line quoting can also be used on
unindented literal blocks::

> Useful for quotes from email and
> for Haskell literate programming.

A paragraph containing only two colons indicates that the following indented or quoted text is a literal block.

Whitespace, newlines, blank lines, and
all kinds of markup (like *this* or
\this) is preserved by literal blocks.

The paragraph containing only '::'
will be omitted from the result.

The :: may be tacked onto the very end of any paragraph. The :: will be omitted if it is preceded by whitespace. The :: will be converted to a single colon if preceded by text, like this:

It's very convenient to use this form.

Literal blocks end when text returns to the preceding paragraph's indentation. This means that something like this is possible:

    We start here
    and continue here
and end here.

Per-line quoting can also be used on unindented literal blocks:

> Useful for quotes from email and
> for Haskell literate programming.

Line Blocks


Plain text Typical result
| Line blocks are useful for addresses,
| verse, and adornment-free lists.
| Each new line begins with a
| vertical bar ("|").
|     Line breaks and initial indents
|     are preserved.
| Continuation lines are wrapped
  portions of long lines; they begin
  with spaces in place of vertical bars.
Line blocks are useful for addresses,
verse, and adornment-free lists.

Each new line begins with a
vertical bar ("|").
Line breaks and initial indents
are preserved.
Continuation lines are wrapped portions of long lines; they begin with spaces in place of vertical bars.

Block Quotes


Plain text Typical result
Block quotes are just:

    Indented paragraphs,

        and they may nest.

Block quotes are just:

Indented paragraphs,

and they may nest.

Use empty comments to separate indentation contexts, such as block quotes and directive contents.

Doctest Blocks


Plain text Typical result

Doctest blocks are interactive
Python sessions. They begin with
"``>>>``" and end with a blank line.

>>> print "This is a doctest block."
This is a doctest block.

Doctest blocks are interactive Python sessions. They begin with ">>>" and end with a blank line.

>>> print "This is a doctest block."
This is a doctest block.

"The doctest module searches a module's docstrings for text that looks like an interactive Python session, then executes all such sessions to verify they still work exactly as shown." (From the doctest docs.)



There are two syntaxes for tables in reStructuredText. Grid tables are complete but cumbersome to create. Simple tables are easy to create but limited (no row spans, etc.).

Plain text Typical result

Grid table:

| Header 1   | Header 2   | Header 3  |
| body row 1 | column 2   | column 3  |
| body row 2 | Cells may span columns.|
| body row 3 | Cells may  | - Cells   |
+------------+ span rows. | - contain |
| body row 4 |            | - blocks. |

Grid table:

Header 1 Header 2 Header 3
body row 1 column 2 column 3
body row 2 Cells may span columns.
body row 3 Cells may
span rows.
  • Cells
  • contain
  • blocks.
body row 4

Simple table:

=====  =====  ======
   Inputs     Output
------------  ------
  A      B    A or B
=====  =====  ======
False  False  False
True   False  True
False  True   True
True   True   True
=====  =====  ======

Simple table:

Inputs Output
A B A or B
False False False
True False True
False True True
True True True



Plain text Typical result

A transition marker is a horizontal line
of 4 or more repeated punctuation


A transition should not begin or end a
section or document, nor should two
transitions be immediately adjacent.

A transition marker is a horizontal line of 4 or more repeated punctuation characters.

A transition should not begin or end a section or document, nor should two transitions be immediately adjacent.

Transitions are commonly seen in novels and short fiction, as a gap spanning one or more lines, marking text divisions or signaling changes in subject, time, point of view, or emphasis.

Explicit Markup

Explicit markup blocks are used for constructs which float (footnotes), have no direct paper-document representation (hyperlink targets, comments), or require specialized processing (directives). They all begin with two periods and whitespace, the "explicit markup start".



Plain text Typical result
Footnote references, like [5]_.
Note that footnotes may get
rearranged, e.g., to the bottom of
the "page".

.. [5] A numerical footnote. Note
   there's no colon after the ``]``.

Footnote references, like 5. Note that footnotes may get rearranged, e.g., to the bottom of the "page".

[5] A numerical footnote. Note there's no colon after the ].
Autonumbered footnotes are
possible, like using [#]_ and [#]_.

.. [#] This is the first one.
.. [#] This is the second one.

They may be assigned 'autonumber
labels' - for instance,
[#fourth]_ and [#third]_.

.. [#third] a.k.a. third_

.. [#fourth] a.k.a. fourth_

Autonumbered footnotes are possible, like using 1 and 2.

They may be assigned 'autonumber labels' - for instance, 4 and 3.

[1] This is the first one.
[2] This is the second one.
[3] a.k.a. third
[4] a.k.a. fourth
Auto-symbol footnotes are also
possible, like this: [*]_ and [*]_.

.. [*] This is the first one.
.. [*] This is the second one.

Auto-symbol footnotes are also possible, like this: * and .

[*] This is the first symbol footnote
[†] This is the second one.

The numbering of auto-numbered footnotes is determined by the order of the footnotes, not of the references. For auto-numbered footnote references without autonumber labels ("[#]_"), the references and footnotes must be in the same relative order. Similarly for auto-symbol footnotes ("[*]_").



Plain text Typical result
Citation references, like [CIT2002]_.
Note that citations may get
rearranged, e.g., to the bottom of
the "page".

.. [CIT2002] A citation
   (as often used in journals).

Citation labels contain alphanumerics,
underlines, hyphens and fullstops.
Case is not significant.

Given a citation like [this]_, one
can also refer to it like this_.

.. [this] here.

Citation references, like [CIT2002]. Note that citations may get rearranged, e.g., to the bottom of the "page".

Citation labels contain alphanumerics, underlines, hyphens and fullstops. Case is not significant.

Given a citation like [this], one can also refer to it like this.

[CIT2002] A citation (as often used in journals).
[this] here.

Hyperlink Targets


External Hyperlink Targets

Plain text Typical result
External hyperlinks, like Python_.

.. _Python:

Fold-in form
External hyperlinks, like Python.
Call-out form
External hyperlinks, like Python.


"Fold-in" is the representation typically used in HTML documents (think of the indirect hyperlink being "folded in" like ingredients into a cake), and "call-out" is more suitable for printed documents, where the link needs to be presented explicitly, for example as a footnote. You can force usage of the call-out form by using the "target-notes" directive.

reStructuredText also provides for embedded URIs (details), a convenience at the expense of readability. A hyperlink reference may directly embed a target URI inline, within angle brackets. The following is exactly equivalent to the example above:

Plain text Typical result
External hyperlinks, like `Python
External hyperlinks, like Python.
Internal Hyperlink Targets

Plain text Typical result
Internal crossreferences, like example_.

.. _example:

This is an example crossreference target.

Fold-in form
Internal crossreferences, like example

This is an example crossreference target.

Call-out form
Internal crossreferences, like example

This is an example crossreference target.

Indirect Hyperlink Targets


Plain text Typical result
Python_ is `my favourite
programming language`__.

.. _Python:

__ Python_

Python is my favourite programming language.

The second hyperlink target (the line beginning with "__") is both an indirect hyperlink target (indirectly pointing at the Python website via the "Python_" reference) and an anonymous hyperlink target. In the text, a double-underscore suffix is used to indicate an anonymous hyperlink reference. In an anonymous hyperlink target, the reference text is not repeated. This is useful for references with long text or throw-away references, but the target should be kept close to the reference to prevent them going out of sync.

Implicit Hyperlink Targets


Section titles, footnotes, and citations automatically generate hyperlink targets (the title text or footnote/citation label is used as the hyperlink name).

Plain text Typical result
Titles are targets, too
Implict references, like `Titles are
targets, too`_.
Titles are targets, too

Implict references, like Titles are targets, too.



Directives are a general-purpose extension mechanism, a way of adding support for new constructs without adding new syntax. For a description of all standard directives, see reStructuredText Directives.

Plain text Typical result
For instance:

.. image:: images/nikola.png

For instance:


Substitution References and Definitions


Substitutions are like inline directives, allowing graphics and arbitrary constructs within text.

Plain text Typical result
The |Nikola| static site generator is named after Nikola Tesla.

.. |Nikola| image:: nikola.png

The Nikola static site generator is named after Nikola Tesla.



Any text which begins with an explicit markup start but doesn't use the syntax of any of the constructs above, is a comment.

Plain text Typical result
.. This text will not be shown
   (but, for instance, in HTML might be
   rendered as an HTML comment)
An "empty comment" does not
consume following blocks.
(An empty comment is ".." with
blank lines before and after.)


        So this block is not "lost",
        despite its indentation.

An "empty comment" does not consume following blocks. (An empty comment is ".." with blank lines before and after.)
So this block is not "lost", despite its indentation.

Getting Help

Users who have questions or need assistance with Docutils or reStructuredText should post a message to the Docutils-Users mailing list. The Docutils project web site has more information.

Authors: Tibs ( and David Goodger (


This site is built with the uikit framework and the nikola static blog/site generator and its associated lanyon theme. I particularly enjoy using nikola and find the lanyon theme to be clean, simple, and easy to read.

Read more…