1 files changed, 0 insertions, 526 deletions
diff --git a/js/codemirror/mode/rst/index.html b/js/codemirror/mode/rst/index.html
deleted file mode 100644
index 0831dff4..00000000
--- a/js/codemirror/mode/rst/index.html
+++ /dev/null
@@ -1,526 +0,0 @@
-<!doctype html>
-<html>
-  <head>
-    <title>CodeMirror 2: reStructuredText mode</title>
-    <link rel="stylesheet" href="../../lib/codemirror.css">
-    <script src="../../lib/codemirror.js"></script>
-    <script src="rst.js"></script>
-    <link rel="stylesheet" href="rst.css">
-    <style type="text/css">.CodeMirror {border-top: 1px solid black; border-bottom: 1px solid black;}</style>
-    <link rel="stylesheet" href="../../css/docs.css">
-  </head>
-  <body>
-    <h1>CodeMirror 2: reStructuredText mode</h1>
-<form><textarea id="code" name="code">
-.. This is an excerpt from Sphinx documentation: http://sphinx.pocoo.org/_sources/rest.txt
-.. highlightlang:: rest
-.. _rst-primer:
-reStructuredText Primer
-=======================
-This section is a brief introduction to reStructuredText (reST) concepts and
-syntax, intended to provide authors with enough information to author documents
-productively.  Since reST was designed to be a simple, unobtrusive markup
-language, this will not take too long.
-.. seealso::
-   The authoritative `reStructuredText User Documentation
-   &lt;http://docutils.sourceforge.net/rst.html&gt;`_.  The "ref" links in this
-   document link to the description of the individual constructs in the reST
-   reference.
-Paragraphs
----------
-The paragraph (:duref:`ref &lt;paragraphs&gt;`) is the most basic block in a reST
-document.  Paragraphs are simply chunks of text separated by one or more blank
-lines.  As in Python, indentation is significant in reST, so all lines of the
-same paragraph must be left-aligned to the same level of indentation.
-.. _inlinemarkup:
-Inline markup
-------------
-The standard reST inline markup is quite simple: use
-* one asterisk: ``*text*`` for emphasis (italics),
-* two asterisks: ``**text**`` for strong emphasis (boldface), and
-* backquotes: ````text```` for code samples.
-If asterisks or backquotes appear in running text and could be confused with
-inline markup delimiters, they have to be escaped with a backslash.
-Be aware of some restrictions of this markup:
-* it may not be nested,
-* content may not start or end with whitespace: ``* text*`` is wrong,
-* it must be separated from surrounding text by non-word characters.  Use a
-  backslash escaped space to work around that: ``thisis\ *one*\ word``.
-These restrictions may be lifted in future versions of the docutils.
-reST also allows for custom "interpreted text roles"', which signify that the
-enclosed text should be interpreted in a specific way.  Sphinx uses this to
-provide semantic markup and cross-referencing of identifiers, as described in
-the appropriate section.  The general syntax is ``:rolename:`content```.
-Standard reST provides the following roles:
-* :durole:`emphasis` -- alternate spelling for ``*emphasis*``
-* :durole:`strong` -- alternate spelling for ``**strong**``
-* :durole:`literal` -- alternate spelling for ````literal````
-* :durole:`subscript` -- subscript text
-* :durole:`superscript` -- superscript text
-* :durole:`title-reference` -- for titles of books, periodicals, and other
-  materials
-See :ref:`inline-markup` for roles added by Sphinx.
-Lists and Quote-like blocks
---------------------------
-List markup (:duref:`ref &lt;bullet-lists&gt;`) 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.
-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 (:duref:`ref &lt;definition-lists&gt;`) 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.
-Note that the term cannot have more than one line of text.
-Quoted paragraphs (:duref:`ref &lt;block-quotes&gt;`) are created by just indenting
-them more than the surrounding paragraphs.
-Line blocks (:duref:`ref &lt;line-blocks&gt;`) are a way of preserving line breaks::
-   | These lines are
-   | broken exactly like in
-   | the source file.
-There are also several more special blocks available:
-* field lists (:duref:`ref &lt;field-lists&gt;`)
-* option lists (:duref:`ref &lt;option-lists&gt;`)
-* quoted literal blocks (:duref:`ref &lt;quoted-literal-blocks&gt;`)
-* doctest blocks (:duref:`ref &lt;doctest-blocks&gt;`)
-Source Code
-----------
-Literal code blocks (:duref:`ref &lt;literal-blocks&gt;`) are introduced by ending a
-paragraph with the special marker ``::``.  The literal block must be indented
-(and, like all paragraphs, separated from the surrounding ones by 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:".
-.. _rst-tables:
-Tables
------
-Two forms of tables are supported.  For *grid tables* (:duref:`ref
-&lt;grid-tables&gt;`), you have to "paint" the cell grid yourself.  They look like
-this::
-   +------------------------+------------+----------+----------+
-   | Header row, column 1   | Header 2   | Header 3 | Header 4 |
-   | (header rows optional) |            |          |          |
-   +========================+============+==========+==========+
-   | body row 1, column 1   | column 2   | column 3 | column 4 |
-   +------------------------+------------+----------+----------+
-   | body row 2             | ...        | ...      |          |
-   +------------------------+------------+----------+----------+
-*Simple tables* (:duref:`ref &lt;simple-tables&gt;`) are easier to write, but
-limited: they must contain more than one row, and the first column cannot
-contain multiple lines.  They look like this::
-   =====  =====  =======
-   A      B      A and B
-   =====  =====  =======
-   False  False  False
-   True   False  False
-   False  True   False
-   True   True   True
-   =====  =====  =======
-Hyperlinks
----------
-External links
-^^^^^^^^^^^^^^
-Use ```Link text &lt;http://example.com/&gt;`_`` 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.
-You can also separate the link and the target definition (:duref:`ref
-&lt;hyperlink-targets&gt;`), like this::
-   This is a paragraph that contains `a link`_.
-   .. _a link: http://example.com/
-Internal links
-^^^^^^^^^^^^^^
-Internal linking is done via a special reST role provided by Sphinx, see the
-section on specific markup, :ref:`ref-role`.
-Sections
--------
-Section headers (:duref:`ref &lt;sections&gt;`) 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

diff --git a/js/codemirror/mode/rst/index.html b/js/codemirror/mode/rst/index.html deleted file mode 100644 index 0831dff4..00000000 --- a/js/codemirror/mode/rst/index.html +++ /dev/null
@@ -1,526 +0,0 @@
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	--------
233
234	Section headers (:duref:`ref <sections>`) are created by underlining (and
235	optionally overlining) the section title with a punctuation character, at least
236	as long as the text::
237
238	=================
239	This is a heading