Project

General

Profile

Statistics
| Revision:

root / trunk / scripts / codemirror / mode / rst / index.html @ 216

History | View | Annotate | Download (17.2 KB)

1
<!doctype html>
2
<html>
3
  <head>
4
    <title>CodeMirror: reStructuredText mode</title>
5
    <link rel="stylesheet" href="../../lib/codemirror.css">
6
    <script src="../../lib/codemirror.js"></script>
7
    <script src="rst.js"></script>
8
    <style type="text/css">.CodeMirror {border-top: 1px solid black; border-bottom: 1px solid black;}</style>
9
    <link rel="stylesheet" href="../../doc/docs.css">
10
  </head>
11
  <body>
12
    <h1>CodeMirror: reStructuredText mode</h1>
13

    
14
<form><textarea id="code" name="code">
15
.. This is an excerpt from Sphinx documentation: http://sphinx.pocoo.org/_sources/rest.txt
16

    
17
.. highlightlang:: rest
18

    
19
.. _rst-primer:
20

    
21
reStructuredText Primer
22
=======================
23

    
24
This section is a brief introduction to reStructuredText (reST) concepts and
25
syntax, intended to provide authors with enough information to author documents
26
productively.  Since reST was designed to be a simple, unobtrusive markup
27
language, this will not take too long.
28

    
29
.. seealso::
30

    
31
   The authoritative `reStructuredText User Documentation
32
   &lt;http://docutils.sourceforge.net/rst.html&gt;`_.  The "ref" links in this
33
   document link to the description of the individual constructs in the reST
34
   reference.
35

    
36

    
37
Paragraphs
38
----------
39

    
40
The paragraph (:duref:`ref &lt;paragraphs&gt;`) is the most basic block in a reST
41
document.  Paragraphs are simply chunks of text separated by one or more blank
42
lines.  As in Python, indentation is significant in reST, so all lines of the
43
same paragraph must be left-aligned to the same level of indentation.
44

    
45

    
46
.. _inlinemarkup:
47

    
48
Inline markup
49
-------------
50

    
51
The standard reST inline markup is quite simple: use
52

    
53
* one asterisk: ``*text*`` for emphasis (italics),
54
* two asterisks: ``**text**`` for strong emphasis (boldface), and
55
* backquotes: ````text```` for code samples.
56

    
57
If asterisks or backquotes appear in running text and could be confused with
58
inline markup delimiters, they have to be escaped with a backslash.
59

    
60
Be aware of some restrictions of this markup:
61

    
62
* it may not be nested,
63
* content may not start or end with whitespace: ``* text*`` is wrong,
64
* it must be separated from surrounding text by non-word characters.  Use a
65
  backslash escaped space to work around that: ``thisis\ *one*\ word``.
66

    
67
These restrictions may be lifted in future versions of the docutils.
68

    
69
reST also allows for custom "interpreted text roles"', which signify that the
70
enclosed text should be interpreted in a specific way.  Sphinx uses this to
71
provide semantic markup and cross-referencing of identifiers, as described in
72
the appropriate section.  The general syntax is ``:rolename:`content```.
73

    
74
Standard reST provides the following roles:
75

    
76
* :durole:`emphasis` -- alternate spelling for ``*emphasis*``
77
* :durole:`strong` -- alternate spelling for ``**strong**``
78
* :durole:`literal` -- alternate spelling for ````literal````
79
* :durole:`subscript` -- subscript text
80
* :durole:`superscript` -- superscript text
81
* :durole:`title-reference` -- for titles of books, periodicals, and other
82
  materials
83

    
84
See :ref:`inline-markup` for roles added by Sphinx.
85

    
86

    
87
Lists and Quote-like blocks
88
---------------------------
89

    
90
List markup (:duref:`ref &lt;bullet-lists&gt;`) is natural: just place an asterisk at
91
the start of a paragraph and indent properly.  The same goes for numbered lists;
92
they can also be autonumbered using a ``#`` sign::
93

    
94
   * This is a bulleted list.
95
   * It has two items, the second
96
     item uses two lines.
97

    
98
   1. This is a numbered list.
99
   2. It has two items too.
100

    
101
   #. This is a numbered list.
102
   #. It has two items too.
103

    
104

    
105
Nested lists are possible, but be aware that they must be separated from the
106
parent list items by blank lines::
107

    
108
   * this is
109
   * a list
110

    
111
     * with a nested list
112
     * and some subitems
113

    
114
   * and here the parent list continues
115

    
116
Definition lists (:duref:`ref &lt;definition-lists&gt;`) are created as follows::
117

    
118
   term (up to a line of text)
119
      Definition of the term, which must be indented
120

    
121
      and can even consist of multiple paragraphs
122

    
123
   next term
124
      Description.
125

    
126
Note that the term cannot have more than one line of text.
127

    
128
Quoted paragraphs (:duref:`ref &lt;block-quotes&gt;`) are created by just indenting
129
them more than the surrounding paragraphs.
130

    
131
Line blocks (:duref:`ref &lt;line-blocks&gt;`) are a way of preserving line breaks::
132

    
133
   | These lines are
134
   | broken exactly like in
135
   | the source file.
136

    
137
There are also several more special blocks available:
138

    
139
* field lists (:duref:`ref &lt;field-lists&gt;`)
140
* option lists (:duref:`ref &lt;option-lists&gt;`)
141
* quoted literal blocks (:duref:`ref &lt;quoted-literal-blocks&gt;`)
142
* doctest blocks (:duref:`ref &lt;doctest-blocks&gt;`)
143

    
144

    
145
Source Code
146
-----------
147

    
148
Literal code blocks (:duref:`ref &lt;literal-blocks&gt;`) are introduced by ending a
149
paragraph with the special marker ``::``.  The literal block must be indented
150
(and, like all paragraphs, separated from the surrounding ones by blank lines)::
151

    
152
   This is a normal text paragraph. The next paragraph is a code sample::
153

    
154
      It is not processed in any way, except
155
      that the indentation is removed.
156

    
157
      It can span multiple lines.
158

    
159
   This is a normal text paragraph again.
160

    
161
The handling of the ``::`` marker is smart:
162

    
163
* If it occurs as a paragraph of its own, that paragraph is completely left
164
  out of the document.
165
* If it is preceded by whitespace, the marker is removed.
166
* If it is preceded by non-whitespace, the marker is replaced by a single
167
  colon.
168

    
169
That way, the second sentence in the above example's first paragraph would be
170
rendered as "The next paragraph is a code sample:".
171

    
172

    
173
.. _rst-tables:
174

    
175
Tables
176
------
177

    
178
Two forms of tables are supported.  For *grid tables* (:duref:`ref
179
&lt;grid-tables&gt;`), you have to "paint" the cell grid yourself.  They look like
180
this::
181

    
182
   +------------------------+------------+----------+----------+
183
   | Header row, column 1   | Header 2   | Header 3 | Header 4 |
184
   | (header rows optional) |            |          |          |
185
   +========================+============+==========+==========+
186
   | body row 1, column 1   | column 2   | column 3 | column 4 |
187
   +------------------------+------------+----------+----------+
188
   | body row 2             | ...        | ...      |          |
189
   +------------------------+------------+----------+----------+
190

    
191
*Simple tables* (:duref:`ref &lt;simple-tables&gt;`) are easier to write, but
192
limited: they must contain more than one row, and the first column cannot
193
contain multiple lines.  They look like this::
194

    
195
   =====  =====  =======
196
   A      B      A and B
197
   =====  =====  =======
198
   False  False  False
199
   True   False  False
200
   False  True   False
201
   True   True   True
202
   =====  =====  =======
203

    
204

    
205
Hyperlinks
206
----------
207

    
208
External links
209
^^^^^^^^^^^^^^
210

    
211
Use ```Link text &lt;http://example.com/&gt;`_`` for inline web links.  If the link
212
text should be the web address, you don't need special markup at all, the parser
213
finds links and mail addresses in ordinary text.
214

    
215
You can also separate the link and the target definition (:duref:`ref
216
&lt;hyperlink-targets&gt;`), like this::
217

    
218
   This is a paragraph that contains `a link`_.
219

    
220
   .. _a link: http://example.com/
221

    
222

    
223
Internal links
224
^^^^^^^^^^^^^^
225

    
226
Internal linking is done via a special reST role provided by Sphinx, see the
227
section on specific markup, :ref:`ref-role`.
228

    
229

    
230
Sections
231
--------
232

    
233
Section headers (:duref:`ref &lt;sections&gt;`) are created by underlining (and
234
optionally overlining) the section title with a punctuation character, at least
235
as long as the text::
236

    
237
   =================
238
   This is a heading
239
   =================
240

    
241
Normally, there are no heading levels assigned to certain characters as the
242
structure is determined from the succession of headings.  However, for the
243
Python documentation, this convention is used which you may follow:
244

    
245
* ``#`` with overline, for parts
246
* ``*`` with overline, for chapters
247
* ``=``, for sections
248
* ``-``, for subsections
249
* ``^``, for subsubsections
250
* ``"``, for paragraphs
251

    
252
Of course, you are free to use your own marker characters (see the reST
253
documentation), and use a deeper nesting level, but keep in mind that most
254
target formats (HTML, LaTeX) have a limited supported nesting depth.
255

    
256

    
257
Explicit Markup
258
---------------
259

    
260
"Explicit markup" (:duref:`ref &lt;explicit-markup-blocks&gt;`) is used in reST for
261
most constructs that need special handling, such as footnotes,
262
specially-highlighted paragraphs, comments, and generic directives.
263

    
264
An explicit markup block begins with a line starting with ``..`` followed by
265
whitespace and is terminated by the next paragraph at the same level of
266
indentation.  (There needs to be a blank line between explicit markup and normal
267
paragraphs.  This may all sound a bit complicated, but it is intuitive enough
268
when you write it.)
269

    
270

    
271
.. _directives:
272

    
273
Directives
274
----------
275

    
276
A directive (:duref:`ref &lt;directives&gt;`) is a generic block of explicit markup.
277
Besides roles, it is one of the extension mechanisms of reST, and Sphinx makes
278
heavy use of it.
279

    
280
Docutils supports the following directives:
281

    
282
* Admonitions: :dudir:`attention`, :dudir:`caution`, :dudir:`danger`,
283
  :dudir:`error`, :dudir:`hint`, :dudir:`important`, :dudir:`note`,
284
  :dudir:`tip`, :dudir:`warning` and the generic :dudir:`admonition`.
285
  (Most themes style only "note" and "warning" specially.)
286

    
287
* Images:
288

    
289
  - :dudir:`image` (see also Images_ below)
290
  - :dudir:`figure` (an image with caption and optional legend)
291

    
292
* Additional body elements:
293

    
294
  - :dudir:`contents` (a local, i.e. for the current file only, table of
295
    contents)
296
  - :dudir:`container` (a container with a custom class, useful to generate an
297
    outer ``&lt;div&gt;`` in HTML)
298
  - :dudir:`rubric` (a heading without relation to the document sectioning)
299
  - :dudir:`topic`, :dudir:`sidebar` (special highlighted body elements)
300
  - :dudir:`parsed-literal` (literal block that supports inline markup)
301
  - :dudir:`epigraph` (a block quote with optional attribution line)
302
  - :dudir:`highlights`, :dudir:`pull-quote` (block quotes with their own
303
    class attribute)
304
  - :dudir:`compound` (a compound paragraph)
305

    
306
* Special tables:
307

    
308
  - :dudir:`table` (a table with title)
309
  - :dudir:`csv-table` (a table generated from comma-separated values)
310
  - :dudir:`list-table` (a table generated from a list of lists)
311

    
312
* Special directives:
313

    
314
  - :dudir:`raw` (include raw target-format markup)
315
  - :dudir:`include` (include reStructuredText from another file)
316
    -- in Sphinx, when given an absolute include file path, this directive takes
317
    it as relative to the source directory
318
  - :dudir:`class` (assign a class attribute to the next element) [1]_
319

    
320
* HTML specifics:
321

    
322
  - :dudir:`meta` (generation of HTML ``&lt;meta&gt;`` tags)
323
  - :dudir:`title` (override document title)
324

    
325
* Influencing markup:
326

    
327
  - :dudir:`default-role` (set a new default role)
328
  - :dudir:`role` (create a new role)
329

    
330
  Since these are only per-file, better use Sphinx' facilities for setting the
331
  :confval:`default_role`.
332

    
333
Do *not* use the directives :dudir:`sectnum`, :dudir:`header` and
334
:dudir:`footer`.
335

    
336
Directives added by Sphinx are described in :ref:`sphinxmarkup`.
337

    
338
Basically, a directive consists of a name, arguments, options and content. (Keep
339
this terminology in mind, it is used in the next chapter describing custom
340
directives.)  Looking at this example, ::
341

    
342
   .. function:: foo(x)
343
                 foo(y, z)
344
      :module: some.module.name
345

    
346
      Return a line of text input from the user.
347

    
348
``function`` is the directive name.  It is given two arguments here, the
349
remainder of the first line and the second line, as well as one option
350
``module`` (as you can see, options are given in the lines immediately following
351
the arguments and indicated by the colons).  Options must be indented to the
352
same level as the directive content.
353

    
354
The directive content follows after a blank line and is indented relative to the
355
directive start.
356

    
357

    
358
Images
359
------
360

    
361
reST supports an image directive (:dudir:`ref &lt;image&gt;`), used like so::
362

    
363
   .. image:: gnu.png
364
      (options)
365

    
366
When used within Sphinx, the file name given (here ``gnu.png``) must either be
367
relative to the source file, or absolute which means that they are relative to
368
the top source directory.  For example, the file ``sketch/spam.rst`` could refer
369
to the image ``images/spam.png`` as ``../images/spam.png`` or
370
``/images/spam.png``.
371

    
372
Sphinx will automatically copy image files over to a subdirectory of the output
373
directory on building (e.g. the ``_static`` directory for HTML output.)
374

    
375
Interpretation of image size options (``width`` and ``height``) is as follows:
376
if the size has no unit or the unit is pixels, the given size will only be
377
respected for output channels that support pixels (i.e. not in LaTeX output).
378
Other units (like ``pt`` for points) will be used for HTML and LaTeX output.
379

    
380
Sphinx extends the standard docutils behavior by allowing an asterisk for the
381
extension::
382

    
383
   .. image:: gnu.*
384

    
385
Sphinx then searches for all images matching the provided pattern and determines
386
their type.  Each builder then chooses the best image out of these candidates.
387
For instance, if the file name ``gnu.*`` was given and two files :file:`gnu.pdf`
388
and :file:`gnu.png` existed in the source tree, the LaTeX builder would choose
389
the former, while the HTML builder would prefer the latter.
390

    
391
.. versionchanged:: 0.4
392
   Added the support for file names ending in an asterisk.
393

    
394
.. versionchanged:: 0.6
395
   Image paths can now be absolute.
396

    
397

    
398
Footnotes
399
---------
400

    
401
For footnotes (:duref:`ref &lt;footnotes&gt;`), use ``[#name]_`` to mark the footnote
402
location, and add the footnote body at the bottom of the document after a
403
"Footnotes" rubric heading, like so::
404

    
405
   Lorem ipsum [#f1]_ dolor sit amet ... [#f2]_
406

    
407
   .. rubric:: Footnotes
408

    
409
   .. [#f1] Text of the first footnote.
410
   .. [#f2] Text of the second footnote.
411

    
412
You can also explicitly number the footnotes (``[1]_``) or use auto-numbered
413
footnotes without names (``[#]_``).
414

    
415

    
416
Citations
417
---------
418

    
419
Standard reST citations (:duref:`ref &lt;citations&gt;`) are supported, with the
420
additional feature that they are "global", i.e. all citations can be referenced
421
from all files.  Use them like so::
422

    
423
   Lorem ipsum [Ref]_ dolor sit amet.
424

    
425
   .. [Ref] Book or article reference, URL or whatever.
426

    
427
Citation usage is similar to footnote usage, but with a label that is not
428
numeric or begins with ``#``.
429

    
430

    
431
Substitutions
432
-------------
433

    
434
reST supports "substitutions" (:duref:`ref &lt;substitution-definitions&gt;`), which
435
are pieces of text and/or markup referred to in the text by ``|name|``.  They
436
are defined like footnotes with explicit markup blocks, like this::
437

    
438
   .. |name| replace:: replacement *text*
439

    
440
or this::
441

    
442
   .. |caution| image:: warning.png
443
                :alt: Warning!
444

    
445
See the :duref:`reST reference for substitutions &lt;substitution-definitions&gt;`
446
for details.
447

    
448
If you want to use some substitutions for all documents, put them into
449
:confval:`rst_prolog` or put them into a separate file and include it into all
450
documents you want to use them in, using the :rst:dir:`include` directive.  (Be
451
sure to give the include file a file name extension differing from that of other
452
source files, to avoid Sphinx finding it as a standalone document.)
453

    
454
Sphinx defines some default substitutions, see :ref:`default-substitutions`.
455

    
456

    
457
Comments
458
--------
459

    
460
Every explicit markup block which isn't a valid markup construct (like the
461
footnotes above) is regarded as a comment (:duref:`ref &lt;comments&gt;`).  For
462
example::
463

    
464
   .. This is a comment.
465

    
466
You can indent text after a comment start to form multiline comments::
467

    
468
   ..
469
      This whole indented block
470
      is a comment.
471

    
472
      Still in the comment.
473

    
474

    
475
Source encoding
476
---------------
477

    
478
Since the easiest way to include special characters like em dashes or copyright
479
signs in reST is to directly write them as Unicode characters, one has to
480
specify an encoding.  Sphinx assumes source files to be encoded in UTF-8 by
481
default; you can change this with the :confval:`source_encoding` config value.
482

    
483

    
484
Gotchas
485
-------
486

    
487
There are some problems one commonly runs into while authoring reST documents:
488

    
489
* **Separation of inline markup:** As said above, inline markup spans must be
490
  separated from the surrounding text by non-word characters, you have to use a
491
  backslash-escaped space to get around that.  See `the reference
492
  &lt;http://docutils.sf.net/docs/ref/rst/restructuredtext.html#inline-markup&gt;`_
493
  for the details.
494

    
495
* **No nested inline markup:** Something like ``*see :func:`foo`*`` is not
496
  possible.
497

    
498

    
499
.. rubric:: Footnotes
500

    
501
.. [1] When the default domain contains a :rst:dir:`class` directive, this directive
502
       will be shadowed.  Therefore, Sphinx re-exports it as :rst:dir:`rst-class`.
503
</textarea></form>
504

    
505
    <script>
506
      var editor = CodeMirror.fromTextArea(document.getElementById("code"), {
507
        lineNumbers: true,
508
      });
509
    </script>
510
    <p>The reStructuredText mode supports one configuration parameter:</p>
511
    <dl>
512
      <dt><code>verbatim (string)</code></dt>
513
      <dd>A name or MIME type of a mode that will be used for highlighting
514
      verbatim blocks. By default, reStructuredText mode uses uniform color
515
      for whole block of verbatim text if no mode is given.</dd>
516
    </dl>
517
    <p>If <code>python</code> mode is available,
518
    it will be used for highlighting blocks containing Python/IPython terminal
519
    sessions (blocks starting with <code>&gt;&gt;&gt;</code> (for Python) or
520
    <code>In [num]:</code> (for IPython).
521

    
522
    <p><strong>MIME types defined:</strong> <code>text/x-rst</code>.</p>
523
  </body>
524
</html>
525