3 files changed, 934 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 @@
+<!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
+--------

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	--------
	233