radiant 0.9.0.rc2 → 0.9.1

data/vendor/extensions/markdown_filter/vendor/kramdown/doc/syntax.page

@@ -2,67 +2,72 @@
 title: Syntax
 in_menu: true
 sort_info: 10
----
-This is version **<%= ::Kramdown::VERSION %>** of the syntax documentation.
+--- name:sidebar
+<h1>Contents</h1>
 
-Table of Contents:
-
-{menu: {used_nodes: fragments, min_levels: 3}}
+{menu: {used_nodes: fragments, min_levels: 4, max_levels: 6}}
+--- name:content
 
 # kramdown Syntax
 
+This is version **<%= ::Kramdown::VERSION %>** of the syntax documentation.
+
 The kramdown syntax is based on the Markdown syntax and has been enhanced with features that are
 found in other Markdown implementations like [Maruku], [PHP Markdown Extra] and [Pandoc]. However,
 it strives to provide a strict syntax with definite rules and therefore isn't completely compatible
 with Markdown. Nonetheless, most Markdown documents should work fine when parsed with kramdown. All
 places where the kramdown syntax differs from the Markdown syntax are highlighted.
 
-Following is the complete syntax definition so that you know what you will get when a kramdown
-document is converted to HTML. There are basically two types of elements: block level elements
-(paragraphs, blockquotes, ...) and span level elements (emphasis, links, ...). Each has its own
-section.
+Following is the complete syntax definition for all elements kramdown supports. Together with the
+documentation on the available converters, it is clearly specified what you will get when a kramdown
+document is converted.
 
-[Maruku]: http://maruku.rubyforge.org
-[PHP Markdown Extra]: http://michelf.com/projects/php-markdown/extra/
-[Pandoc]: http://johnmacfarlane.net/pandoc/
 
+## Source Text Formatting
 
-## Tabs
+A kramdown document may be in any encoding, for example ASCII, UTF-8 or ISO-8859-1, and the output
+will have the same encoding as the source. The document consists of two types of elements, block
+level elements and span level elements:
 
-kramdown assumes that tab stops are set at multiples of four. This is especially important when
-using tabs for indentation in lists. Also, tabs may only be used at the beginning of a line when
-indenting text and must not be preceded by spaces. Otherwise the results may be unexpected.
+* Block level elements define the main structure of the content, for example, what part of the text
+  should be a paragraph, a list, a blockquote and so on.
 
+* Span level elements mark up small text parts as, for example, emphasized text or a link.
 
-## Automatic Escaping and Escaping
+Thus span level elements can only occur inside block level elements or other span level elements.
 
-There are three characters in HTML syntax that need special treatment: `<`, `>` and `&`. When these
-characters are used inside a code block or code span, they are always automatically escaped to their
-HTML entity counterparts.
+You will often find references to the "first column" or "first character" of a line in a block level
+element descriptions. Such a reference is always to be taken relative to the current indentation
+level because some block level elements open up a new indentation level (e.g. blockquotes). The
+beginning of a kramdown document opens up the default indentation level which begins at the first
+column of the text.
 
-When used inside the normal text flow:
 
-* `<` and `>` are always escaped except if they are part of an HTML tag, an XML processing
-  instruction/comment or an autolink.
-* `&` is escaped if it is not part of an HTML entity.
+### Usage of Tabs
 
-For example, the following fragment:
+kramdown assumes that tab stops are set at multiples of four. This is especially important when
+using tabs for indentation in lists. Also, tabs may only be used at the beginning of a line when
+indenting text and must not be preceded by spaces. Otherwise the results may be unexpected.
 
-    This is the A&O. &copy; 2008 by me
-    0 < 1 < 2 and 2 > 1 > 0
 
-will be converted to:
+### Automatic and Manual Escaping
 
-    <p>This is the A&amp;O. &copy; 2008 by me
-    0 &lt; 1 &lt; 2 and 2 &gt; 1 &gt; 0</p>
+Depending on the output format, there are often characters that need special treatment. For example,
+when converting a kramdown document to HTML one needs to take care of the characters `<`, `>` and
+`&`. To ease working with these special characters, they are automatically and correctly escaped
+depending on the output format.
 
-Since kramdown also uses some characters to mark-up the text, there need to be a way to escape these
-special characters so that they can have their normal meaning. This can be done by using backslash
-escapes. For example, you can use a literal backtick like this:
+This means, for example, that you can just use `<`, `>` and `&` in a kramdown document and need not
+think about when to use their HTML entity counterparts. However, if you *do use* HTML entitys or
+HTML tags which use one of the characters, the result will be correct nonetheless!
+
+Since kramdown also uses some characters to mark-up the text, there needs to be a way to escape
+these special characters so that they can have their normal meaning. This can be done by using
+backslash escapes. For example, you can use a literal backtick like this:
 
     This \`is not a code\` span!
 
-Following is a list of all those characters (character sequences) that can be escaped:
+Following is a list of all the characters (character sequences) that can be escaped:
 
     \         backslash
     .         period
@@ -71,7 +76,7 @@ Following is a list of all those characters (character sequences) that can be es
     +         plus
     -         minus
     `         backtick
-    ()[]{}    parens/brackets/braces
+    ()[]{}    left and right parens/brackets/braces
     #         hash
     !         bang
     <<        left guillemet
@@ -80,38 +85,13 @@ Following is a list of all those characters (character sequences) that can be es
     |         pipe
     "         double quote
     '         single quote
+    $         dollar sign
 
 
-## Typographic Symbols
-
-kramdown converts the following plain ASCII character into their corresponding typographic symbols:
-
-* `---` will become an em-dash (like this ---)
-* `--` will become an en-dash (like this --)
-* `...` will become an ellipsis (like this ...)
-* `<<` will become a left guillemet (like this <<) -- an optional following space will become a
-  non-breakable space
-* `>>` will become a right guillemet (like this >>) -- an optional leading space will become a
-  non-breakable space
-
-It also replaces normal single `'` and double quotes `"` with "fancy quotes". There *may* be times
-when kramdown falsely replace the quotes. If this is the case, just \'escape\" the quotes and they
-won't be replaced with fancy ones.
-
-> The original Markdown program does not do this transformations.
-{: .markdown-difference}
-
-
-# Block Level Elements
-
-Block level elements are used to structure the content. They can mark up some text, for example, as
-code, as a quote or as list items.
+# Structural Elements
 
-You will often find references to the "first column" or "first character" of a line in the block
-level element descriptions. Such a reference is always to be taken relative to the current
-indentation level because some block level elements open up a new indentation level (e.g.
-blockquotes). The beginning of a kramdown document opens up the default indentation level which
-begins at the first column of the text.
+All structural elements are block level elements and they are used to structure the content. They
+can mark up some text as, for example, a simple paragraph, a quote or as a list item.
 
 
 ## Blank lines
@@ -127,37 +107,12 @@ meaning:
 * When used in lists -- see the [lists section](#lists)
 
 
-## End-Of-Block Marker
-
-The End-Of-Block (EOB) marker -- a `^` as first character on an otherwise empty line -- can be used
-to specify the end of a block level element even if the block level element, after which it is used,
-would continue otherwise. If there is no block to end, the EOB marker is simply ignored.
-
-You won't find an EOB marker in most kramdown documents but sometimes it is necessary to use it to
-achieve the wanted results which would be impossible otherwise.
-
-For example, the following gives you one list with two items:
-
-    * list item one
-
-    * list item two
-
-By using an EOB marker, you can make two lists with each one item:
-
-    * list one
-    ^
-    * list two
-
-> The EOB marker is not part of the standard Markdown syntax.
-{: .markdown-difference}
-
-
 ## Paragraphs
 
 Paragraphs are the most used block level elements. One or more consecutive lines of text are
 interpreted as one paragraph. Every line of a paragraph may be indented up to three spaces. You can
 separate two consecutive paragraphs from each other by using one or more blank lines. Notice that a
-line break in the source does not mean a line break in the output. If you want to have an explicit
+line break in the source does not mean a line break in the output! If you want to have an explicit
 line break (i.e. a `<br />` tag) you need to end a line with two or more spaces or two backslashes!
 Note, however, that a line break on the last text line of a paragraph is not possible and will be
 ignored. Leading and trailing spaces will be stripped from the paragraph text.
@@ -170,22 +125,23 @@ The following gives you an example of how paragraphs look like:
 
       This is another paragraph, not connected to the above one. But  
     with a hard line break. \\
-    and another one.
+    And another one.
 {: .show-whitespaces .ws-lr}
 
 
 ## Headers
 
-kramdown supports Setext style and atx style headers.
+kramdown supports so called Setext style and atx style headers. Both forms can be used inside a
+single document.
 
 ### Setext Style
 
-Setext style headers are specified by a blank line (except at the beginning of a document), a line
-of text (the header text) followed by a line with only equal signs (for a first level header) or
-dashes (for a second level header). The header text may be indented up to three spaces, any leading
-or trailing spaces are stripped from the header text. The amount of equal signs or dashes is not
-significant, just one is enough but more may look better. The equal signs or dashes have to begin at
-the first column. For example:
+Setext style headers are specified by a [blank line](#blank-lines) (except at the beginning of a
+document), followed by a line of text (the header text) and a line with only equal signs (for a
+first level header) or dashes (for a second level header). The header text may be indented up to
+three spaces but any leading or trailing spaces are stripped from the header text. The amount of
+equal signs or dashes is not significant, just one is enough but more may look better. The equal
+signs or dashes have to begin at the first column. For example:
 
     First level header
     ==================
@@ -196,7 +152,7 @@ the first column. For example:
        Other first level header
     =
 
-As mentioned you need to insert a blank line before a Setext header:
+As mentioned you need to insert a blank line before (but not necessarily after) a Setext header:
 
     This is a normal
     paragraph.
@@ -214,8 +170,8 @@ However, it is generally a good idea to also use a blank line after a Setext hea
 more appropriate.
 
 > The original Markdown syntax allows one to omit the blank line before a Setext header. However,
-> this makes reading the document harder than necessary and is therefore not allowed in a kramdown
-> document.
+> this leads to ambiguities and makes reading the document harder than necessary. Therefore it is
+> not allowed in a kramdown document.
 {: .markdown-difference}
 
 An edge case worth mentioning is the following:
@@ -224,18 +180,19 @@ An edge case worth mentioning is the following:
     ---
     para
 
-One might ask if this represents two paragraphs separated by a horizontal line or a second level
-header and a paragraph. As suggested by the wording in the example, the latter is the case. The
-general rule is that Setext headers are processed before horizontal rules.
+One might ask if this represents two paragraphs separated by a [horizontal rule](#horizontal-rules)
+or a second level header and a paragraph. As suggested by the wording in the example, the latter is
+the case. The general rule is that Setext headers are processed before horizontal rules.
 
 ### atx Style
 
-atx style headers can be specified by a blank line (except at the beginning of a document), a line
-with one or more hash characters and then the header text. No spaces are allowed before the hash
-characters. The number of hash characters specifies the heading level: one hash character gives you
-a first level heading, two a second level heading and so on till the maximum of six hash characters
-for a sixth level heading. You may optionally use any number of hashes at the end of the line to
-close the header. Any leading or trailing spaces are stripped from the header text. For example:
+atx style headers are specified by a [blank line](#blank-lines) (except at the beginning of a
+document), followed by a line with one or more hash characters and then the header text. No spaces
+are allowed before the hash characters. The number of hash characters specifies the heading level:
+one hash character gives you a first level heading, two a second level heading and so on until the
+maximum of six hash characters for a sixth level heading. You may optionally use any number of
+hashes at the end of the line to close the header. Any leading or trailing spaces are stripped from
+the header text. For example:
 
     # First level header
 
@@ -246,56 +203,14 @@ close the header. Any leading or trailing spaces are stripped from the header te
 > Again, the original Markdown syntax allows one to omit the blank line before an atx style header.
 {: .markdown-difference}
 
-### Automatic Generation of Header IDs
-
-kramdown supports the automatic generation of header IDs if the option `:auto_ids` is set to `true`
-(which is the default). This is done by converting the untransformed, i.e. plain, header text via the
-following steps:
-
-* All characters except letters, numbers, spaces and dashes are removed.
-* All characters from the start of the line till the first letter are removed.
-* Everything except letters and numbers is converted to dashes.
-* Everything is lowercased.
-* If nothing is left, the identifier `section` is used.
-* If a such created identifier already exists, a dash and a sequential number is added (first `-1`,
-  then `-2` and so on).
-
-Following are some examples of header texts and their respective generated IDs:
-
-    # This is a header
-    auto_id: this-is-a-header
-
-    ## 12. Another one 1 here
-    auto_id: another-one-1-here
 
-    ### Do ^& it now
-    auto_id: do--it-now
+### Specifying a Header ID
 
-    Hallo
-    =====
-    auto_id: hallo
-
-    Not now
-    -------
-    auto_id: not-now
-
-    # Hallo
-    auto_id: hallo-1
-
-    # 123456789
-    auto_id: section
-
-> The automatic creation of header IDs is not part of standard Markdown. The rules on how header
-> text is converted to an identifier are based on the rules specified by [Pandoc].
-{: .markdown-difference}
-
-### Manually Specifying a Header ID
-
-Additionally, kramdown supports a nice way for setting the header ID which is available in [PHP
-Markdown Extra] and [Maruku]: If you follow the header text with an opening curly bracket (separated
-from the text with a least one space), a hash, the ID and a closing curly bracket, the ID is set on
-the header. If you use the trailing hash feature of atx style headers, the header ID has to go after
-the trailing hashes. For example:
+kramdown supports a nice way for explicitly setting the header ID which is taken from [PHP Markdown
+Extra] and [Maruku]: If you follow the header text with an opening curly bracket (separated from the
+text with a least one space), a hash, the ID and a closing curly bracket, the ID is set on the
+header. If you use the trailing hash feature of atx style headers, the header ID has to go after the
+trailing hashes. For example:
 
     Hello        {#id}
     -----
@@ -310,11 +225,11 @@ the trailing hashes. For example:
 
 ## Blockquotes
 
-A blockquote is started using the `>` marker followed by an optional space. The marker itself may be
-indented up to three spaces. All following lines that are also started with the blockquote marker
-belong to the blockquote. The contents of a blockquote are block level elements. This means that if
-you are just using text as content that it will be wrapped in a paragraph. For example, the
-following gives you one blockquote with two paragraphs in it:
+A blockquote is started using the `>` marker followed by an optional space and the content of the
+blockquote. The marker itself may be indented up to three spaces. All following lines that are also
+started with the blockquote marker belong to the blockquote. The contents of a blockquote are block
+level elements. This means that if you are just using text as content that it will be wrapped in a
+paragraph. For example, the following gives you one blockquote with two paragraphs in it:
 
     > This is a blockquote.
     >on multiple lines.
@@ -334,8 +249,8 @@ block level elements:
     > and all other block level elements
 
 Note that the first space character after the `>` marker does *not* count when counting spaces for
-the indentation of the block level elements inside the blockquote! So code blocks will have to be
-indented with five spaces or one space and one tab, like this:
+the indentation of the block level elements inside the blockquote! So [code blocks](#code-blocks)
+will have to be indented with five spaces or one space and one tab, like this:
 
     > A code block:
     >
@@ -356,9 +271,8 @@ indented with five spaces or one space and one tab, like this:
 
 ## Code Blocks
 
-Code blocks can be used to represent verbatim text like markup, HTML or a program fragment. No
-syntax is parsed within a code block, only `<`, `>` and `&` are substituted by their respective HTML
-counterparts. A code block is wrapped in both `<pre>` and  `<code>` tags.
+Code blocks can be used to represent verbatim text like markup, HTML or a program fragment because
+no syntax is parsed within a code block.
 
 ### Standard Code Block
 
@@ -371,8 +285,8 @@ blocks:
 
         This text belongs to the same code block.
 
-If you want to have one code block directly after another one, you need to use an EOB marker to
-separate the two:
+If you want to have one code block directly after another one, you need to use an [EOB
+marker](#eob-marker) to separate the two:
 
         Here comes some code
     ^
@@ -406,54 +320,6 @@ example:
 This type of code block is especially useful for copy-pasted code since you don't need to indent the
 code.
 
-### Showing Whitespace in a Code Block
-
-If you add the class `show-whitespaces` to a code block (using a [block
-IAL](#block-inline-attribute-lists)), all spaces are replaced with `&sdot;` and additionally spaces
-and tabs in the code block are marked up using HTML `span` tags and the CSS classes:
-
-* `ws-space-l`, `ws-tab-l`: leading spaces/tabs
-* `ws-space-r`, `ws-tab-r`: trailing spaces/tabs
-* `ws-space`, `ws-tab`: spaces/tabs in between
-
-Here is an example output:
-
-    	  leading tab	and space
-    trailing   tab and space    	
-{: .show-whitespaces}
-
-
-### Automatic Syntax Highlighting   {#syntax-highlighting}
-
-kramdown supports syntax highlighting of code through the [CodeRay](http://coderay.rubychan.de)
-library if it is installed and if the HTML converter is used. Syntax highlighting is activated when
-you add the key `lang` to a code block (using a [block IAL](#block-inline-attribute-lists)), its
-value has to be a language supported by CodeRay.
-
-Here is an example output:
-
-    require 'kramdown'
-
-    Kramdown::Document.new('* something').to_html
-    puts 1 + 1
-{: lang='ruby'}
-
-
-## Horizontal Rules
-
-A horizontal rule is created by using three or more asterisks, dashes or underscores (these may not
-be mixed on one line), optionally separated by spaces or tabs, on an otherwise blank line. The first
-asterisk, dash or underscore may optionally be indented up to three spaces. The following examples
-show different possibilities to create a horizontal rule:
-
-    * * *
-
-    ---
-
-      _  _  _  _
-
-    ---------------
-
 
 ## Lists
 
@@ -466,7 +332,8 @@ Both ordered and unordered lists follow the same rules.
 
 A list is started with a list marker (in case of unordered lists one of `+`, `-` or `*` -- you can
 mix them -- and in case of ordered lists a number followed by a period) followed by one tab or at
-least one space and then the first part of the content of the list item. The leading tabs or spaces
+least one space, optionally followed by an [IAL](#inline-attribute-lists) that should be applied to
+the list item and then the first part of the content of the list item. The leading tabs or spaces
 are stripped away from this first line of content to allow for a nice alignment with the following
 content of a list item (see below). All following list items with the same marker type (unordered or
 ordered) are put into the same list. The numbers used for ordered lists are irrelevant, an ordered
@@ -515,7 +382,8 @@ different (marker and list content) indents for same level list items!
 {: .markdown-difference}
 
 When using tabs for indenting the content of a list item, remember that tab stops occur at multiples
-of four. Tabs are converted to spaces for calculating the indentation. For example:
+of four for kramdown. Tabs are correctly converted to spaces for calculating the indentation. For
+example:
 
     *   Using a tab to indent this line, the tab only counts as three spaces and therefore the
         overall indentation is four spaces.
@@ -524,8 +392,8 @@ of four. Tabs are converted to spaces for calculating the indentation. For examp
             is three spaces and the marker itself takes two characters, the overall indentation
             needed for the following lines is eight spaces or two tabs.
 
-It is clear that you might get unexpected results if you mix tabs and spaces and don't have the tab
-stops set to multiples of four! Therefore this should be avoided!
+It is clear that you might get unexpected results if you mix tabs and spaces or if you don't have
+the tab stops set to multiples of four in your editor! Therefore this should be avoided!
 
 The content of a list item is made up of either text or block level elements. Simple list items only
 contain text like in the above examples. They are not even wrapped in a paragraph tag. If the first
@@ -549,6 +417,16 @@ by leaving a blank line after the last list item and using an EOB marker:
 
     ^
 
+The text of the last list item is also wrapped in a paragraph tag if *all* other list items contain
+a proper paragraph as first element. This makes the following use case work like expected, i.e.
+*all* the list items are wrapped in paragraphs:
+
+    * First list item
+
+    * Second list item
+
+    * Last list item
+
 > The original Markdown syntax page specifies that list items which are separated by one or more
 > blank lines are wrapped in paragraph tags. This means that the first text will also be wrapped in
 > a paragraph if you have block level elements in a list which are separated by blank lines. The
@@ -569,8 +447,8 @@ Since the content of a list item can contain block level elements, you can do th
 
     *   Second item
 
-However, there is a problem when you want to follow a list item with an indentation of four or less
-immediately with a code block. You can use an EOB marker to circumvent this problem:
+However, there is a problem when you want to have a code block immediately after a list item. You
+can use an EOB marker to circumvent this problem:
 
     *   This is a list item.
 
@@ -634,6 +512,14 @@ useful when the paragraph starts with something looking like a list item marker)
     1984\. It was great
     \- others say that, too!
 
+As mentioned at the beginning, an optional IAL for applying attributes to a list item can be used
+after the list item marker:
+
+    * {:.cls} This item has the class "cls".
+      Here continues the above paragraph.
+
+    * This is a normal list item.
+
 
 ### Definition Lists
 
@@ -716,7 +602,7 @@ There are three different text line types that can be used in a table:
   text of the first table cell. Subsequent table cells consist of a pipe character followed by the
   cell text. One may optionally use a pipe character at the the end of a table row line.
 
-  Header rows, footer rows and normal rows are all made using these table rows. Table cells can only
+  Header rows, footer rows and normal rows are all done using these table rows. Table cells can only
   contain a single line of text, no multiline text is supported. The text of a table cell is parsed
   as span level elements. Note that literal pipe characters need to be escaped, even if they occur
   in code spans!
@@ -830,6 +716,82 @@ editor. However, the table syntax is flexible and the above table could also be
     | Footer row
 
 
+## Horizontal Rules
+
+A horizontal rule for visually separating content is created by using three or more asterisks,
+dashes or underscores (these may not be mixed on a line), optionally separated by spaces or tabs, on
+an otherwise blank line. The first asterisk, dash or underscore may optionally be indented up to
+three spaces. The following examples show different possibilities to create a horizontal rule:
+
+    * * *
+
+    ---
+
+      _  _  _  _
+
+    ---------------
+
+
+## Math Blocks
+
+> This syntax feature is not part of the original Markdown syntax. The idea comes from the [Maruku]
+> and [Pandoc] packages.
+{: .markdown-difference}
+
+kramdown has built-in support for block and span level mathematics written in LaTeX.
+
+A math block is started using two dollar signs, optionally indented up to three spaces. The math
+block continues until the next two dollar signs (which may be on the same line or on one of the next
+lines) that appear at the end of a line, i.e. they may only be followed by whitespace characters.
+The content of a math block has to be valid LaTeX math. It is always wrapped inside a
+`\begin{displaymath}...\end{displaymath}` enviroment except if it begins with a `\begin` statement.
+
+The following kramdown fragment
+
+    $$
+    \begin{align*}
+      & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
+      = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
+      & (x_1, \ldots, x_n) \left( \begin{array}{ccc}
+          \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
+          \vdots & \ddots & \vdots \\
+          \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
+        \end{array} \right)
+      \left( \begin{array}{c}
+          y_1 \\
+          \vdots \\
+          y_n
+        \end{array} \right)
+    \end{align*}
+    $$
+
+renders as
+
+$$
+\begin{align*}
+  & \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
+  = \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
+  & (x_1, \ldots, x_n) \left( \begin{array}{ccc}
+      \phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
+      \vdots & \ddots & \vdots \\
+      \phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
+    \end{array} \right)
+  \left( \begin{array}{c}
+      y_1 \\
+      \vdots \\
+      y_n
+    \end{array} \right)
+\end{align*}
+$$
+
+Using inline math is also easy: just surround your math content with two dollar signs, like with a
+math block.
+
+If you don't want to start a math block or an inline math statement, just escape the dollar signs
+and they will be treated as simple dollar signs. If you want to start an inline math statement at
+the beginning of a paragraph, just escape the first dollar sign.
+
+
 ## HTML Blocks
 
 > The original Markdown syntax specifies that an HTML block must start at the left margin, i.e. no
@@ -879,9 +841,9 @@ inside a raw HTML block.
 Also, if an invalid closing tag is found, it is ignored.
 
 By default, kramdown parses all block HTML tags and all XML tags as raw HTML blocks. However, this
-can be configured with the `:parse_block_html` option. If this is set to `true`, then syntax parsing
-in HTML blocks is globally enabled. It is also possible to enable/disable syntax parsing on a tag
-per tag basis using the `markdown` attribute:
+can be configured with the `parse_block_html`. If this is set to `true`, then syntax parsing in HTML
+blocks is globally enabled. It is also possible to enable/disable syntax parsing on a tag per tag
+basis using the `markdown` attribute:
 
 * If an HTML tag has an attribute `markdown="0"`, then the tag is parsed as raw HTML block.
 
@@ -895,7 +857,7 @@ per tag basis using the `markdown` attribute:
   level elements.
 
 The following list shows which HTML tags are parsed in which mode by default when `markdown="1"` is
-applied or `:parse_block_html` is `true`:
+applied or `parse_block_html` is `true`:
 
 Parse as raw HTML block
 : 
@@ -906,19 +868,19 @@ Parse as raw HTML block
 Parse as block level elements
 : 
         applet button blockquote colgroup dd div dl fieldset form iframe li
-        map noscript object ol table tbody td th thead tfoot tr ul
+        map noscript object ol table tbody thead tfoot tr td ul
 
 Parse as span level elements
 : 
         a abbr acronym address b bdo big cite caption code del dfn dt em
         h1 h2 h3 h4 h5 h6 i ins kbd label legend optgroup p pre q rb rbc
-        rp rt rtc ruby samp select small span strong sub sup tt var
+        rp rt rtc ruby samp select small span strong sub sup th tt var
 
 > Remember that all span level HTML tags like `a` or `b` do not start a HTML block! However, the
 > above lists also include span level HTML tags in the case the `markdown` attribute is used on a
 > tag inside a raw HTML block.
 
-Here is a simple example input and its output with `:parse_block_html` set to `false`:
+Here is a simple example input and its HTML output with `parse_block_html` set to `false`:
 
     This is a para.
     <div>
@@ -957,7 +919,7 @@ appears after a start/end tag but on the same line, is processed as if it appear
     <div markdown="1">The end tag is not found because
     this line is parsed as a paragraph</div>
 
-Since setting `:parse_block_html` to `true` can lead to some not wanted behaviour, it is generally
+Since setting `parse_block_html` to `true` can lead to some not wanted behaviour, it is generally
 better to selectively enable or disable block/span level elements parsing by using the `markdown`
 attribute!
 
@@ -988,167 +950,8 @@ comments is not processed:
     continues here.
 
 
-## Attribute List Definitions
-
-> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
-> the [Maruku] package.
-{: .markdown-difference}
-
-This is an implementation of [Maruku]'s feature for adding attributes to block and span level
-elements (the naming is also taken from Maruku). This block level element is used to define
-attributes which can be referenced later. The [Block Inline Attribute
-List](#block-inline-attribute-lists) is used to attach attributes to a block level element and the
-[Span Inline Attribute List](#span-inline-attribute-lists) is used to attach attributes to a span
-level element.
-
-Following are some examples of attribute list definitions (ALDs) and afterwards comes the syntax
-explanation:
-
-    {:ref-name: #myid .my-class}
-    {:other: ref-name #id-of-other title="hallo you"}
-    {:test: key="value \" with quote" and other='quote brace \}'}
-
-An ALD line has the following structure:
-
-* a left brace, optionally preceded by up to three spaces,
-* followed by a colon, the reference name and another colon,
-* followed by attribute definitions (allowed characters are backslash-escaped closing braces or any
-  character except a not escaped closing brace),
-* followed by a closing brace and optional spaces till the end of the line.
-
-The reference name needs to start with a word character or a digit, optionally followed by other word
-characters, digits or dashes.
-
-There are four different types of attribute definitions which have to be separated by one or more
-spaces:
-
-references
-
-:   This must be a valid reference name. It is used to reference an other ALD so that the attributes
-    of the other ALD are also included in this one. The reference name is ignored when collecting the
-    attributes if no attribute definition list with this reference name exists. For example, a
-    simple reference looks like `id`.
-
-key-value pairs
-
-:   A key-value pair is defined by a key name, which must follow the rules for reference names, then
-    an equal sign and then the value in single or double quotes. If you need to use the value
-    delimiter (a single or a double quote) inside the value, you need to escape it with a backslash.
-    Key-value pairs can be used to specify arbitrary attributes for block or span level elements. For
-    example, a key-value pair looks like `key1="bef \"quoted\" aft"` or `title='This is a title'`.
-
-ID name
-
-:   An ID name is defined by using a hash and then the identifier name which must follow the rules
-    for reference names. This is a short hand for the key-value pair `id="IDNAME"` since this is
-    often used. The ID name specifies the unique ID of a block or span level element. For example,
-    an ID name looks like `#myid`.
-
-class names
-
-:   A class name is defined by using a dot and then the class name. This is (almost, but not quite)
-    a short hand for the key-value pair `class="class-name"`. Almost because it actually means that
-    the class name should be appended to the current value of the `class` attribute. The following
-    ALDs are all equivalent:
-
-        {:id: .cls1 .cls2}
-        {:id: class="cls1" .cls2}
-        {:id: class="something" class="cls1" .cls2}
-        {:id: class="cls1 cls2}
-
-As can be seen from the example of the class names, attributes that are defined earlier are
-overwritten by ones with the same name defined later. Also, everything in the attribute definitions
-part that does not match one of the above four types is ignored.
-
-If there is more than one ALD with the same reference name, the attribute definitions of all the
-ALDs are processed like they are defined in one ALD.
-
-
-## Block Inline Attribute Lists
-
-> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
-> the [Maruku] package.
-{: .markdown-difference}
-
-This block level element is used to attach attributes to a block level element. A block inline
-attribute list (block IAL) has the same structure as an [ALD](#attribute-list-definitions) except
-that the colon/reference name/colon part is replaced by a colon. A block IAL (or two or more block
-IALs) has to be put directly after the block level element to which the attributes should be
-attached, otherwise it is ignored. This is, for example, the case when there is a blank line between
-the block level element and the IAL.
-
-Key-value pairs of an IAL take precedence over equally named key-value pairs in referenced ALDs.
-
-Here are some examples for block IALs:
-
-    A simple paragraph with an ID attribute.
-    {: #para-one}
-
-    > A blockquote with a title
-    {:title="The blockquote title"}
-    {: #myid}
-
-        Some code here
-    {:.ruby}
-
-
-## Extension Blocks
-
-> This syntax feature is not part of the original Markdown syntax.
-{: .markdown-difference}
-
-Extension blocks can be used, for example, to treat whole sections of text specially. For example,
-one could write an extension that highlights a code fragment specified in an extension block.
-
-An extension block has two forms, one with a body and one without a body:
-
-Without a body
-
-:   The extension block line has the same structure as an [ALD](#attribute-list-definitions) except
-    that the reference name needs to prefixed and postfixed with `:` and identifies the extension to
-    be used. Attributes can be defined like it is done for an ALD.
-
-With a body
-
-:   The starting and ending lines of an extension block with a body have the same structure as an
-    [ALD](#attribute-list-definitions) except that the reference name needs to prefixed with `:` and
-    identifies the extension to be used; attributes can be defined on the starting or ending line.
-    The text between the starting and ending line is passed to the extension and not parsed by
-    kramdown. If no ending line is found, the starting line is ignored and the body is parsed
-    normally by kramdown.
-
-If the specified extension is not found, a warning is shown and the whole extension block including
-the body is ignored. The following extensions are built-in:
-
-`comment`
-
-:   Treats the body text as a comment which does not show in the output.
-
-`nomarkdown`
-
-:   The body is not processed with kramdown but output as-is.
-
-`options`
-
-:   Should be used without a body since the body is ignored. Is used for setting the global options
-    for the kramdown processor (for example, to enable automatic header ID generation). Note that
-    options that are used by the parser are immediately effective whereas all other options are not!
-    This means, for example, that it is not possible to set converter options only for some part of
-    a kramdown document.
-
-Here are some examples for how extension blocks look like:
-
-    {::toc::}
-
-    The above extension block could be replaced by a table of contents.
-
-    {::comment:}
-    This text is completely ignored by kramdown - a comment in the text.
-    {::comment:}
-
 
-
-# Span Level Elements
+# Text Markup
 
 These elements are used inside block level elements to markup text fragments. For example, one can
 easily create links or apply emphasis to certain text parts.
@@ -1160,7 +963,20 @@ output.
 
 ## Links and Images
 
-Two styles of links are supported: inline and reference.
+Three types of links are supported: autolinks, inline links and reference links.
+
+### Autolinks
+
+This is the easiest one to create: Just surround a web address or an email address with angle
+brackets and the address will be turned into a proper link. The address will be used as link target
+and as link text. For example:
+
+    Information can be found on the <http://example.com> homepage.
+    You can also mail me: <me.example@example.com>
+
+It is not possible to specify a different link text using autolinks -- use the other link types for
+this!
+
 
 ### Inline Links
 
@@ -1244,42 +1060,30 @@ The link definition for images is exactly the same as the link definition for no
 
 ## Emphasis
 
-kramdown uses the HTML elements `em` and `strong` to style emphasized text parts. Text parts that
-are surrounded with single asterisks `*` or underscores `_` are wrapped in `em` tags, text parts
-surrounded with two asterisks or underscores are wrapped in `strong` tags. Surrounded means that the
-starting delimiter must not be followed by a space and that the stopping delimiter must not be
-preceded by a space. For example:
+kramdown supports two types of emphasis: light and strong emphasis. Text parts that are surrounded
+with single asterisks `*` or underscores `_` are treated as text with light emphasis, text parts
+surrounded with two asterisks or underscores are treated as text with strong emphasis. Surrounded
+means that the starting delimiter must not be followed by a space and that the stopping delimiter
+must not be preceded by a space.
+
+Here is an example for text with light and strong emphasis:
 
     *some text*
     _some text_
     **some text**
     __some text__
 
-will produce the following output:
-
-    <em>some text</em>
-    <em>some text</em>
-    <strong>some text</strong>
-    <strong>some text</strong>
-
 The asterisk form is also allowed within a single word:
 
     This is un*believe*able! This d_oe_s not work!
 
-Text emphasized with different delimiters can be nested but you can't nest emphasized text with the
-same delimiters:
-
-    This is a ***strong and emphasized*** text.
-    This **is __very__ strong**.
-    This **is **very** strong**.
-
-will produce the following output:
-
-    <p>This is a <strong><em>strong and emphasized</em></strong> text.
-    This <strong>is <strong>very</strong> strong</strong>.
-    This <strong>is </strong>very<strong> strong</strong>.</p>
+Text can be marked up with both light and strong emphasis, possibly using different delimiters.
+However, it is not possible to nest strong within strong or light within light emphasized text:
 
-Notice the difference between the second and the third line!
+    This is a ***text with light and strong emphasis***.
+    This **is _emphasized_ as well**.
+    This *does _not_ work*.
+    This **does __not__ work either**.
 
 If one or two asterisks or underscores are surrounded by spaces, they are treated literally. If you
 want to force the literal meaning of an asterisk or an underscore you can backslash-escape it:
@@ -1296,20 +1100,16 @@ by surrounding it with backticks `` ` ``. For example:
 
     Use `<html>` tags for this.
 
-The special characters `<`, `>` and `&` are substituted by their respective HTML counterparts (same
-behaviour as seen with the block level code block element).
+Note that all special characters in a code span are treated correctly. For example, when a code span
+is converted to HTML, the characters `<`, `>` and `&` are substituted by their respective HTML
+counterparts.
 
 To include a literal backtick in a code span, you need to use two or more backticks as delimiters.
 You can insert one optional space after the starting and before the ending delimiter (these spaces
 are not used in the output). For example:
 
     Here is a literal `` ` `` backtick.
-    And here is ``  `some`  `` text (note the two spaces!).
-
-will produce:
-
-    <p>Here is a literal <code>`</code> backtick.</p>
-    <p>And here is <code> `some` </code> text (note the two spaces!).</p>
+    And here is ``  `some`  `` text (note the two spaces so that one is left in the output!).
 
 A single backtick surrounded by spaces is treated as literal backtick. If you want to force the
 literal meaning of a backtick you can backslash-escape it:
@@ -1327,7 +1127,7 @@ you have to use, for example, `<br />` instead of `<br>` (although kramdown trie
 if possible).
 
 By default, kramdown parses kramdown syntax inside span HTML tags. However, this behaviour can be
-configured with the `:parse_span_html` option. If this is set to `true`, then syntax parsing in HTML
+configured with the `parse_span_html` option. If this is set to `true`, then syntax parsing in HTML
 spans is enabled, if it is set to `false`, parsing is disabled. It is also possible to
 enable/disable syntax parsing on a tag per tag basis using the `markdown` attribute:
 
@@ -1434,7 +1234,202 @@ foot note definitions are ignored. If more than one footnote definitions have th
 name, all footnote definitions but the last are ignored.
 
 
-## Span Inline Attribute Lists
+## Abbreviations
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [PHP Markdown Extra] package.
+{: .markdown-difference}
+
+kramdown provides a syntax to assign the full phrase to an abbreviation. When writing the text, you
+don't need to do anything special. However, once you add abbreviation definitions, the
+abbreviations in the text get marked up automatically. Abbreviations can consist of any character
+except a closing bracket.
+
+An abbreviation definition is used to define the full phrase for an abbreviation and has the
+following structure:
+
+* An asterisk and the abbreviation in square brackets, optionally indented up to three
+  spaces,
+* then a colon and the full phrase of the abbreviation on one line (leading and trailing spaces are
+  stripped from the full phrase).
+
+Later abbreviation definition for the same abbreviation override prior ones and it does not matter
+where you put an abbreviation definition in a kramdown document. Empty definitions are also allowed.
+
+Here are some examples:
+
+    This is some text not written in HTML but in another language!
+
+    *[another language]: It's called Markdown
+    *[HTML]: HyperTextMarkupLanguage
+
+> Abbreviation definitions are, despite being described here, block level elements.
+{: .information}
+
+
+## Typographic Symbols
+
+> The original Markdown syntax does not support these transformations.
+{: .markdown-difference}
+
+kramdown converts the following plain ASCII character into their corresponding typographic symbols:
+
+* `---` will become an em-dash (like this ---)
+* `--` will become an en-dash (like this --)
+* `...` will become an ellipsis (like this ...)
+* `<<` will become a left guillemet (like this <<) -- an optional following space will become a
+  non-breakable space
+* `>>` will become a right guillemet (like this >>) -- an optional leading space will become a
+  non-breakable space
+
+It also replaces normal single `'` and double quotes `"` with "fancy quotes". There *may* be times
+when kramdown falsely replace the quotes. If this is the case, just \'escape\" the quotes and they
+won't be replaced with fancy ones.
+
+
+
+# Other Markup
+
+This section describes markup that is not widely used in kramdown documents but which are sometimes
+needed nonetheless.
+
+
+## End-Of-Block Marker    {#eob-marker}
+
+> The EOB marker is not part of the standard Markdown syntax.
+{: .markdown-difference}
+
+The End-Of-Block (EOB) marker -- a `^` as first character on an otherwise empty line -- is a block
+level element that can be used to specify the end of a block level element even if the block level
+element, after which it is used, would continue otherwise. If there is no block level element to
+end, the EOB marker is simply ignored.
+
+You won't find an EOB marker in most kramdown documents but sometimes it is necessary to use it to
+achieve the wanted results which would be impossible otherwise. However, it should only be used when
+absolutely necesary!
+
+For example, the following gives you one list with two items:
+
+    * list item one
+
+    * list item two
+
+By using an EOB marker, you can make two lists with one item each:
+
+    * list one
+    ^
+    * list two
+
+
+## Attribute List Definitions
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [Maruku] package.
+{: .markdown-difference}
+
+This is an implementation of [Maruku]'s feature for adding attributes to block and span level
+elements (the naming is also taken from Maruku). This block level element is used to define
+attributes which can be referenced later. The [Block Inline Attribute
+List](#block-inline-attribute-lists) is used to attach attributes to a block level element and the
+[Span Inline Attribute List](#span-inline-attribute-lists) is used to attach attributes to a span
+level element.
+
+Following are some examples of attribute list definitions (ALDs) and afterwards comes the syntax
+explanation:
+
+    {:ref-name: #myid .my-class}
+    {:other: ref-name #id-of-other title="hallo you"}
+    {:test: key="value \" with quote" and other='quote brace \}'}
+
+An ALD line has the following structure:
+
+* a left brace, optionally preceded by up to three spaces,
+* followed by a colon, the reference name and another colon,
+* followed by attribute definitions (allowed characters are backslash-escaped closing braces or any
+  character except a not escaped closing brace),
+* followed by a closing brace and optional spaces until the end of the line.
+
+The reference name needs to start with a word character or a digit, optionally followed by other word
+characters, digits or dashes.
+
+There are four different types of attribute definitions which have to be separated by one or more
+spaces:
+
+references
+
+:   This must be a valid reference name. It is used to reference an other ALD so that the attributes
+    of the other ALD are also included in this one. The reference name is ignored when collecting the
+    attributes if no attribute definition list with this reference name exists. For example, a
+    simple reference looks like `id`.
+
+key-value pairs
+
+:   A key-value pair is defined by a key name, which must follow the rules for reference names, then
+    an equal sign and then the value in single or double quotes. If you need to use the value
+    delimiter (a single or a double quote) inside the value, you need to escape it with a backslash.
+    Key-value pairs can be used to specify arbitrary attributes for block or span level elements. For
+    example, a key-value pair looks like `key1="bef \"quoted\" aft"` or `title='This is a title'`.
+
+ID name
+
+:   An ID name is defined by using a hash and then the identifier name which must follow the rules
+    for reference names. This is a short hand for the key-value pair `id="IDNAME"` since this is
+    often used. The ID name specifies the unique ID of a block or span level element. For example,
+    an ID name looks like `#myid`.
+
+class names
+
+:   A class name is defined by using a dot and then the class name. This is (almost, but not quite)
+    a short hand for the key-value pair `class="class-name"`. Almost because it actually means that
+    the class name should be appended to the current value of the `class` attribute. The following
+    ALDs are all equivalent:
+
+        {:id: .cls1 .cls2}
+        {:id: class="cls1" .cls2}
+        {:id: class="something" class="cls1" .cls2}
+        {:id: class="cls1 cls2}
+
+As can be seen from the example of the class names, attributes that are defined earlier are
+overwritten by ones with the same name defined later. Also, everything in the attribute definitions
+part that does not match one of the above four types is ignored.
+
+If there is more than one ALD with the same reference name, the attribute definitions of all the
+ALDs are processed like they are defined in one ALD.
+
+
+## Inline Attribute Lists
+
+These elements are used to attach attributes to another element.
+
+### Block Inline Attribute Lists
+
+> This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
+> the [Maruku] package.
+{: .markdown-difference}
+
+This block level element is used to attach attributes to a block level element. A block inline
+attribute list (block IAL) has the same structure as an [ALD](#attribute-list-definitions) except
+that the colon/reference name/colon part is replaced by a colon. A block IAL (or two or more block
+IALs) has to be put directly before or after the block level element to which the attributes should
+be attached. If a block IAL is directly after *and* before a block level element, it is applied to
+preceding element. The block IAL is ignored in all other cases, for example, when the block IAL is
+surrounded by blank lines.
+
+Key-value pairs of an IAL take precedence over equally named key-value pairs in referenced ALDs.
+
+Here are some examples for block IALs:
+
+    A simple paragraph with an ID attribute.
+    {: #para-one}
+
+    > A blockquote with a title
+    {:title="The blockquote title"}
+    {: #myid}
+
+    {:.ruby}
+        Some code here
+
+### Span Inline Attribute Lists
 
 > This syntax feature is not part of the original Markdown syntax. The idea and syntax comes from
 > the [Maruku] package.
@@ -1442,10 +1437,85 @@ name, all footnote definitions but the last are ignored.
 
 This is a version of the [block inline attribute list](#block-inline-attribute-lists) for span level
 elements. It has the same structure as the block IAL except that leading and trailing spaces are not
-allowed. A span IAL (or two or more span IALs) has to be put directly after the span level element,
-no additional character is allowed between.
+allowed. A span IAL (or two or more span IALs) has to be put directly after the span level element
+to which it should be applied, no additional character is allowed between, otherwise it is ignored
+and only removed from the output.
 
 Here are some examples for span IALs:
 
     This *is*{:.underline} some `code`{:#id}{:.class}.
     A [link](test.html){:rel='something'} and some **tools**{:.tools}.
+
+
+## Extensions
+
+> This syntax feature is not part of the original Markdown syntax.
+{: .markdown-difference}
+
+Extensions provide additional functionality but use the same syntax for it. They are available as
+block as well as span level elements.
+
+The syntax for an extension is very similar to the syntax of [ALDs](#attribute-list-definitions).
+Here are some examples of how to specify extensions and afterwards is the syntax definition:
+
+    {::comment}
+    This text is completely ignored by kramdown - a comment in the text.
+    {:/comment}
+
+    Do you see {::comment}this text{:/comment}?
+    {::comment}some other comment{:/}
+
+    {::options key="val" /}
+
+An extension can be specified with or without a body. Therefore there exist a start and an end tag
+for extensions. The start tag has the following structure:
+
+* an left brace,
+* followed by two colons and the extension name,
+* optionally followed by a space and attribute definitions (allowed characters are backslash-escaped
+  closing braces or any character except a not escaped closing brace -- same as with ALDs),
+* followed by a slash and a right brace (in case the extension has no body) or only a right
+  brace (in case the extension has a body).
+
+The stop tag has the following structure:
+
+* a left brace,
+* followed by a colon and a slash,
+* optionally followed by the extension name,
+* followed by a right brace.
+
+A stop tag is only needed if the extension has a body!
+
+The above syntax can be used as is for span level extensions. The starting and ending lines for block level
+extensions are defined as:
+
+* The starting line consists of the extension start tag, optionally preceded by up to three spaces,
+  and followed by optional spaces until the end of the line.
+* The ending line consists of the extension stop tag, optionally preceded by up to three spaces,
+  and followed by optional spaces until the end of the line.
+
+If no end tag can be found for an extension start tag, the start tag is treated as if it has no
+body. If an invalid extension stop tag is found, it is ignored. If an invalid extension name is
+specified the extension (and the eventually specified body) are ignored.
+
+The following extensions can be used with kramdown:
+
+`comment`
+
+:   Treat the body text as a comment which does not show in the output.
+
+`nomarkdown`
+
+:   Don't process the body with kramdown but output it as-is.
+
+`options`
+
+:   Should be used without a body since the body is ignored. Is used for setting the global options
+    for the kramdown processor (for example, to disable automatic header ID generation). Note that
+    options that are used by the parser are immediately effective whereas all other options are not!
+    This means, for example, that it is not possible to set converter options only for some part of
+    a kramdown document.
+
+
+
+{include_file: doc/links.markdown}