diff options
author | Valerio Virgillito | 2012-02-14 11:07:21 -0800 |
---|---|---|
committer | Valerio Virgillito | 2012-02-14 11:07:21 -0800 |
commit | f060190a3bffd9a16718f2ce0499699103d46372 (patch) | |
tree | a308fe7eacec2156c8212dff0892a3de925d5f9a /imports/codemirror/mode/rst/index.html | |
parent | f766cc203f30ea43ae8b83cf4b65d45cc4435ee9 (diff) | |
parent | 33bc9d62b8e6694500bf14d5b18187bd99a520a3 (diff) | |
download | ninja-f060190a3bffd9a16718f2ce0499699103d46372.tar.gz |
Merge branch 'FileIO' of https://github.com/joseeight/ninja-internal into integration
Diffstat (limited to 'imports/codemirror/mode/rst/index.html')
-rwxr-xr-x | imports/codemirror/mode/rst/index.html | 525 |
1 files changed, 525 insertions, 0 deletions
diff --git a/imports/codemirror/mode/rst/index.html b/imports/codemirror/mode/rst/index.html new file mode 100755 index 00000000..fd75a284 --- /dev/null +++ b/imports/codemirror/mode/rst/index.html | |||
@@ -0,0 +1,525 @@ | |||
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 | <http://docutils.sourceforge.net/rst.html>`_. 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 <paragraphs>`) 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 <bullet-lists>`) 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 <definition-lists>`) 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 <block-quotes>`) are created by just indenting | ||
129 | them more than the surrounding paragraphs. | ||
130 | |||
131 | Line blocks (:duref:`ref <line-blocks>`) 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 <field-lists>`) | ||
140 | * option lists (:duref:`ref <option-lists>`) | ||
141 | * quoted literal blocks (:duref:`ref <quoted-literal-blocks>`) | ||
142 | * doctest blocks (:duref:`ref <doctest-blocks>`) | ||
143 | |||
144 | |||
145 | Source Code | ||
146 | ----------- | ||
147 | |||
148 | Literal code blocks (:duref:`ref <literal-blocks>`) 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 | <grid-tables>`), 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 <simple-tables>`) 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 <http://example.com/>`_`` 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 | <hyperlink-targets>`), 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 |