diff options
author | Pierre Frisch | 2011-12-22 07:25:50 -0800 |
---|---|---|
committer | Valerio Virgillito | 2012-01-27 11:18:17 -0800 |
commit | b89a7ee8b956c96a1dcee995ea840feddc5d4b27 (patch) | |
tree | 0f3136ab0ecdbbbed6a83576581af0a53124d6f1 /js/codemirror/mode/rst/index.html | |
parent | 2401f05d1f4b94d45e4568b81fc73e67b969d980 (diff) | |
download | ninja-b89a7ee8b956c96a1dcee995ea840feddc5d4b27.tar.gz |
First commit of Ninja to ninja-internal
Signed-off-by: Valerio Virgillito <rmwh84@motorola.com>
Diffstat (limited to 'js/codemirror/mode/rst/index.html')
-rw-r--r-- | js/codemirror/mode/rst/index.html | 526 |
1 files changed, 526 insertions, 0 deletions
diff --git a/js/codemirror/mode/rst/index.html b/js/codemirror/mode/rst/index.html new file mode 100644 index 00000000..0831dff4 --- /dev/null +++ b/js/codemirror/mode/rst/index.html | |||
@@ -0,0 +1,526 @@ | |||
1 | <!doctype html> | ||
2 | <html> | ||
3 | <head> | ||
4 | <title>CodeMirror 2: 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 | <link rel="stylesheet" href="rst.css"> | ||
9 | <style type="text/css">.CodeMirror {border-top: 1px solid black; border-bottom: 1px solid black;}</style> | ||
10 | <link rel="stylesheet" href="../../css/docs.css"> | ||
11 | </head> | ||
12 | <body> | ||
13 | <h1>CodeMirror 2: reStructuredText mode</h1> | ||
14 | |||
15 | <form><textarea id="code" name="code"> | ||
16 | .. This is an excerpt from Sphinx documentation: http://sphinx.pocoo.org/_sources/rest.txt | ||
17 | |||
18 | .. highlightlang:: rest | ||
19 | |||
20 | .. _rst-primer: | ||
21 | |||
22 | reStructuredText Primer | ||
23 | ======================= | ||
24 | |||
25 | This section is a brief introduction to reStructuredText (reST) concepts and | ||
26 | syntax, intended to provide authors with enough information to author documents | ||
27 | productively. Since reST was designed to be a simple, unobtrusive markup | ||
28 | language, this will not take too long. | ||
29 | |||
30 | .. seealso:: | ||
31 | |||
32 | The authoritative `reStructuredText User Documentation | ||
33 | <http://docutils.sourceforge.net/rst.html>`_. The "ref" links in this | ||
34 | document link to the description of the individual constructs in the reST | ||
35 | reference. | ||
36 | |||
37 | |||
38 | Paragraphs | ||
39 | ---------- | ||
40 | |||
41 | The paragraph (:duref:`ref <paragraphs>`) is the most basic block in a reST | ||
42 | document. Paragraphs are simply chunks of text separated by one or more blank | ||
43 | lines. As in Python, indentation is significant in reST, so all lines of the | ||
44 | same paragraph must be left-aligned to the same level of indentation. | ||
45 | |||
46 | |||
47 | .. _inlinemarkup: | ||
48 | |||
49 | Inline markup | ||
50 | ------------- | ||
51 | |||
52 | The standard reST inline markup is quite simple: use | ||
53 | |||
54 | * one asterisk: ``*text*`` for emphasis (italics), | ||
55 | * two asterisks: ``**text**`` for strong emphasis (boldface), and | ||
56 | * backquotes: ````text```` for code samples. | ||
57 | |||
58 | If asterisks or backquotes appear in running text and could be confused with | ||
59 | inline markup delimiters, they have to be escaped with a backslash. | ||
60 | |||
61 | Be aware of some restrictions of this markup: | ||
62 | |||
63 | * it may not be nested, | ||
64 | * content may not start or end with whitespace: ``* text*`` is wrong, | ||
65 | * it must be separated from surrounding text by non-word characters. Use a | ||
66 | backslash escaped space to work around that: ``thisis\ *one*\ word``. | ||
67 | |||
68 | These restrictions may be lifted in future versions of the docutils. | ||
69 | |||
70 | reST also allows for custom "interpreted text roles"', which signify that the | ||
71 | enclosed text should be interpreted in a specific way. Sphinx uses this to | ||
72 | provide semantic markup and cross-referencing of identifiers, as described in | ||
73 | the appropriate section. The general syntax is ``:rolename:`content```. | ||
74 | |||
75 | Standard reST provides the following roles: | ||
76 | |||
77 | * :durole:`emphasis` -- alternate spelling for ``*emphasis*`` | ||
78 | * :durole:`strong` -- alternate spelling for ``**strong**`` | ||
79 | * :durole:`literal` -- alternate spelling for ````literal```` | ||
80 | * :durole:`subscript` -- subscript text | ||
81 | * :durole:`superscript` -- superscript text | ||
82 | * :durole:`title-reference` -- for titles of books, periodicals, and other | ||
83 | materials | ||
84 | |||
85 | See :ref:`inline-markup` for roles added by Sphinx. | ||
86 | |||
87 | |||
88 | Lists and Quote-like blocks | ||
89 | --------------------------- | ||
90 | |||
91 | List markup (:duref:`ref <bullet-lists>`) is natural: just place an asterisk at | ||
92 | the start of a paragraph and indent properly. The same goes for numbered lists; | ||
93 | they can also be autonumbered using a ``#`` sign:: | ||
94 | |||
95 | * This is a bulleted list. | ||
96 | * It has two items, the second | ||
97 | item uses two lines. | ||
98 | |||
99 | 1. This is a numbered list. | ||
100 | 2. It has two items too. | ||
101 | |||
102 | #. This is a numbered list. | ||
103 | #. It has two items too. | ||
104 | |||
105 | |||
106 | Nested lists are possible, but be aware that they must be separated from the | ||
107 | parent list items by blank lines:: | ||
108 | |||
109 | * this is | ||
110 | * a list | ||
111 | |||
112 | * with a nested list | ||
113 | * and some subitems | ||
114 | |||
115 | * and here the parent list continues | ||
116 | |||
117 | Definition lists (:duref:`ref <definition-lists>`) are created as follows:: | ||
118 | |||
119 | term (up to a line of text) | ||
120 | Definition of the term, which must be indented | ||
121 | |||
122 | and can even consist of multiple paragraphs | ||
123 | |||
124 | next term | ||
125 | Description. | ||
126 | |||
127 | Note that the term cannot have more than one line of text. | ||
128 | |||
129 | Quoted paragraphs (:duref:`ref <block-quotes>`) are created by just indenting | ||
130 | them more than the surrounding paragraphs. | ||
131 | |||
132 | Line blocks (:duref:`ref <line-blocks>`) are a way of preserving line breaks:: | ||
133 | |||
134 | | These lines are | ||
135 | | broken exactly like in | ||
136 | | the source file. | ||
137 | |||
138 | There are also several more special blocks available: | ||
139 | |||
140 | * field lists (:duref:`ref <field-lists>`) | ||
141 | * option lists (:duref:`ref <option-lists>`) | ||
142 | * quoted literal blocks (:duref:`ref <quoted-literal-blocks>`) | ||
143 | * doctest blocks (:duref:`ref <doctest-blocks>`) | ||
144 | |||
145 | |||
146 | Source Code | ||
147 | ----------- | ||
148 | |||
149 | Literal code blocks (:duref:`ref <literal-blocks>`) are introduced by ending a | ||
150 | paragraph with the special marker ``::``. The literal block must be indented | ||
151 | (and, like all paragraphs, separated from the surrounding ones by blank lines):: | ||
152 | |||
153 | This is a normal text paragraph. The next paragraph is a code sample:: | ||
154 | |||
155 | It is not processed in any way, except | ||
156 | that the indentation is removed. | ||
157 | |||
158 | It can span multiple lines. | ||
159 | |||
160 | This is a normal text paragraph again. | ||
161 | |||
162 | The handling of the ``::`` marker is smart: | ||
163 | |||
164 | * If it occurs as a paragraph of its own, that paragraph is completely left | ||
165 | out of the document. | ||
166 | * If it is preceded by whitespace, the marker is removed. | ||
167 | * If it is preceded by non-whitespace, the marker is replaced by a single | ||
168 | colon. | ||
169 | |||
170 | That way, the second sentence in the above example's first paragraph would be | ||
171 | rendered as "The next paragraph is a code sample:". | ||
172 | |||
173 | |||
174 | .. _rst-tables: | ||
175 | |||
176 | Tables | ||
177 | ------ | ||
178 | |||
179 | Two forms of tables are supported. For *grid tables* (:duref:`ref | ||
180 | <grid-tables>`), you have to "paint" the cell grid yourself. They look like | ||
181 | this:: | ||
182 | |||
183 | +------------------------+------------+----------+----------+ | ||
184 | | Header row, column 1 | Header 2 | Header 3 | Header 4 | | ||
185 | | (header rows optional) | | | | | ||
186 | +========================+============+==========+==========+ | ||
187 | | body row 1, column 1 | column 2 | column 3 | column 4 | | ||
188 | +------------------------+------------+----------+----------+ | ||
189 | | body row 2 | ... | ... | | | ||
190 | +------------------------+------------+----------+----------+ | ||
191 | |||
192 | *Simple tables* (:duref:`ref <simple-tables>`) are easier to write, but | ||
193 | limited: they must contain more than one row, and the first column cannot | ||
194 | contain multiple lines. They look like this:: | ||
195 | |||
196 | ===== ===== ======= | ||
197 | A B A and B | ||
198 | ===== ===== ======= | ||
199 | False False False | ||
200 | True False False | ||
201 | False True False | ||
202 | True True True | ||
203 | ===== ===== ======= | ||
204 | |||
205 | |||
206 | Hyperlinks | ||
207 | ---------- | ||
208 | |||
209 | External links | ||
210 | ^^^^^^^^^^^^^^ | ||
211 | |||
212 | Use ```Link text <http://example.com/>`_`` for inline web links. If the link | ||
213 | text should be the web address, you don't need special markup at all, the parser | ||
214 | finds links and mail addresses in ordinary text. | ||
215 | |||
216 | You can also separate the link and the target definition (:duref:`ref | ||
217 | <hyperlink-targets>`), like this:: | ||
218 | |||
219 | This is a paragraph that contains `a link`_. | ||
220 | |||
221 | .. _a link: http://example.com/ | ||
222 | |||
223 | |||
224 | Internal links | ||
225 | ^^^^^^^^^^^^^^ | ||
226 | |||
227 | Internal linking is done via a special reST role provided by Sphinx, see the | ||
228 | section on specific markup, :ref:`ref-role`. | ||
229 | |||
230 | |||
231 | Sections | ||
232 | -------- | ||