2 files changed, 851 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 @@
+<!doctype html>
+<html>
+  <head>
+    <title>CodeMirror: reStructuredText mode</title>
+    <link rel="stylesheet" href="../../lib/codemirror.css">
+    <script src="../../lib/codemirror.js"></script>
+    <script src="rst.js"></script>
+    <style type="text/css">.CodeMirror {border-top: 1px solid black; border-bottom: 1px solid black;}</style>
+    <link rel="stylesheet" href="../../doc/docs.css">
+  </head>
+  <body>
+    <h1>CodeMirror: 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/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	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