本章是对 reStructuredText (reST) 相关概念和语法的一个简短介绍,来帮助编写者更有效的编写reST文档。由于reST本身设计上就是一个非常简单的标记语言,所以并不需要很大的篇幅。
See also
段落是reST文档中最基本的部分。段落是被一行或多行空格分隔的文本块。和Python一样, reST中缩进格式是有意义的,同一段落的每一行必须按同一缩进格式左对齐。
标准的reST的行内标记(inline markup)非常简单:使用
单星号: *text* 来强调(斜体),
双星号: **text** 来更一步强调(粗体), and
反引号: ``text`` 来做代码的示例。
如果星号和反引号同时出现并可能混淆时就可以使用反斜杠来转义。
注意下面这些标记限制:
不能嵌套使用,
内容的前后都不能包含空格: * text* 是错误的,
必须和周围的文本用non-word字符分隔开来。使用反斜杠来转义空格字符: thisis\ *one*\ word.
这些限制可能会在docutils的新版本中取消。
reST同样允许使用自定义的 ‘“interpreted text roles”’,这表示包含的文本将用特定的方式解析。 Sphinx使用这个机制来提供相关标记和交叉索引定义。通用的语法是 :rolename:`content` 。
List markup is natural: just place an asterisk at the start of a paragraph and indent properly. The same goes for numbered lists; they can also be autonumbered using a # sign:
* This is a bulleted list.
* It has two items, the second
item uses two lines.
1. This is a numbered list.
2. It has two items too.
#. This is a numbered list.
#. It has two items too.
Note that Sphinx disables the use of enumerated lists introduced by alphabetic or roman numerals, such as :
A. First item
B. Second item
Nested lists are possible, but be aware that they must be separated from the parent list items by blank lines:
* this is
* a list
* with a nested list
* and some subitems
* and here the parent list continues
Definition lists are created as follows:
term (up to a line of text)
Definition of the term, which must be indented
and can even consist of multiple paragraphs
next term
Description.
Paragraphs are quoted by just indenting them more than the surrounding paragraphs.
Literal code blocks are introduced by ending a paragraph with the special marker ::. The literal block must be indented, to be able to include blank lines:
This is a normal text paragraph. The next paragraph is a code sample:
::
It is not processed in any way, except
that the indentation is removed.
It can span multiple lines.
This is a normal text paragraph again.
The handling of the :: marker is smart:
If it occurs as a paragraph of its own, that paragraph is completely left out of the document.
If it is preceded by whitespace, the marker is removed.
If it is preceded by non-whitespace, the marker is replaced by a single colon.
That way, the second sentence in the above example’s first paragraph would be rendered as “The next paragraph is a code sample:”.
Use `Link text <http://target>`_ for inline web links. If the link text should be the web address, you don’t need special markup at all, the parser finds links and mail addresses in ordinary text.
Internal linking is done via a special reST role, see the section on specific markup, Cross-linking markup.
Section headers are created by underlining (and optionally overlining) the section title with a punctuation character, at least as long as the text:
=================
This is a heading
=================
Normally, there are no heading levels assigned to certain characters as the structure is determined from the succession of headings. However, for the Python documentation, we use this convention:
# with overline, for parts
* with overline, for chapters
=, for sections
-, for subsections
^, for subsubsections
", for paragraphs
“Explicit markup” is used in reST for most constructs that need special handling, such as footnotes, specially-highlighted paragraphs, comments, and generic directives.
An explicit markup block begins with a line starting with .. followed by whitespace and is terminated by the next paragraph at the same level of indentation. (There needs to be a blank line between explicit markup and normal paragraphs. This may all sound a bit complicated, but it is intuitive enough when you write it.)
A directive is a generic block of explicit markup. Besides roles, it is one of the extension mechanisms of reST, and Sphinx makes heavy use of it.
Basically, a directive consists of a name, arguments, options and content. (Keep this terminology in mind, it is used in the next chapter describing custom directives.) Looking at this example, :
.. function:: foo(x)
foo(y, z)
:bar: no
Return a line of text input from the user.
function is the directive name. It is given two arguments here, the remainder of the first line and the second line, as well as one option bar (as you can see, options are given in the lines immediately following the arguments and indicated by the colons).
The directive content follows after a blank line and is indented relative to the directive start.
For footnotes, use [#]_ to mark the footnote location, and add the footnote body at the bottom of the document after a “Footnotes” rubric heading, like so:
Lorem ipsum [#]_ dolor sit amet ... [#]_
.. rubric:: Footnotes
.. [#] Text of the first footnote.
.. [#] Text of the second footnote.
You can also explicitly number the footnotes for better context.
Every explicit markup block which isn’t a valid markup construct (like the footnotes above) is regarded as a comment.
Since the easiest way to include special characters like em dashes or copyright signs in reST is to directly write them as Unicode characters, one has to specify an encoding:
All Python documentation source files must be in UTF-8 encoding, and the HTML documents written from them will be in that encoding as well.
There are some problems one commonly runs into while authoring reST documents:
Separation of inline markup: As said above, inline markup spans must be separated from the surrounding text by non-word characters, you have to use an escaped space to get around that.
关于本评注系统
本站使用上下文关联的评注系统来收集反馈信息。不同于一般对整章做评注的做法, 我们允许你对每一个独立的“文本块”做评注。一个“文本块”看起来是这样的:
一个“文本块”是一个段落,一个列表项,一段代码,或者其他一小段内容。 你选中它会高亮度显示:
要对文本块做评注,你只需要点击它旁边的标识块:
我们会仔细阅读每个评论,如果可能的话我们也会把评注考虑到未来的版本中去:
如果你愿意你的评注被采用,请确保留下你的全名 (注意不是昵称或简称)
Many, many thanks to Jack Slocum; the inspiration and much of the code for the comment system comes from Jack's blog, and this site couldn't have been built without his wonderful
YAHOO.extlibrary. Thanks also to Yahoo for YUI itself.