From: Armin Ronacher <armin.ronacher@active-4.com>
Date: Sun, 27 Apr 2008 19:42:57 +0000 (+0200)
Subject: bootstrapped new documentation
X-Git-Tag: 2.0rc1~128
X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=083ae16362d96aa9469394cbe74f06379371960f;p=jinja2.git

bootstrapped new documentation

--HG--
branch : trunk
---

diff --git a/docs/Makefile b/docs/Makefile
new file mode 100644
index 0000000..e9c11d0
--- /dev/null
+++ b/docs/Makefile
@@ -0,0 +1,70 @@
+# Makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line.
+SPHINXOPTS    =
+SPHINXBUILD   = sphinx-build
+PAPER         =
+
+# Internal variables.
+PAPEROPT_a4     = -D latex_paper_size=a4
+PAPEROPT_letter = -D latex_paper_size=letter
+ALLSPHINXOPTS   = -d _build/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
+
+.PHONY: help clean html web pickle htmlhelp latex changes linkcheck
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html      to make standalone HTML files"
+	@echo "  pickle    to make pickle files (usable by e.g. sphinx-web)"
+	@echo "  htmlhelp  to make HTML files and a HTML help project"
+	@echo "  latex     to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
+	@echo "  changes   to make an overview over all changed/added/deprecated items"
+	@echo "  linkcheck to check all external links for integrity"
+
+clean:
+	-rm -rf _build/*
+
+html:
+	mkdir -p _build/html _build/doctrees
+	$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) _build/html
+	@echo
+	@echo "Build finished. The HTML pages are in _build/html."
+
+pickle:
+	mkdir -p _build/pickle _build/doctrees
+	$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) _build/pickle
+	@echo
+	@echo "Build finished; now you can process the pickle files or run"
+	@echo "  sphinx-web _build/pickle"
+	@echo "to start the sphinx-web server."
+
+web: pickle
+
+htmlhelp:
+	mkdir -p _build/htmlhelp _build/doctrees
+	$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) _build/htmlhelp
+	@echo
+	@echo "Build finished; now you can run HTML Help Workshop with the" \
+	      ".hhp project file in _build/htmlhelp."
+
+latex:
+	mkdir -p _build/latex _build/doctrees
+	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex
+	@echo
+	@echo "Build finished; the LaTeX files are in _build/latex."
+	@echo "Run \`make all-pdf' or \`make all-ps' in that directory to" \
+	      "run these through (pdf)latex."
+
+changes:
+	mkdir -p _build/changes _build/doctrees
+	$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) _build/changes
+	@echo
+	@echo "The overview file is in _build/changes."
+
+linkcheck:
+	mkdir -p _build/linkcheck _build/doctrees
+	$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) _build/linkcheck
+	@echo
+	@echo "Link check complete; look for any errors in the above output " \
+	      "or in _build/linkcheck/output.txt."
diff --git a/docs/conf.py b/docs/conf.py
new file mode 100644
index 0000000..b81ae0a
--- /dev/null
+++ b/docs/conf.py
@@ -0,0 +1,141 @@
+# -*- coding: utf-8 -*-
+#
+# Jinja2 documentation build configuration file, created by
+# sphinx-quickstart on Sun Apr 27 21:42:41 2008.
+#
+# This file is execfile()d with the current directory set to its containing dir.
+#
+# The contents of this file are pickled, so don't put values in the namespace
+# that aren't pickleable (module imports are okay, they're removed automatically).
+#
+# All configuration values have a default value; values that are commented out
+# serve to show the default value.
+
+import sys, os
+
+# If your extensions are in another directory, add it here. If the directory
+# is relative to the documentation root, use os.path.abspath to make it
+# absolute, like shown here.
+#sys.path.append(os.path.abspath('some/directory'))
+
+# General configuration
+# ---------------------
+
+# Add any Sphinx extension module names here, as strings. They can be extensions
+# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+#extensions = []
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix of source filenames.
+source_suffix = '.rst'
+
+# The master toctree document.
+master_doc = 'index'
+
+# General substitutions.
+project = 'Jinja2'
+copyright = '2008, Armin Ronacher'
+
+# The default replacements for |version| and |release|, also used in various
+# other places throughout the built documents.
+#
+# The short X.Y version.
+version = '2.0'
+# The full version, including alpha/beta/rc tags.
+release = '2.0'
+
+# There are two options for replacing |today|: either, you set today to some
+# non-false value, then it is used:
+#today = ''
+# Else, today_fmt is used as the format for a strftime call.
+today_fmt = '%B %d, %Y'
+
+# List of documents that shouldn't be included in the build.
+#unused_docs = []
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+#add_function_parentheses = True
+
+# If true, the current module name will be prepended to all description
+# unit titles (such as .. function::).
+#add_module_names = True
+
+# If true, sectionauthor and moduleauthor directives will be shown in the
+# output. They are ignored by default.
+#show_authors = False
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+
+# Options for HTML output
+# -----------------------
+
+# The style sheet to use for HTML and HTML Help pages. A file of that name
+# must exist either in Sphinx' static/ path, or in one of the custom paths
+# given in html_static_path.
+html_style = 'default.css'
+
+# The name for this set of Sphinx documents.  If None, it defaults to
+# "<project> v<release> documentation".
+#html_title = None
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
+# using the given strftime format.
+html_last_updated_fmt = '%b %d, %Y'
+
+# If true, SmartyPants will be used to convert quotes and dashes to
+# typographically correct entities.
+#html_use_smartypants = True
+
+# Custom sidebar templates, maps document names to template names.
+#html_sidebars = {}
+
+# Additional templates that should be rendered to pages, maps page names to
+# template names.
+#html_additional_pages = {}
+
+# If false, no module index is generated.
+#html_use_modindex = True
+
+# If true, the reST sources are included in the HTML build as _sources/<name>.
+#html_copy_source = True
+
+# If true, an OpenSearch description file will be output, and all pages will
+# contain a <link> tag referring to it.
+#html_use_opensearch = False
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'Jinja2doc'
+
+
+# Options for LaTeX output
+# ------------------------
+
+# The paper size ('letter' or 'a4').
+#latex_paper_size = 'letter'
+
+# The font size ('10pt', '11pt' or '12pt').
+#latex_font_size = '10pt'
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title, author, document class [howto/manual]).
+latex_documents = [
+  ('index', 'Jinja2.tex', 'Jinja2 Documentation', 'Armin Ronacher', 'manual'),
+]
+
+# Additional stuff for the LaTeX preamble.
+#latex_preamble = ''
+
+# Documents to append as an appendix to all manuals.
+#latex_appendices = []
+
+# If false, no module index is generated.
+#latex_use_modindex = True
diff --git a/docs/generate.py b/docs/generate.py
deleted file mode 100755
index 8d9f3a0..0000000
--- a/docs/generate.py
+++ /dev/null
@@ -1,325 +0,0 @@
-#!/usr/bin/env python
-# -*- coding: utf-8 -*-
-"""
-    Generate Jinja Documentation
-    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-    Generates a bunch of html files containing the documentation.
-
-    :copyright: 2006-2007 by Armin Ronacher, Georg Brandl.
-    :license: BSD, see LICENSE for more details.
-"""
-import os
-import sys
-sys.path.insert(0, os.path.join(os.path.dirname(__file__), '..'))
-import re
-import inspect
-from datetime import datetime
-from cgi import escape
-
-from docutils import nodes
-from docutils.parsers.rst import directives
-from docutils.core import publish_parts
-from docutils.writers import html4css1
-
-from jinja import Environment
-
-from pygments import highlight
-from pygments.lexers import get_lexer_by_name
-from pygments.formatters import HtmlFormatter
-
-def generate_list_of_filters():
-    from jinja.filters import FILTERS
-    result = []
-
-    filters = {}
-    for name, f in FILTERS.iteritems():
-        if not f in filters:
-            filters[f] = ([name], inspect.getdoc(f))
-        else:
-            filters[f][0].append(name)
-    for names, _ in filters.itervalues():
-        names.sort(key=lambda x: -len(x))
-
-    for names, doc in sorted(filters.values(), key=lambda x: x[0][0].lower()):
-        name = names[0]
-        if len(names) > 1:
-            aliases = '\n\n    :Aliases: %s\n' % ', '.join(names[1:])
-        else:
-            aliases = ''
-
-        doclines = []
-        for line in doc.splitlines():
-            doclines.append('    ' + line)
-        doc = '\n'.join(doclines)
-        result.append('`%s`\n%s%s' % (name, doc, aliases))
-
-    return '\n'.join(result)
-
-def generate_list_of_tests():
-    from jinja.tests import TESTS
-    result = []
-
-    tests = {}
-    for name, f in TESTS.iteritems():
-        if not f in tests:
-            tests[f] = ([name], inspect.getdoc(f))
-        else:
-            tests[f][0].append(name)
-    for names, _ in tests.itervalues():
-        names.sort(key=lambda x: -len(x))
-
-    for names, doc in sorted(tests.values(), key=lambda x: x[0][0].lower()):
-        name = names[0]
-        if len(names) > 1:
-            aliases = '\n\n    :Aliases: %s\n' % ', '.join(names[1:])
-        else:
-            aliases = ''
-
-        doclines = []
-        for line in doc.splitlines():
-            doclines.append('    ' + line)
-        doc = '\n'.join(doclines)
-        result.append('`%s`\n%s%s' % (name, doc, aliases))
-
-    return '\n'.join(result)
-
-def generate_list_of_loaders():
-    from jinja import loaders as loader_module
-
-    result = []
-    loaders = []
-    for item in loader_module.__all__:
-        loaders.append(getattr(loader_module, item))
-    loaders.sort(key=lambda x: x.__name__.lower())
-
-    for loader in loaders:
-        doclines = []
-        for line in inspect.getdoc(loader).splitlines():
-            doclines.append('    ' + line)
-        result.append('`%s`\n%s' % (loader.__name__, '\n'.join(doclines)))
-
-    return '\n\n'.join(result)
-
-def generate_list_of_baseloaders():
-    from jinja import loaders as loader_module
-
-    result = []
-    loaders = []
-    for item in dir(loader_module):
-        obj = getattr(loader_module, item)
-        try:
-            if issubclass(obj, loader_module.BaseLoader) and \
-               obj.__name__ != 'BaseLoader' and \
-               obj.__name__ not in loader_module.__all__:
-                loaders.append(obj)
-        except TypeError:
-            pass
-    loaders.sort(key=lambda x: x.__name__.lower())
-
-    for loader in loaders:
-        doclines = []
-        for line in inspect.getdoc(loader).splitlines():
-            doclines.append('    ' + line)
-        result.append('`%s`\n%s' % (loader.__name__, '\n'.join(doclines)))
-
-    return '\n\n'.join(result)
-
-def generate_environment_doc():
-    from jinja.environment import Environment
-    return '%s\n\n%s' % (
-        inspect.getdoc(Environment),
-        inspect.getdoc(Environment.__init__)
-    )
-
-e = Environment()
-
-PYGMENTS_FORMATTER = HtmlFormatter(style='pastie', cssclass='syntax')
-
-LIST_OF_FILTERS = generate_list_of_filters()
-LIST_OF_TESTS = generate_list_of_tests()
-LIST_OF_LOADERS = generate_list_of_loaders()
-LIST_OF_BASELOADERS = generate_list_of_baseloaders()
-ENVIRONMENT_DOC = generate_environment_doc()
-CHANGELOG = file(os.path.join(os.path.dirname(__file__), os.pardir, 'CHANGES'))\
-            .read().decode('utf-8')
-
-FULL_TEMPLATE = e.from_string('''\
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
-   "http://www.w3.org/TR/html4/strict.dtd">
-<html>
-<head>
-  <title>{{ title }} &mdash; Jinja Documentation</title>
-  <meta http-equiv="content-type" content="text/html; charset=utf-8">
-  <link rel="stylesheet" href="style.css" type="text/css">
-  <style type="text/css">
-    {{ style|e }}
-  </style>
-</head>
-<body>
-  <div id="content">
-    {% if file_id == 'index' %}
-      <div id="jinjalogo"></div>
-      <h2 class="subheading plain">{{ title }}</h2>
-    {% else %}
-      <h1 class="heading"><span>Jinja</span></h1>
-      <h2 class="subheading">{{ title }}</h2>
-    {% endif %}
-    {% if file_id != 'index' or toc %}
-    <div id="toc">
-      <h2>Navigation</h2>
-      <ul>
-        <li><a href="index.html">back to index</a></li>
-      </ul>
-      {% if toc %}
-        <h2>Contents</h2>
-        <ul class="contents">
-        {% for key, value in toc %}
-          <li><a href="{{ key }}">{{ value }}</a></li>
-        {% endfor %}
-        </ul>
-      {% endif %}
-    </div>
-    {% endif %}
-    <div id="contentwrapper">
-      {{ body }}
-    </div>
-  </div>
-</body>
-<!-- generated on: {{ generation_date }}
-     file id: {{ file_id }} -->
-</html>\
-''')
-
-PREPROC_TEMPLATE = e.from_string('''\
-<!-- TITLE -->{{ title }}<!-- ENDTITLE -->
-<!-- TOC -->{% for key, value in toc %}<li><a href="{{
-    key }}">{{ value }}</a></li>{% endfor %}<!-- ENDTOC -->
-<!-- BODY -->{{ body }}<!-- ENDBODY -->\
-''')
-
-def pygments_directive(name, arguments, options, content, lineno,
-                      content_offset, block_text, state, state_machine):
-    try:
-        lexer = get_lexer_by_name(arguments[0])
-    except ValueError:
-        # no lexer found
-        lexer = get_lexer_by_name('text')
-    parsed = highlight(u'\n'.join(content), lexer, PYGMENTS_FORMATTER)
-    return [nodes.raw('', parsed, format="html")]
-pygments_directive.arguments = (1, 0, 1)
-pygments_directive.content = 1
-directives.register_directive('sourcecode', pygments_directive)
-
-
-def create_translator(link_style):
-    class Translator(html4css1.HTMLTranslator):
-        def visit_reference(self, node):
-            refuri = node.get('refuri')
-            if refuri is not None and '/' not in refuri and refuri.endswith('.txt'):
-                node['refuri'] = link_style(refuri[:-4])
-            html4css1.HTMLTranslator.visit_reference(self, node)
-    return Translator
-
-
-class DocumentationWriter(html4css1.Writer):
-
-    def __init__(self, link_style):
-        html4css1.Writer.__init__(self)
-        self.translator_class = create_translator(link_style)
-
-    def translate(self):
-        html4css1.Writer.translate(self)
-        # generate table of contents
-        contents = self.build_contents(self.document)
-        contents_doc = self.document.copy()
-        contents_doc.children = contents
-        contents_visitor = self.translator_class(contents_doc)
-        contents_doc.walkabout(contents_visitor)
-        self.parts['toc'] = self._generated_toc
-
-    def build_contents(self, node, level=0):
-        sections = []
-        i = len(node) - 1
-        while i >= 0 and isinstance(node[i], nodes.section):
-            sections.append(node[i])
-            i -= 1
-        sections.reverse()
-        toc = []
-        for section in sections:
-            try:
-                reference = nodes.reference('', '', refid=section['ids'][0], *section[0])
-            except IndexError:
-                continue
-            ref_id = reference['refid']
-            text = escape(reference.astext().encode('utf-8'))
-            toc.append((ref_id, text))
-
-        self._generated_toc = [('#%s' % href, caption) for href, caption in toc]
-        # no further processing
-        return []
-
-
-def generate_documentation(data, link_style):
-    writer = DocumentationWriter(link_style)
-    data = data.replace('[[list_of_filters]]', LIST_OF_FILTERS)\
-               .replace('[[list_of_tests]]', LIST_OF_TESTS)\
-               .replace('[[list_of_loaders]]', LIST_OF_LOADERS)\
-               .replace('[[list_of_baseloaders]]', LIST_OF_BASELOADERS)\
-               .replace('[[environment_doc]]', ENVIRONMENT_DOC)\
-               .replace('[[changelog]]', CHANGELOG)
-    parts = publish_parts(
-        data,
-        writer=writer,
-        settings_overrides={
-            'initial_header_level': 2,
-            'field_name_limit': 50,
-        }
-    )
-    return {
-        'title':        parts['title'].encode('utf-8'),
-        'body':         parts['body'].encode('utf-8'),
-        'toc':          parts['toc']
-    }
-
-
-def handle_file(filename, fp, dst, preproc):
-    now = datetime.now()
-    title = os.path.basename(filename)[:-4]
-    content = fp.read().decode('utf-8')
-    suffix = not preproc and '.html' or ''
-    parts = generate_documentation(content, (lambda x: './%s%s' % (x, suffix)))
-    result = file(os.path.join(dst, title + '.html'), 'w')
-    c = dict(parts)
-    c['style'] = PYGMENTS_FORMATTER.get_style_defs('.syntax')
-    c['generation_date'] = now
-    c['file_id'] = title
-    if preproc:
-        tmpl = PREPROC_TEMPLATE
-    else:
-        tmpl = FULL_TEMPLATE
-    result.write(tmpl.render(c).encode('utf-8'))
-    result.close()
-
-
-def run(dst, preproc, sources=(), handle_file=handle_file):
-    path = os.path.abspath(os.path.join(os.path.dirname(__file__), 'src'))
-    if not sources:
-        sources = [os.path.join(path, fn) for fn in os.listdir(path)]
-    for fn in sources:
-        if not os.path.isfile(fn):
-            continue
-        print 'Processing %s' % fn
-        f = open(fn)
-        try:
-            handle_file(fn, f, dst, preproc)
-        finally:
-            f.close()
-
-
-def main(dst='html/', preproc=False, *sources):
-    run(os.path.realpath(dst), str(preproc).lower() == 'true', sources)
-
-
-if __name__ == '__main__':
-    main(*sys.argv[1:])
diff --git a/docs/html/jinjabanner.png b/docs/html/jinjabanner.png
deleted file mode 100644
index c672118..0000000
Binary files a/docs/html/jinjabanner.png and /dev/null differ
diff --git a/docs/html/jinjalogo.png b/docs/html/jinjalogo.png
deleted file mode 100644
index 17d6dc3..0000000
Binary files a/docs/html/jinjalogo.png and /dev/null differ
diff --git a/docs/html/style.css b/docs/html/style.css
deleted file mode 100644
index 64cba24..0000000
--- a/docs/html/style.css
+++ /dev/null
@@ -1,196 +0,0 @@
-body {
-    background-color: #333;
-    margin: 0;
-    padding: 0;
-    font-family: 'Georgia', serif;
-    font-size: 15px;
-    color: #111;
-}
-
-#content {
-    background-color: white;
-    background-image: url(watermark.png);
-    padding: 10px;
-    margin: 25px;
-    border: 4px solid #ddd;
-}
-
-h1 {
-    margin: 0;
-    padding: 0;
-    height: 80px;
-    background-image: url(jinjabanner.png);
-    background-repeat: no-repeat;
-}
-
-h1 span {
-    display: none;
-}
-
-h2.subheading {
-    margin: -55px 0 35px 200px;
-    font-weight: normal;
-    font-size: 30px;
-    color: #444;
-}
-
-h2.plain {
-    margin: 0;
-}
-
-#jinjalogo {
-    background-image: url(jinjalogo.png);
-    background-repeat: no-repeat;
-    width: 400px;
-    height: 160px;
-}
-
-#contentwrapper {
-    max-width: 700px;
-    padding: 0 0 20px 18px;
-}
-
-#contentwrapper h3,
-#contentwrapper h3 a {
-    color: #b41717;
-    font-size: 26px;
-    margin: 20px 0 0 -5px;
-}
-
-#contentwrapper h4,
-#contentwrapper h4 a {
-    color: #b41717;
-    font-size: 20px;
-    margin: 20px 0 0 0;
-}
-
-table.docutils {
-    border-collapse: collapse;
-    border: 2px solid #aaa;
-    margin: 0.5em 1.5em 0.5em 1.5em;
-}
-
-table.docutils td {
-    padding: 2px;
-    border: 1px solid #ddd;
-}
-
-p, li, dd, dt, blockquote {
-    color: #333;
-}
-
-p {
-    line-height: 150%;
-    margin-bottom: 0;
-    margin-top: 10px;
-    text-align: justify;
-}
-
-hr {
-    border-top: 1px solid #ccc;
-    border-bottom: 0;
-    border-right: 0;
-    border-left: 0;
-    margin-bottom: 10px;
-    margin-top: 20px;
-}
-
-dl {
-    margin-left: 10px;
-}
-
-li, dt {
-    margin-top: 5px;
-}
-
-dt {
-    font-weight: bold;
-}
-
-th {
-    text-align: left;
-    padding: 3px;
-    background-color: #f2f2f2;
-}
-
-a {
-    color: #b41717;
-}
-
-a:hover {
-    color: #444;
-}
-
-pre {
-    background-color: #f9f9f9;
-    border-top: 1px solid #ccc;
-    border-bottom: 1px solid #ccc;
-    padding: 5px;
-    font-size: 13px;
-    font-family: 'Bitstream Vera Sans Mono', 'Monaco', monospace;
-}
-
-tt {
-    font-size: 13px;
-    font-family: 'Bitstream Vera Sans Mono', 'Monaco', monospace;
-    color: black;
-    padding: 1px 2px 1px 2px;
-    background-color: #f0f0f0;
-}
-
-cite {
-    /* abusing <cite>, it's generated by ReST for `x` */
-    font-size: 13px;
-    font-family: 'Bitstream Vera Sans Mono', 'Monaco', monospace;
-    font-weight: bold;
-    font-style: normal;
-}
-
-div.admonition {
-    margin: 10px 0 10px 0;
-    padding: 10px;
-    border: 1px solid #ccc;
-    background-color: #f8f8f8;
-}
-
-div.admonition p.admonition-title {
-    margin: -3px 0 5px 0;
-    font-weight: bold;
-    color: #b41717;
-    font-size: 16px;
-}
-
-div.admonition p {
-    margin: 0 0 0 40px;
-}
-
-#toc {
-    margin: 0 -10px 10px 15px;
-    padding: 10px;
-    width: 200px;
-    float: right;
-    background-color: #f8f8f8;
-    border: 1px solid #ccc;
-    border-right: none;
-}
-
-#toc h2 {
-    font-size: 20px;
-    margin: 0 0 10px 0;
-    padding: 0;
-    color: #444;
-}
-
-#toc ul {
-    margin: 0 0 0 30px;
-    padding: 0;
-}
-
-#toc ul + h2 {
-    margin-top: 10px;
-}
-
-#toc ul li {
-    padding: 0;
-    margin: 2px 0 2px 0;
-}
diff --git a/docs/html/watermark.png b/docs/html/watermark.png
deleted file mode 100644
index 297d899..0000000
Binary files a/docs/html/watermark.png and /dev/null differ
diff --git a/docs/index.rst b/docs/index.rst
new file mode 100644
index 0000000..34458f2
--- /dev/null
+++ b/docs/index.rst
@@ -0,0 +1,19 @@
+.. Jinja2 documentation master file, created by sphinx-quickstart on Sun Apr 27 21:42:41 2008.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Welcome to Jinja2's documentation!
+==================================
+
+Contents:
+
+.. toctree::
+   :maxdepth: 2
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`
+
diff --git a/docs/src/altsyntax.txt b/docs/src/altsyntax.txt
deleted file mode 100644
index 0f7242f..0000000
--- a/docs/src/altsyntax.txt
+++ /dev/null
@@ -1,109 +0,0 @@
-==================
-Alternative Syntax
-==================
-
-Jinja allows some syntax customization for the block delimiters. Depending on
-the Jinja release more or less combinations are possible. The idea of an
-customizable syntax is that you can update existing templates from other
-template engines and programming languages easier and that you can replace
-the django like default delimiters which are not everybody's favorite.
-
-
-Configuring The Environment
-===========================
-
-For syntax configuration there are six arguments in the environment which
-are the first six for convenience. Thus those two snippets do the same:
-
-.. sourcecode:: python
-
-    env = Environment(
-         block_start_string='{%',
-         block_end_string='%}',
-         variable_start_string='{{',
-         variable_end_string='}}',
-         comment_start_string='{#',
-         comment_end_string='#}',
-    )
-
-    env = Environment('{%', '%}', '{{', '}}', '{#', '#]')
-
-
-Ruby Like Syntax
-----------------
-
-Here an example configuration for Ruby-like syntax:
-
-.. sourcecode:: python
-
-    env = Environment('<%', '%>', '<%=', '%>', '<%#', '%>')
-
-An example template then looks like this:
-
-.. sourcecode:: rhtml
-
-    <%# example eruby like configuration for Jinja %>
-    <ul>
-    <% for item in seq %>
-      <li><%= item %></li>
-    <% end‭for %>
-    </ul>
-
-
-SGML Comment Syntax
--------------------
-
-Here an example configuration that uses SGML comments to hide the
-processing instructions. This can be useful if you work with an WYSIWYG
-designer:
-
-.. sourcecode:: python
-
-    env = Environment('<!--', '-->', '${', '}', '<!--#', '-->')
-
-.. sourcecode:: html
-
-    <!--# example SGML comment configuration for Jinja -->
-    <ul>
-    <!-- for item in seq -->
-      <li>${item}</li>
-    <!-- endfor -->
-    </ul>
-
-
-Parenthesis Balancing
----------------------
-
-Starting with Jinja 1.1 it's possible to use the block delimiter as a token
-in the expression. That means that you can use small delimiters like single
-braces or parenthesis. So if you want to have your variables to look like
-``${expr}`` and you still want to use dicts in such expressions you need
-Jinja 1.1 or higher.
-
-
-Block / Variable Tag Unification
-================================
-
-If variable end and start tags are `None` or look the same as block tags and
-you're running Jinja 1.1 or later the parser will switch into the
-`no_comment_block` mode. In that mode it will try to match something as block
-first and continue treating it as variable block if there is no known
-directive for that name. Example:
-
-.. sourcecode:: python
-
-    env = Environment('{', '}', None, None, '{*', '*}')
-
-This now allows smarty like templates:
-
-.. sourcecode:: smarty
-
-    {* example smarty-like configuration for Jinja *}
-    {if something == 42}
-        Something is the answer to all questions and stuff like that.
-    {else}
-        Something is {something}.
-    {endif}
-
-This feature however can cause strange looking templates because there is no
-visible difference between blocks and variables.
diff --git a/docs/src/api.txt b/docs/src/api.txt
deleted file mode 100644
index 5086953..0000000
--- a/docs/src/api.txt
+++ /dev/null
@@ -1,315 +0,0 @@
-=======================
-Context and Environment
-=======================
-
-The two central objects in Jinja are the `Environment` and `Context`. Both
-are designed to be subclassed by applications if they need to extend Jinja.
-
-Environment
-===========
-
-The initialization parameters are already covered in the `Quickstart`_ thus
-not repeated here.
-
-But beside those configurable instance variables there are some functions used
-in the template evaluation code you may want to override:
-
-**def** `parse` *(source, filename)*:
-
-    Parse the sourcecode and return the abstract syntax tree. This tree of
-    nodes is used by the `translators`_ to convert the template into
-    executable source- or bytecode.
-
-**def** `lex` *(source, filename)*:
-
-    Tokenize the given sourcecode and return a generator of tuples in the
-    form ``(lineno, token, value)``. The filename is just used in the
-    exceptions raised.
-    
-    **New in Jinja 1.1**
-
-**def** `from_string` *(source)*:
-
-    Load and parse a template source and translate it into eval-able Python
-    code. This code is wrapped within a `Template` class that allows you to
-    render it.
-
-**def** `get_template` *(name)*:
-
-    Load a template from a loader. If the template does not exist, you will
-    get a `jinja.exceptions.TemplateNotFound` exception.
-
-**def** `to_unicode` *(self, value)*:
-
-    Called to convert variables to unicode. Per default this checks if the
-    value is already unicode. If not it's converted to unicode using the
-    charset defined on the environment.
-
-    Also `None` is converted into an empty string per default.
-
-**def** `get_translator` *(self, context)*:
-
-    Return the translator used for i18n. A translator is an object that
-    provides the two functions ``gettext(string)`` and
-    ``ngettext(singular, plural, n)``. Both of those functions have to
-    behave like the `ugettext` and `nugettext` functions described in the
-    python `gettext documentation`_.
-
-    If you don't provide a translator a default one is used to switch
-    between singular and plural forms.
-
-    Have a look at the `i18n`_ section for more information.
-
-**def** `get_translations` *(self, name)*:
-
-    Get the translations for the template `name`. Only works if a loader
-    is present. See the `i18n`_ section for more details.
-
-**def** `get_translations_for_string` *(self, string)*:
-
-    Get the translations for the string `string`. This works also if no
-    loader is present and can be used to lookup translation strings from
-    templates that are loaded from dynamic resources like databases.
-
-**def** `apply_filters` *(self, value, context, filters)*:
-
-    Now this function is a bit tricky and you usually don't have to override
-    it. It's used to apply filters on a value. The Jinja expression
-    ``{{ foo|escape|replace('a', 'b') }}`` calls the function with the
-    value of `foo` as first parameter, the current context as second and
-    a list of filters as third. The list looks like this:
-
-    .. sourcecode:: python
-
-        [('escape', ()), ('replace', (u'a', u'b'))]
-
-    As you can see the filter `escape` is called without arguments whereas
-    `replace` is called with the two literal strings ``a`` and ``b``, both
-    unicode. The filters for the names are stored on ``self.filters`` in a
-    dict. Missing filters should raise a `FilterNotFound` exception.
-
-    **Warning** this is a Jinja internal method. The actual implementation
-    and function signature might change.
-
-**def** `perform_test` *(self, context, testname, args, value, invert)*:
-
-    Like `apply_filters` you usually don't override this one. It's the
-    callback function for tests (``foo is bar`` / ``foo is not bar``).
-
-    The first parameter is the current contex, the second the name of
-    the test to perform. the third a tuple of arguments, the fourth is
-    the value to test. The last one is `True` if the test was performed
-    with the `is not` operator, `False` if with the `is` operator.
-
-    Missing tests should raise a `TestNotFound` exception.
-
-    **Warning** this is a Jinja internal method. The actual implementation
-    and function signature might change.
-
-**def** `get_attribute` *(self, obj, attribute)*:
-
-    Get `attribute` from the object provided. The default implementation
-    performs security tests.
-
-    **Warning** this is a Jinja internal method. The actual implementation
-    and function signature might change.
-
-**def** `get_attributes` *(self, obj, attributes)*:
-
-    Get some attributes from the object. If `attributes` is an empty
-    sequence the object itself is returned unchanged.
-
-**def** `call_function` *(self, f, context, args, kwargs, dyn_args, dyn_kwargs)*:
-    
-    Call a function `f` with the arguments `args`, `kwargs`, `dyn_args` and
-    `dyn_kwargs` where `args` is a tuple and `kwargs` a dict. If `dyn_args`
-    is not `None` you have to add it to the arguments, if `dyn_kwargs` is
-    not `None` you have to update the `kwargs` with it.
-
-    The default implementation performs some security checks.
-
-    **Warning** this is a Jinja internal method. The actual implementation
-    and function signature might change.
-
-**def** `call_function_simple` *(self, f, context)*:
-
-    Like `call_function` but without arguments.
-
-    **Warning** this is a Jinja internal method. The actual implementation
-    and function signature might change.
-
-**def** `finish_var` *(self, value, ctx)*:
-
-    Postprocess a variable before it's sent to the template.
-
-    **Warning** this is a Jinja internal method. The actual implementation
-    and function signature might change.
-    
-.. admonition:: Note
-
-    The Enviornment class is defined in `jinja.environment.Environment`
-    but imported into the `jinja` package because it's often used.
-
-Context
-=======
-
-Jinja wraps the variables passed to the template in a special class called a
-context. This context supports variables on multiple layers and lazy (deferred)
-objects. Often your application has a request object, database connection
-object or something similar you want to access in filters, functions etc.
-
-The default context object is defined in `jinja.datastructure`. If you want
-to provide your own context object always subclass the default one. This
-ensures that the class continues working after Jinja upgrades.
-
-Beacause of that you can easily subclass a context to add additional variables
-or to change the way it behaves.
-
-**def** `pop` *(self)*:
-
-    Pop the outermost layer and return it.
-
-**def** `push` *(self, data=None)*:
-
-    Push a dict to the stack or an empty layer.
-
-    Has to return the pushed object.
-
-**def** `to_dict` *(self)*:
-
-    Flatten the context and convert it into a dict.
-
-**def** `__getitem__` *(self, name)*:
-
-    Resolve an item. Per default this also resolves `Deferred` objects.
-
-**def** `__setitem__` *(self, name, value)*:
-
-    Set an item in the outermost layer.
-
-**def** `__delitem__` *(self, name)*:
-
-    Delete an item in the outermost layer. Do not raise exceptions if
-    the value does not exist.
-
-**def** `__contains__` *(self, name)*:
-
-    Return `True` if `name` exists in the context.
-
-**attribute** `cache`:
-
-    The cache is a dict which can be used by filters, test functions
-    and global objects to cache data. It's also used by the environment
-    to cache often used tests and filters.
-
-**attribute** `translate_func`:
-
-    This property is created on first access and returns a translation
-    function used by the rendering process to translate strings with the
-    translator defined on the environment.
-
-.. admonition:: Note
-
-    The context uses a stack of dicts internally to represent the
-    layers of variables. It contains at least 3 levels available on
-    the context with some attributes. Those are:
-
-    `globals`:
-        
-        The reference to the global namespace of the environment.
-        It's the lowest namespace on the stack and thus immutable
-
-    `initial`:
-
-        The initial namespace. Contains the values passed to the
-        context in the render function. It also contains the resolved
-        deferred values for bot the `initial` and the `globals`
-        namespace.
-
-    `current`:
-
-        The reference to the current active namespace. When the
-        context is initialized this automatically points to an
-        empty namespace.
-
-    The number of layers on the stack are theoretically unlimited.
-    Some elements in the template language like loops, blocks,
-    macros and others push and pop the layer on entering and leaving
-    the section.
-
-    This is done in order to keep the namespace clean.
-
-    Note that since Jinja 1.1 the context object is a subclass of the
-    `BaseContext`, a much simpler class that just implements a stack
-    like namespace for python. If the `_speedups` extension was
-    compiled for jinja the base class will be
-    `jinja._speedups.BaseContext` otherwise `jinja._native.BaseContext`.
-
-    Since you cannot reproduce completely the same semantics in python
-    and the C API there are some things you should keep in mind:
-
-    -   The `stack` attribute of the context maps to the real layers
-        on the stack, thus you can modify the items but the list as
-        such is meant to be read only.
-
-    -   `globals`, `current` and `initial` are read only attributes that
-        map to layers on the stack which you can of course modify.
-
-
-Exceptions
-==========
-
-During parsing and evaluation Jinja raises a couple of Jinja specific
-exceptions. All of those exceptions are defined in the `jinja.exceptions`
-module and are subclasses of the `TemplateError` class defined there.
-
-Here a list of exceptions that could occur:
-
-`SecurityException`:
-
-    An exception that is raised if the template tried to access something
-    it should not access. In the default configuration this exception
-    will get caught in the Jinja rendering process and silenced.
-
-    If however the environment is configured to not silently fail it
-    could happen that this exception reaches the application.
-
-`FilterNotFound`:
-
-    Raised if the template tried to apply a filter that does not exist.
-    Since this exception is a subclass of `KeyError` too you can catch
-    it this way too.
-
-`FilterArgumentError`:
-
-    Raised if the filter received an argument that it couldn't handle.
-    It's a subclass of `TypeError` too so you can catch it this way too.
-
-`TestNotFound`:
-
-    Raised if the template tried to perform a test that does not exist.
-    Since this exception is a subclass of `KeyError` too you can catch
-    it this way too.
-
-`TestArgumentError`:
-
-    Raised if a test function received an argument that it couldn't handle.
-    It's a subclass of `TypeError` too so you can catch it this way too.
-
-`TemplateNotFound`:
-
-    Raised if a template does not exist. Subclass of `IOError` too.
-
-`TemplateSyntaxError`:
-
-    Subclass of `SyntaxError` and used to indicate an syntax error.
-
-`TemplateRuntimeError`:
-
-    Generic runtime error exception which can occour at various places.
-
-
-.. _i18n: i18n.txt
-.. _translators: translators.txt
-.. _Quickstart: devintro.txt
-.. _gettext documentation: http://docs.python.org/lib/module-gettext.html
diff --git a/docs/src/builtins.txt b/docs/src/builtins.txt
deleted file mode 100644
index 0708077..0000000
--- a/docs/src/builtins.txt
+++ /dev/null
@@ -1,228 +0,0 @@
-===================================
-Filters, Tests and Helper Functions
-===================================
-
-This part of the documentation lists the filter-, test- and helper functions
-you can use in templates.
-
-
-Filters
-=======
-
-In the examples above you might have noticed the pipe symbols. Pipe symbols tell
-the engine that it has to apply a filter on the variable. Here is a small example:
-
-.. sourcecode:: jinja
-
-    {{ variable|replace('foo', 'bar')|escape }}
-
-If you want, you can also put whitespace between the filters.
-
-This will look for a variable `variable`, pass it to the filter `replace`
-with the arguments ``'foo'`` and ``'bar'``, and pass the result to the filter
-`escape` that automatically XML-escapes the value. The `e` filter is an alias for
-`escape`. Here is the complete list of supported filters:
-
-[[list_of_filters]]
-
-.. admonition:: note
-
-    *Jinja 1.0 and 1.1 notice*
-
-    The filter operator has a pretty low priority in Jinja 1.0 and 1.1. If you
-    want to add fitered values you have to put them into parentheses. The same
-    applies if you want to access attributes or return values:
-
-    .. sourcecode:: jinja
-
-        correct:
-            {{ (foo|filter) + (bar|filter) }}
-        wrong:
-            {{ foo|filter + bar|filter }}
-
-        correct:
-            {{ (foo|filter).attribute }}
-        wrong:
-            {{ foo|filter.attribute }}
-
-    This changed in Jinja 1.2, from that version one the filter operator has
-    the highest priority so you can do ``foo|filter + bar|filter``.
-
-*new in Jinja 1.1*:
-
-Because the application can provide additional filters you can get a documentation
-of all the provided filters by calling ``debug.filters()``:
-
-.. sourcecode:: jinja
-
-    {{ debug.filters() }}
-        -> returns a plain text representation of all the filters
-
-    {{ debug.filters(False) }}
-        -> same as above but without the builtin ones.
-
-Tests
-=====
-
-You can use the `is` operator to perform tests on a value:
-
-.. sourcecode:: jinja
-
-    {{ 42 is numeric }} -> true
-    {{ "foobar" is numeric }} -> false
-    {{ 'FOO' is upper }} -> true
-
-These tests are especially useful when used in `if` conditions.
-
-[[list_of_tests]]
-
-*new in Jinja 1.1*:
-
-Because the application can provide additional tests you can get a documentation
-of all the provided tests by calling ``debug.tests()``:
-
-.. sourcecode:: jinja
-
-    {{ debug.tests() }}
-        -> returns a plain text representation of all the tests
-
-    {{ debug.tests(False) }}
-        -> same as above but without the builtin ones.
-
-*new in Jinja 1.2*:
-
-If a test function expects one or no argument you can leave out the parentheses.
-Previously this was only possible for text functions without arguments:
-
-.. sourcecode:: jinja
-
-    {{ foo is matching @/\s+/ }}
-        is the same as
-    {{ foo is matching(@/\s+/) }}
-
-
-Global Functions
-================
-
-Test functions and filter functions live in their own namespace. Global
-functions not. They behave like normal objects in the context. Beside the
-functions added by the application or framewhere there are two functions
-available per default:
-
-`range`
-    
-    Works like the python `range function`_ just that it doesn't support
-    ranges greater than ``1000000``.
-
-`debug`
-
-    Function that outputs the contents of the context.
-
-`lipsum`
-
-    Generate some paragraphs of random text:
-
-    .. sourcecode:: jinja
-
-        {{ lipsum(5) }}
-            five html paragraphs
-
-        {{ lipsum(2, False) }}
-            two ascii only paragraphs
-
-    Per default a paragraph is between 20 and 100 words long. You can
-    override this default with the third and fourth parameter:
-
-    .. sourcecode:: jinja
-
-        {{ lipsum(10, True, 50, 200) }}
-            generate 10 HTML paragraphs between 50 and 200 words.
-
-    *new in Jinja 1.1*
-
-`watchchanges`
-
-    Jinja does not provide an django like ``{% ifchanged %}`` tag. As
-    replacement for this tag there is a special function in the namespace
-    called `watchchanges`.
-
-    You can use it like this:
-
-    .. sourcecode:: html+jinja
-
-        {% for changed, article in watchchanges(articles, 'date', 'day') %}
-            {% if changed %}<h3>{{ articles.date.day }}</h3>{% endif %}
-            <h4>{{ article.title|e }}</h4>
-            <p>{{ article.body|e }}</p>
-        {% endif %}
-
-    For each iteration `watchchanges` will check the given attribute. If it
-    changed to the former iteration the first yielded item (in this example
-    it's called `changed`) will be `true`, else `false`.
-
-    In this example `articles` is a list of articles for the template with
-    an attribute called `date.day` which represents the current day. To only
-    add a new day headline if the day has changed `watchchanges` is now told
-    to check `articles.date.days`.
-
-    If you want to observe more than one attribute you can provide pairs:
-
-    .. sourcecode:: html+jinja
-
-        {% for changed, item in watchchanges(foo, ('a', 'b'), ('a', 'c')) %}
-            ...
-        {% endfor %}
-
-    Note that if you want to watch two first level attributes you have to
-    either use the list syntax `[]` or add a colon:
-
-    .. sourcecode:: html+jinja
-
-        {% for changed, item in watchchanges(foo, ['a'], ('b',)) %}
-            ...
-        {% endfor %}
-
-    otherwise Jinja cannot differ between a pair of parentheses to group
-    expressions or the sequence syntax.
-
-    If you don't provide any arguments the value of the variable itself
-    is checked.
-
-    *new in Jinja 1.1*
-
-`rendertemplate`
-
-    Loads and renders a template with a copy of the current context. This works
-    in many situations like the ``{% include %}`` tag, just that it does not
-    include a template and merges it into the template structure but renders
-    it completely independent and returns the rendered data as string.
-
-    *new in Jinja 1.1*
-
-
-Global Constants
-================
-
-Jinja provides some special variables which cannot be overridden in templates.
-Those are not affected by the variable lookup:
-
-    `_`, `true`, `false`, `none`, `undefined`
-
-You cannot use those names for your own variables or macros. It's however no
-problem to have blocks with that name.
-
-**Notice** due to a bug in Jinja 1.0 it was possible to override `_`, `true`,
-`false`, `none` and `undefined` from the template by either using `{% set %}`
-or in a for loop. While overriding `true`, `false` etc just caused nothing
-overriding the translation marker `_` would crash the translation interface.
-If you want to use `_` for unpacking in for loops (eg. skipping items) you
-have to give it a proper name:
-
-.. sourcecode:: jinja
-
-    {% for key, ignore in mydict|dictsort %}
-        {{ key|e }}
-    {% endfor %}
-
-
-.. _range function: http://docs.python.org/tut/node6.html#SECTION006300000000000000000
diff --git a/docs/src/changelog.txt b/docs/src/changelog.txt
deleted file mode 100644
index 557c248..0000000
--- a/docs/src/changelog.txt
+++ /dev/null
@@ -1 +0,0 @@
-[[changelog]]
diff --git a/docs/src/debugging.txt b/docs/src/debugging.txt
deleted file mode 100644
index e8f432a..0000000
--- a/docs/src/debugging.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-===================
-Debugging Templates
-===================
-
-In order to keep templates debuggable you have to do some additional work on
-the application side. The traceback module that comes with python currently
-does not support the `__loader__` hook which is used by Jinja to provide
-templates. Although the import system was implemented three Python versions
-ago the default traceback system still doesn't support it.
-
-However most of the extended web development traceback modules have support
-for `__loader__`.  Either directly or via the linecache module:
-
--  `Werkzeug Debugging Middleware`_
--  `Django`_
--  `cgitb`_
--  `EvalException`_
-
-To enable debugging you have to use one of those debugging systems or
-implement your own one with support for `__loader__`.
-
-The python implementation of the jinja debugger can only translate the first
-exception in a traceback which can lead to problematic results.  If you have
-the extended debugger c extension compiled (default on unix systems but only
-available on Windows if you have a VisualStudio 2003 installation) all frames
-in the traceback will point to the correct linenumbers of the templates.
-
-
-.. _Werkzeug Debugging Middleware: http://werkzeug.pocoo.org/
-.. _Django: http://www.djangoproject.com/
-.. _cgitb: http://docs.python.org/lib/module-cgitb.html
-.. _EvalException: http://pythonpaste.org/module-paste.evalexception.html
diff --git a/docs/src/designerdoc.txt b/docs/src/designerdoc.txt
deleted file mode 100644
index cc0cbde..0000000
--- a/docs/src/designerdoc.txt
+++ /dev/null
@@ -1,565 +0,0 @@
-======================
-Designer Documentation
-======================
-
-This part of the Jinja documentaton is meant for template designers.
-
-Basics
-======
-
-The Jinja template language is designed to strike a balance between content
-and application logic. Nevertheless you can use a python like statement
-language. You don't have to know how Python works to create Jinja templates,
-but if you know it you can use some additional statements you may know from
-Python.
-
-Here is a small example template:
-
-.. sourcecode:: html+jinja
-
-    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
-     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-    <html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
-    <head>
-        <title>My Webpage</title>
-    </head>
-    <body>
-        <ul id="navigation">
-        {% for item in navigation %}
-            <li><a href="{{ item.href|e }}">{{ item.caption|e }}</a></li>
-        {% endfor %}
-        </ul>
-
-        <h1>My Webpage</h1>
-        {{ variable }}
-    </body>
-    </html>
-
-This covers the default settings. The application developer might have changed
-the syntax from ``{% foo %}`` to ``<% foo %>`` or something similar. This
-documentation just covers the default values.
-
-A variable looks like ``{{ foobar }}`` where foobar is the variable name. Inside
-of statements (``{% some content here %}``) variables are just normal names
-without the braces around it. In fact ``{{ foobar }}`` is just an alias for
-the statement ``{% print foobar %}``.
-
-Variables are coming from the context provided by the application. Normally there
-should be a documentation regarding the context contents but if you want to know
-the content of the current context, you can add this to your template:
-
-.. sourcecode:: html+jinja
-
-    <pre>{{ debug()|e }}</pre>
-
-A context isn't flat which means that each variable can has subvariables, as long
-as it is representable as python data structure. You can access attributes of
-a variable using the dot and bracket operators. The following examples show
-this:
-
-.. sourcecode:: jinja
-
-    {{ user.username }}
-        is the same as
-    {{ user['username'] }}
-        you can also use a variable to access an attribute:
-    {{ users[current_user].username }}
-        If you have numerical indices you have to use the [] syntax:
-    {{ users[0].username }}
-
-*new in Jinja 1.2*: You can now use django like attributes for integer
-indices.  Thus ``{{ foo.0 }}`` is equivalent to ``{{ foo[0] }}``.
-
-
-Loops
-=====
-
-To iterate over a sequence, you can use the `for` loop. It basically looks like a
-normal Python `for` loop and works pretty much the same:
-
-.. sourcecode:: html+jinja
-
-    <h1>Members</h1>
-    <ul>
-    {% for user in users %}
-      <li>{{ loop.index }} / {{ loop.length }} - {{ user.username|escape }}</li>
-    {% else %}
-      <li><em>no users found</em></li>
-    {% endfor %}
-    </ul>
-
-*Important* Contrary to Python is the optional `else` block only
-executed if there was no iteration because the sequence was empty.
-
-Inside of a `for` loop block you can access some special variables:
-
-+----------------------+----------------------------------------+
-| Variable             | Description                            |
-+======================+========================================+
-| `loop.index`         | The current iteration of the loop.     |
-+----------------------+----------------------------------------+
-| `loop.index0`        | The current iteration of the loop,     |
-|                      | starting counting by 0.                |
-+----------------------+----------------------------------------+
-| `loop.revindex`      | The number of iterations from the end  |
-|                      | of the loop.                           |
-+----------------------+----------------------------------------+
-| `loop.revindex0`     | The number of iterations from the end  |
-|                      | of the loop, starting counting by 0.   |
-+----------------------+----------------------------------------+
-| `loop.first`         | True if first iteration.               |
-+----------------------+----------------------------------------+
-| `loop.last`          | True if last iteration.                |
-+----------------------+----------------------------------------+
-| `loop.even`          | True if current iteration is even.     |
-+----------------------+----------------------------------------+
-| `loop.odd`           | True if current iteration is odd.      |
-+----------------------+----------------------------------------+
-| `loop.length`        | Total number of items in the sequence. |
-+----------------------+----------------------------------------+
-| `loop.parent`        | The context of the parent loop.        |
-+----------------------+----------------------------------------+
-
-Loops also support recursion. Let's assume you have a sitemap where each item
-might have a number of child items. A template for that could look like this:
-
-.. sourcecode:: html+jinja
-
-    <h1>Sitemap
-    <ul id="sitemap">
-    {% for item in sitemap recursive %}
-      <li><a href="{{ item.url|e }}">{{ item.title|e }}</a>
-      {% if item.children %}<ul>{{ loop(item.children) }}</ul>{% endif %}</li>
-    {% endfor %}
-    </ul>
-
-What happens here? Basically the first thing that is different to a normal
-loop is the additional ``recursive`` modifier in the `for`-loop declaration.
-It tells the template engine that we want recursion. If recursion is enabled
-the special `loop` variable is callable. If you call it with a sequence it will
-automatically render the loop at that position with the new sequence as argument.
-
-Cycling
-=======
-
-Sometimes you might want to have different text snippets for each row in a list,
-for example to have alternating row colors. You can easily do this by using the
-``{% cycle %}`` tag:
-
-.. sourcecode:: html+jinja
-
-    <ul id="messages">
-    {% for message in messages %}
-      <li class="{% cycle 'row1', 'row2' %}">{{ message|e }}</li>
-    {% endfor %}
-    </ul>
-
-Each time Jinja encounters a `cycle` tag it will cycle through the list
-of given items and return the next one. If you pass it one item jinja assumes
-that this item is a sequence from the context and uses this:
-
-.. sourcecode:: html+jinja
-
-    <li style="color: {% cycle rowcolors %}">...</li>
-
-Conditions
-==========
-
-Jinja supports Python-like `if` / `elif` / `else` constructs:
-
-.. sourcecode:: jinja
-
-    {% if user.active %}
-        user {{ user.name|e }} is active.
-    {% elif user.deleted %}
-        user {{ user.name|e }} was deleted some time ago.
-    {% else %}
-        i don't know what's wrong with {{ user.username|e }}
-    {% endif %}
-
-If the user is active the first block is rendered. If not and the user was
-deleted the second one, in all other cases the third one.
-
-You can also use comparison operators:
-
-.. sourcecode:: html+jinja
-
-    {% if amount < 0 %}
-        <span style="color: red">{{ amount }}</span>
-    {% else %}
-        <span style="color: black">{{ amount }}</span>
-    {% endif %}
-
-.. admonition:: Note
-
-    Of course you can use `or` / `and` and parentheses to create more complex
-    conditions, but usually the logic is already handled in the application and
-    you don't have to create such complex constructs in the template code. However
-    in some situations it might be a good thing to have the abilities to create
-    them.
-
-Literals
-========
-
-For most of the builtin python types, literals exist in Jinja. The following
-table shows which syntax elements are supported:
-
-    ======================= ===================================================
-    ``"text" / 'text'``     work like python's unicode literals (u'text').
-    ``42``                  integer literls.
-    ``42.0``                float literals (exponents are not supported and
-                            before and after the dot digits must be present)
-    ``[1, 'two', none]``    list literal
-    ``(), (1,), (1, 2)``    tuple literals. (tuples work like lists but consume
-                            less memory and are not modifyable.)
-    ``{'foo': 'bar'}``      dictionary literal
-    ``@/expr/flags``        regular expression literals. ``@/expr/flags`` is
-                            equivalent to ``re.compile('(?flags)expr')`` in
-                            python.
-    ``@(1, 2, 3)``          set literal. ``@(1, 2, 3)`` in Jinja is is equal to
-                            ``set([1, 2, 3])`` in python.
-    ``true / false``        corresponds to `True` and `False` in python.
-    ``none``                corresponds to `None` in python.
-    ``undefined``           special Jinja undefined singleton.
-    ======================= ===================================================
-
-.. admonition:: Common Pitfalls
-
-    Keep in mind that Jinja literals, keywords and functions are all lowercase.
-    If you're used to Python you probably tried to write `True` which evaluates
-    to undefined because it simply does not exist.  The correct name for the
-    true value is just `true` (lowercase).
-   
-
-Operators
-=========
-
-Inside ``{{ variable }}`` blocks, `if` conditions and many other parts you can
-can use expressions. In expressions you can use any of the following operators:
-
-    ======= ===================================================================
-    ``+``   add the right operand to the left one.
-            ``{{ 1 + 2 }}`` would return ``3``.
-    ``-``   subtract the right operand from the left one.
-            ``{{ 1 - 1 }}`` would return ``0``.
-    ``/``   divide the left operand by the right one.
-            ``{{ 1 / 2 }}`` would return ``0.5``.
-    ``//``  divide the left operand by the right one and return a truncated
-            integer result: ``{{ 20 // 7 }}`` is ``2``.
-            *added in Jinja 1.1*
-    ``~``   string concatenate a value with another one.  ``{{ foo ~ bar }}``
-            is equivalent to ``{{ foo|string + bar|string }}``.  *added in
-            Jinja 1.1*
-    ``*``   multiply the left operand with the right one.
-            ``{{ 2 * 2 }}`` would return ``4``.
-    ``**``  raise the left operand to the power of the right
-            operand. ``{{ 2**3 }}`` would return ``8``.
-    ``%``   calculate the remainder of an integer division between the
-            left and right operand: ``{{ 11 % 7 }}`` is ``4``.
-    ``in``  perform sequence membership test. ``{{ 1 in [1,2,3] }}`` would
-            return true.
-    ``is``  perform a test on the value. See the section about
-            tests for more information.
-    ``|``   apply a filter on the value. See the section about
-            filters for more information.
-    ``and`` return true if the left and the right operand is true.
-    ``or``  return true if the left or the right operand is true.
-    ``not`` negate a statement (see below)
-    ``()``  call a callable: ``{{ user.get_username() }}``. Inside of the
-            parentheses you can use variables: ``{{ user.get(username) }}``.
-    ======= ===================================================================
-
-Note that there is no support for any bit operations or something similar.
-
-* special note regarding `not`: The `is` and `in` operators support negation
-  using an infix notation too: ``foo is not bar`` and ``foo not in bar``
-  instead of ``not foo is bar`` and ``not foo in bar``. All other expressions
-  require a prefix notation: ``not (foo and bar)``.
-
-
-With Jinja 1.2 onwards it's possible to replace basic if/else blocks with the
-inline `if` / `else` expression.  The following two examples evaluate to the
-same:
-
-.. sourcecode:: jinja
-
-    {{ "something" if expr else "otherthing" }}
-
-    {% if expr %}something{% else %}otherthing{% endif %}
-
-
-Boolean Values
-==============
-
-In If-Conditions Jinja performs a boolean check. All empty values (eg: empty
-lists ``[]``, empty dicts ``{}`` etc) evaluate to `false`. Numbers that are
-equal to `0`/`0.00` are considered `false` too. The boolean value of other
-objects depends on the behavior the application developer gave it. Usually
-items are `true`.
-
-Here some examples that should explain it:
-
-.. sourcecode:: jinja
-
-    {% if [] %}
-        will always be false because it's an empty list
-
-    {% if {} %}
-        false too.
-
-    {% if ['foo'] %}
-        this is true. Because the list is not empty.
-
-    {% if "foobar" %}
-        this is also true because the string is not empty.
-
-Slicing
-=======
-
-Some objects support slicing operations. For example lists:
-
-.. sourcecode:: jinja
-
-    {% for item in items[:5] %}
-        This will only iterate over the first 5 items of the list
-
-    {% for item in items[5:10] %}
-        This will only iterate from item 5 to 10.
-
-    {% for item in items[:10:2] %}
-        This will only yield items from start to ten and only returing
-        even items.
-
-For more informations about slicing have a look at the `slicing chapter`_
-in the "Dive into Python" e-book.
-
-Macros
-======
-
-If you want to use a partial template in more than one place, you might want to
-create a macro from it:
-
-.. sourcecode:: html+jinja
-
-    {% macro show_user user %}
-      <h1>{{ user.name|e }}</h1>
-      <div class="text">
-        {{ user.description }}
-      </div>
-    {% endmacro %}
-
-Now you can use it from everywhere in the code by passing it an item:
-
-.. sourcecode:: jinja
-    
-    {% for user in users %}
-        {{ show_user(user) }}
-    {% endfor %}
-
-You can also specify more than one value:
-
-.. sourcecode:: html+jinja
-
-    {% macro show_dialog title, text %}
-      <div class="dialog">
-        <h1>{{ title|e }}</h1>
-        <div class="text">{{ text|e }}</div>
-      </div>
-    {% endmacro %}
-
-    {{ show_dialog('Warning', 'something went wrong i guess') }}
-
-*Improvements in Jinja 1.1*:
-
-    Starting with Jinja 1.1 it's possible to use optional parentheses
-    around the macro arguments:
-
-    .. sourcecode:: html+jinja
-
-        {% macro foo(a, b) %}
-            ...
-        {% endmacro %}
-
-    Additionally extra arguments passed to the macro end up in the
-    special variable `varargs`. So you can have a macro like this:
-
-    .. sourcecode:: html+jinja
-
-        {% macro make_list() %}
-          {% if varargs %}
-          <ul>
-            {% for item in varargs %}
-            <li>{{ item|e }}</li>
-            {% endfor %}
-          </ul>
-          {% endif %}
-        {% endmacro %}
-
-        {{ make_list("John", "Jane", "Marcus", "Heinrich") }}
-
-    If a macro parameter is called `varargs` the additional extra
-    arguments are not accessible.
-
-For information regarding the visibility of macros have a look at the
-`Scopes and Variable Behavior`_ section.
-
-
-Extended Macro Call
-===================
-
-*new in Jinja 1.1*
-
-Jinja 1.1 adds a new special tag that you can use to pass some evaluable
-template code to a macro. Here an example macro that uses the features of
-the ``{% call %}`` tag:
-
-.. sourcecode:: html+jinja
-
-    {% macro dialog title %}
-      <div class="dialog">
-        <h3>{{ title }}</h3>
-        <div class="text">
-          {{ caller() }}
-        </div>
-      </div>
-    {% endmacro %}
-
-Called the normal way `caller` will be undefined, but if you call it
-using the new `{% call %}` tag you can pass it some data:
-
-.. sourcecode:: html+jinja
-
-    {% call dialog('Hello World') %}
-        This is an example dialog
-    {% endcall %}
-
-Now the data wrapped will be inserted where you put the `caller` call.
-
-If you pass `caller()` some keyword arguments those are added to the
-namespace of the wrapped template data:
-
-.. sourcecode:: html+jinja
-
-    {% macro makelist items %}
-      <ul>
-      {%- for item in items %}
-        <li>{{ caller(item=item) }}</li>
-      {%- endfor %}
-      </ul>
-    {%- endmacro %}
-
-    {% call makelist([1, 2, 3, 4, 5, 6]) -%}
-      [[{{ item }}]]
-    {%- endcall %}
-
-This will then produce this output:
-
-.. sourcecode:: html
-
-    <ul>
-      <li>[[1]]</li>
-      <li>[[2]]</li>
-      <li>[[3]]</li>
-      <li>[[4]]</li>
-      <li>[[5]]</li>
-      <li>[[6]]</li>
-    </ul>
-
-
-Template Inclusion
-==================
-
-You can load another template at a given position using ``{% include %}``.
-Usually it's a better idea to use inheritance but if you for example want to
-load macros, `include` works better than `extends`:
-
-.. sourcecode:: jinja
-
-    {% include "myhelpers.html" %}
-    {{ my_helper("foo") }}
-
-If you define a macro called ``my_helper`` in ``myhelpers.html``, you can now
-use it from the template as shown above.
-
-Please keep in mind that include does not render the template indenpendently
-but includes the processing instructions into the current template. Thus if the
-included template contains a ``{% extends %}`` tag it also affects the current
-template.
-
-This is intended because it makes it possible to include macros from other
-templates.
-
-*new in Jinja 1.1* you can now render an included template to a string that is
-evaluated in an indepdendent environment by calling `rendertemplate`. See the
-documentation for this function in the `builtins`_ documentation.
-
-
-Filtering Blocks
-================
-
-Sometimes it could be a good idea to filter a complete block of text. For
-example, if you want to escape some html code:
-
-.. sourcecode:: jinja
-
-    {% filter escape %}
-        <html>
-          <code>goes here</code>
-        </html>
-    {% endfilter %}
-
-Of course you can chain filters too:
-
-.. sourcecode:: jinja
-
-    {% filter lower|escape %}
-        <B>SOME TEXT</B>
-    {% endfilter %}
-
-returns ``"&lt;b&gt;some text&lt;/b&gt;"``.
-
-
-Defining Variables
-==================
-
-You can also define variables in the namespace using the ``{% set %}`` tag:
-
-.. sourcecode:: jinja
-
-    {% set foo = 'foobar' %}
-    {{ foo }}
-
-This should ouput ``foobar``.
-
-For information regarding the visibility of variables have a look at the
-`Scopes and Variable Behavior`_ section.
-
-
-Reserved Keywords
-=================
-
-Jinja has some keywords you cannot use a variable names. This limitation
-exists to make templates look coherent. Syntax highlighters won't mess things
-up and you won't have the situation that some names work depending on the
-context.
-
-The following keywords exist and cannot be used as identifiers:
-
-    `and`, `block`, `cycle`, `elif`, `else`, `endblock`, `endfilter`,
-    `endfor`, `endif`, `endmacro`, `endraw`, `endtrans`, `extends`, `filter`,
-    `for`, `if`, `in`, `include`, `is`, `macro`, `not`, `or`, `pluralize`,
-    `print`, `raw`, `recursive`, `set`, `trans`, `call`, `endcall`
-
-If you want to use such a name you have to prefix or suffix it or use
-alternative names:
-
-.. sourcecode:: jinja
-
-    {% for macro_ in macros %}
-        {{ macro_('foo') }}
-    {% endfor %}
-
-
-.. _slicing chapter: http://diveintopython.org/native_data_types/lists.html#odbchelper.list.slice
-.. _Scopes and Variable Behavior: scopes.txt
-.. _builtins: builtins.txt
diff --git a/docs/src/devintro.txt b/docs/src/devintro.txt
deleted file mode 100644
index 0b61924..0000000
--- a/docs/src/devintro.txt
+++ /dev/null
@@ -1,190 +0,0 @@
-====================
-Developer Quickstart
-====================
-
-This part of the documentation shows you how to embed Jinja into your
-application.
-
-Starting Up
-===========
-
-Here the quickest way to create a template from a string and render it:
-
-.. sourcecode:: python
-
-    from jinja import Environment
-    env = Environment()
-    tmpl = env.from_string('Hello {{ name }}!')
-    print tmpl.render(name='John Doe')
-
-This example should output the following string after execution::
-
-    Hello John Doe!
-
-If you receive an error, check if you have a typo in your code. If not, have
-a look at the `installation`_ page for troubleshooting.
-
-Basically the important method on a template is the `render` method. It
-takes either a dict or keyword arguments. All keyword arguments appear
-in the template as variables.
-
-So these two snippets do the same:
-
-.. sourcecode:: python
-
-    tmpl.render(
-        knights='we say nih',
-        spam='and eggs'
-    )
-
-.. sourcecode:: python
-
-    tmpl.render({
-        'knights':  'we say nih',
-        'spam':     'and eggs'
-    })
-
-The Environment
-===============
-
-[[environment_doc]]
-
-The environment provides the following useful functions and properties in
-addition to the initialization values:
-
-=========================== ==================================================
-``parse(source, filename)`` Parse the sourcecode and return the abstract
-                            syntax tree. This tree of nodes is used by the
-                            `translators`_ to convert the template into
-                            executable source- or bytecode.
-``lex(source, filename)``   Tokenize the given sourcecode and return a
-                            generator of tuples in the form
-                            ``(lineno, token, value)``. The filename is just
-                            used in the exceptions raised.
-                            **New in Jinja 1.1**
-``from_string(source)``     Load and parse a template source and translate it
-                            into eval-able Python code. This code is wrapped
-                            within a `Template` class that allows you to
-                            render it.
-``get_template(name)``      Load a template from a loader. If the template
-                            does not exist, you will get a `TemplateNotFound`
-                            exception.
-=========================== ==================================================
-
-There are also some internal functions on the environment used by the template
-evaluation code to keep it sandboxed.
-
-Undefined Values
-================
-
-If a template designer tries to access a not defined value the return value
-will be the `undefined_singleton` specified in the environment. The default
-one is the `SilentUndefined` which fails in no case. Additionally there is
-a special undefined type called the `ComplainingUndefined` which is located
-in the `jinja.datastructure` module. It will raise exceptions when compared
-with other types, or when rendered.
-
-Theoretically you can provide your own singleton by subclassing
-`AbstractUndefindedType` and creating an instance of it using `make_undefined`
-(both located in `jinja.datastructure`) but those two types should cover
-the basic use cases. The `Undefined` object in that module exists for
-backwards compatibility and is an alias for `SilentUndefined`.
-
-To create your own undefined singleton do something like this:
-
-.. sourcecode:: jinja
-
-    from jinja.datastructure import AbstractUndefinedType, make_undefined
-
-    class MyUndefinedType(AbstractUndefindedType):
-        __slots__ = ()
-
-        def __iter__(self):
-            return iter(int, 0)
-
-        def __reduce__(self):
-            return 'MyUndefined'
-
-    MyUndefined = make_undefined(MyUndefinedType)
-
-The only thing you have to do is to override `__reduce__` so that it returns
-the name of the singleton instance and create the instance using
-`make_undefined`. Everything else is up to you. Note that currently attributes
-on undefined objects are available in the Jinja layer too which however
-will change in one of the next Jinja versions. So if you put a `foo` attribute
-on your undefined singleton you will be able to do ``{{ undefined.foo }}``
-by now but certainly not in the future.
-
-This limitation currently exists because undefined is treated as normal object
-and thus affected by normal getattr calls.
-
-
-Automatic Escaping
-==================
-
-Jinja provides a way for automatic escaping, but we do not recommend using it.
-Because Jinja was designed as multi purpose template engine there are some
-issues with automatic escaping. For example filters don't deal with markup
-data. Also you can easily bypass the automatic escaping so it's not something
-you can expect to "just work". Also there is a huge overhead when escaping
-everything.
-
-The best idea is to think about which data already contains html, which will
-probably contain (eg: every user input, etc) etc. And live with self escaping.
-
-That's usually a much better idea.
-
-
-Loading Templates From Files
-============================
-
-Loading templates from a string is always a bad idea. It doesn't allow template
-inheritance and is also slow since it parses and compiles the template again
-and again whereas loaders can cache the template code.
-
-All you have to do is to define a loader and use the `get_template` function.
-
-.. sourcecode:: python
-
-    from jinja import Environment, FileSystemLoader
-    env = Environment(loader=FileSystemLoader('templates'))
-    tmpl = env.get_template('index.html')
-    print tmpl.render(name='John Doe')
-
-This tells jinja to look for templates in the ``templates`` folder. It's a
-better idea to use an absolute path here though. For a list of supported
-loaders or how to write your own, head over to the `loader`_ documentation.
-
-Adding Filters
-==============
-
-If you want to add additional filters to the environment, the best way is to
-modify the ``filters`` attribute and not to pass a dict to the environment.
-If you pass it a dict it will not include the default filters!
-
-.. sourcecode:: python
-
-    from mylib import my_cool_filter
-    env.filters['mycoolfilter'] = my_cool_filter
-
-Writing filter functions is explained in the `filter development`_ section.
-
-Adding Tests
-============
-
-Adding additional tests works analogous to filters:
-
-.. sourcecode:: python
-
-    from mylib import my_cool_test
-    env.tests['mycooltest'] = my_cool_test
-
-Writing tests is explained in the `test development`_ section.
-
-
-.. _installation: installation.txt
-.. _context documentation: contextenv.txt
-.. _loader: loaders.txt
-.. _translators: translators.txt
-.. _filter development: filters.txt
-.. _test development: tests.txt
diff --git a/docs/src/devrecipies.txt b/docs/src/devrecipies.txt
deleted file mode 100644
index dfa2043..0000000
--- a/docs/src/devrecipies.txt
+++ /dev/null
@@ -1,139 +0,0 @@
-=======================
-Recipies For Developers
-=======================
-
-Here some recipies for application developers.
-
-
-Automagic Template Variables
-============================
-
-Python allows some magic stack manipulation which can be used to
-pass variables to templates automatically. It's not a recommended
-way to pass variables to templates but it can be useful for some
-small generation scripts etc.
-
-Just subclass the environment and add an `autorender` function like
-this:
-
-.. sourcecode:: python
-
-    import sys
-    from jinja import Environment
-
-    class AutoEnvironment(Environment):
-
-        def autorender(self, template):
-            tmpl = self.get_template(template)
-            return tmpl.render(sys._getframe(1).f_locals)
-
-You can use it now like this:
-
-.. sourcecode:: python
-
-    def foo():
-        seq = range(10)
-        foo = "blub"
-        return env.autorender('foo.html')
-
-In the template you can now access the local variables `seq` and `foo`.
-
-
-Using Django Filters with Jinja
-===============================
-
-If you use Jinja in django and want to use some of the filters that
-are part of the django core you can use this snippet:
-
-.. sourcecode:: python
-
-    def convert_django_filter(f):
-        def filter_factory(*args):
-            def wrapped(env, ctx, value):
-                return f(value, *args)
-            return wrapped
-        return filter_factory
-
-You can now convert django filters for jinja using `convert_filter`. *Note*:
-Django only supports one filter argument. Because of this limitation you
-shouldn't pass it more arguments than it accepts. Because django uses some
-introspection to find out if a filter accepts an argument weird things can
-happen if you call it with an incompatible argument count.
-
-You can now register django filters for a jinja environment:
-
-.. sourcecode:: python
-
-    from django.template.defaultfilters import date
-    env.filters['date'] = convert_django_filter(date)
-
-And use it:
-
-.. sourcecode:: jinja
-
-    {{ entry.pub_date|date }}
-
-Also keep in mind that Jinja knows about keywords, thus you cannot have a filter
-that is called `pluralize` for example.
-
-Such a conversion function is also part of the djangosupport module which was
-introduced in Jinja 1.2.  It's explained on the `Framework Integration`_ page.
-
-
-Using Jinja in Django
-=====================
-
-.. admonition:: Note
-
-    This section is more or less obsolete as of Jinja 1.2 which provides a
-    djangosupport module, covered on the `Framework Integration`_ page.
-
-This snippet was contributed by Bryan McLemore. It provides a `render_to_response`
-function similar to the one shipped with django just that it uses Jinja for
-rendering. It applies the context processors on the context and consumes a
-`RequestContext`:
-
-.. sourcecode:: python
-
-    from django.template.context import get_standard_processors
-    from django.http import HttpResponse
-    from jinja import Environment, FileSystemLoader, ChoiceLoader
-    from django.conf import settings
-
-    loaders = []
-    for location in settings.TEMPLATE_DIRS:
-        loaders.append(FileSystemLoader(location))
-    env = Environment(loader=ChoiceLoader(loaders))
-
-    def render_to_response(template, context, request=None):
-        template = env.get_template(template)
-        if request:
-            for processor in get_standard_processors():
-                context.update(processor(request))
-        return HttpResponse(template.render(context))
-
-
-If you want to plug Jinja into the Django i18n system you can use this
-environment class:
-
-.. sourcecode:: python
-
-    from jinja import Environment
-    from django.utils.translation import gettext, ngettext
-
-    class DjangoTranslator(object):
-
-        def __init__(self):
-            self.gettext = gettext
-            self.ngettext = ngettext
-
-    class DjangoEnvironment(Environment):
-
-        def get_translator(self, context):
-            return DjangoTranslator()
-
-Because Django uses gettext internally we can create just assign the
-ngettext and gettext functions directly to the translator class.
-
-
-.. _Framework Integration: frameworks.txt
diff --git a/docs/src/escaping.txt b/docs/src/escaping.txt
deleted file mode 100644
index 73c0d93..0000000
--- a/docs/src/escaping.txt
+++ /dev/null
@@ -1,71 +0,0 @@
-=======================
-Whitespace and Escaping
-=======================
-
-This section of the documentation explains how to remove unused whitespace
-from the templates and embed raw Jinja syntax.
-
-Escaping
-========
-
-Sometimes you might want to add Jinja syntax elements into the template
-without executing them. In that case you have quite a few possibilities.
-
-For small parts this might be a good way:
-
-.. sourcecode:: jinja
-
-    {{ "{{ foo }} is variable syntax and {% foo %} is block syntax" }}
-
-When you have multiple elements you can use the ``raw`` block:
-
-.. sourcecode:: jinja
-
-    {% raw %}
-        Filtering blocks works like this in Jinja:
-        {% filter escape %}
-            <html>
-              <code>goes here</code>
-            </html>
-        {% endfilter %}
-    {% endraw %}
-
-
-Whitespace
-==========
-
-If the Jinja environment was created with ``trim_blocks`` set to true the
-first newline after a template tag is removed automatically (php like
-processing).
-
-Starting with `Jinja 1.1` you can also handle some whitespace rules in the
-template. If you put an minus sign (`-`) to the start or end of an block
-(for example a `for` tag), a comment or variable element you can remove
-the whitespaces after or before that block:
-
-.. sourcecode:: jinja
-
-    {% for item in seq -%}
-        {{ item }}
-    {%- endfor %}
-
-This will yield all elements without whitespace between them because they
-are automatically removed. This of course works for other tags too:
-
-.. sourcecode:: jinja
-
-    {% for user in userlist -%}
-        {{ user|e -}}
-        {% if not loop.last %},{% endif %}
-    {%- endfor %}
-
-Note that you must not use a whitespace between the tag and the minus sign:
-
-.. sourcecode:: jinja
-
-    valid:
-        {%- if foo -%}...{% endif %}
-
-    invalid:
-
-        {% - if foo - %}...{% endif %}
diff --git a/docs/src/filters.txt b/docs/src/filters.txt
deleted file mode 100644
index df23205..0000000
--- a/docs/src/filters.txt
+++ /dev/null
@@ -1,73 +0,0 @@
-================
-Filter Functions
-================
-
-Filters are a powerful feature of Jinja taken from django which probably took
-it from UNIX. The idea is that you "pipe" a value through some filters to
-do something with it. For example convert it to upper case, escape it or
-replace a substring.
-
-Jinja comes with some builtin filters explained in the `designer documentation`_.
-
-Writing Filters
-===============
-
-A filter basically is a factory function, a function that returns another
-function. We do this because filters can get an unlimited amount of positional
-arguments and aditionally should gain access to the environment, context and
-piped value. A simple filter looks like this:
-
-.. sourcecode:: python
-
-    def do_join(d=u''):
-        def wrapped(env, context, value):
-            tmp = []
-            for item in value:
-                tmp.append(env.to_unicode(item))
-            return d.join(tmp)
-        return wrapped
-
-Now you have to register that filter on an environment:
-
-.. sourcecode:: python
-
-    env.filters['join'] = do_join
-
-In fact this filter is already bundled so you won't see any effect. But it
-should explain how such a filter looks like. The template designer can just
-trigger the outer code (i.e. call `join` with or without arguments). The
-returned function is then processed by the jinja template engine once all
-filters are created.
-
-If you want to create filters that just operate on a string (in fact unicode
-objects) you can use the `stringfilter` decorator:
-
-.. sourcecode:: python
-
-    from jinja.filters import stringfilter
-
-    @stringfilter
-    def do_strip(value):
-        return value.strip()
-
-The wrapped function is created internally by the decorator, any positional
-arguments are forwarded to the filter function. The first argument is always
-the value already converted into a string.
-
-If you're using Jinja with django and want to use the django filters in Jinja
-have a look at the `developer recipies`_ page.
-
-*new in Jinja 1.1* additionally to the `stringfilter` decorator there is now
-a similar decorator that works exactly the same but does not convert values
-to unicode:
-
-.. sourcecode:: python
-
-    from jinja.filters import simplefilter
-
-    @simplefilter
-    def do_add(value, to_add):
-        return value + to_add
-
-.. _designer documentation: builtins.txt
-.. _developer recipies: devrecipies.txt
diff --git a/docs/src/frameworks.txt b/docs/src/frameworks.txt
deleted file mode 100644
index 6511cf7..0000000
--- a/docs/src/frameworks.txt
+++ /dev/null
@@ -1,247 +0,0 @@
-=====================
-Framework Integration
-=====================
-
-Starting with Jinja 1.1 it's possible to embed Jinja into some of the existing
-frameworks a lot easier. When speaking of frameworks we only refer to `Pylons`_
-which has a working implementation of the TurboGears template specification.
-
-Since the whole situation is problematic because of various reasons (kid
-specific, uses dotted names for template loading, package name prefix etc.)
-we worked around some of the problems by using pylons specific workarounds.
-
-Jinja also ships an implementation for a hypothetical template abstraction layer
-called `General Template Interface`_ which isn't implemented by any existing
-framework so far. This specification however tries to solve the problems that
-exist in Buffet.
-
-
-Buffet
-======
-
-The buffet specification proposes that templates are named in dotted names. That
-means `foo.bar` and not `foo/bar.html`. The dotted notation has the disadvantage
-that you cannot specify the filename extension. In recent pylons versions it's
-however possible to load templates with their native path too if you prefix the
-template name with a foreslash (`/foo/bar.html`). If you don't specify the
-extension it will assume `.html` for the dotted notation.
-
-Here the list of configuration values:
-
-======================= ======================================================
-``jinja.extension``     The template extension when templates are loaded using
-                        the dotted notation. Defaults to ``html``.
-``jinja.environment``   If this is provided it must be the only configuration
-                        value and it's used as jinja environment. In that
-                        case all other configuration parameters except of
-                        ``jinja.extension`` are ignored.
-``jinja.searchpath``    If provided a new file system loader with this
-                        search path is instanciated.
-``jinja.package``       Name of the python package containing the
-                        templates. If this and ``package_path`` is
-                        defined a `PackageLoader` is used.
-``jinja.package_path``  Path to the templates inside of a package.
-``jinja.loader_func``   Function that takes the name of the template to
-                        load. If it returns a string or unicode object
-                        it's used to load a template. If the return
-                        value is None it's considered missing.
-``jinja.getmtime_func`` Function used to check if templates requires
-                        reloading. Has to return the UNIX timestamp of
-                        the last template change or 0 if this template
-                        does not exist or requires updates at any cost.
-``jinja.use_memcache``  Set this to ``True`` to enable memory caching.
-                        This is usually a good idea in production mode,
-                        but disable it during development since it won't
-                        reload template changes automatically.
-                        This only works in persistent environments like
-                        FastCGI.
-``jinja.memcache_size`` Number of template instance you want to cache.
-                        Defaults to ``40``.
-``jinja.cache_folder``  Set this to an existing directory to enable
-                        caching of templates on the file system. Note
-                        that this only affects templates transformed
-                        into python code. Default is ``None`` which means
-                        that caching is disabled.
-``jinja.auto_reload``   Set this to `False` for a slightly better
-                        performance. In that case of `getmtime_func`
-                        not being provided this won't have an effect.
-======================= ======================================================
-
-All other options that start with `jinja.` are automatically forwarded to the
-environment constructor.
-
-In pylons for example you can use jinja as buffet plugin like this:
-
-Edit the `yourproject/config/middleware.py` and add this to `config.init_app`:
-
-.. sourcecode:: python
-
-    config.add_template_engine('jinja', '', {
-        'jinja.package':            'yourapplication',
-        'jinja.package_path':       'res/templates',
-        'jinja.use_memcache':       True
-    })
-
-Note that it's a good idea to set the second parameter to an empty string.
-It's meant to be used as replacement for the turbogears package name but
-Jinja assumes that the name of the template does not include the package
-path.
-
-.. admonition:: Note
-
-    Special note for pylons users.  Jinja will be unable to request attributes
-    from the special `c` object, unless you set `strict_c` to `True` in the
-    `environment.py`:
-
-    .. sourcecode:: python
-
-        return pylons.config.Config(tmpl_options, map, paths, strict_c=True)
-
-You can then render the template in the view like this:
-
-.. sourcecode:: python
-
-    class ExampleController(BaseController):
-
-        def index(self):
-            c.title = "Your Page"
-            c.message = 'hi'
-            return render_response('jinja', 'test_template')
-
-        def download(self):
-            c.title = "Downloads"
-            c.downloads = [1, 2, 3]
-            return render_response('jinja', '/downloads.html')
-
-With the settings from above rendering the `index` action will result in
-rendering the template ``res/templates/test_template.html`` where res is
-a folder in the ``yourapplication`` python package.
-
-The `downloads` action uses the pylons specific leading foreslash notation.
-
-
-General Template Interface
-==========================
-
-Because nobody implemented this specification so far it's not documented here
-but in the sourcecode of the `plugin module`_. The specification itself is
-explained on the pocoo trac on the `General Template Interface`_ wiki page.
-
-
-Django
-======
-
-Using Jinja in django is straightforward because django has a pretty low
-level response interface. Just have a look at the `developer recipies`_,
-there are some examples for django.  Starting with Jinja 1.2 there is also
-a contrib module that simplifies using Jinja in an unicode enabled django.
-
-Quickstart
-----------
-
-To get started execute the following code at the bottom of your settings.py
-or in some general application file such as urls.py or a central module. The
-only thing that matters is that it's executed right *after* the settings
-were set up and *before* `django.contrib.jinja` is imported::
-
-    from jinja.contrib import djangosupport
-    djangosupport.configure()
-
-What this does is setting up a Jinja environment for this django instance
-with loaders for `TEMPLATE_DIRS` etc.  It also converts a couple of default
-django filters such as `date` and `timesince` which are not available in
-Jinja per default.  If you want to change the list you can provide others
-by passing a list with filter import names as `convert_filters` keyword
-argument.
-
-All other keyword arguments are forwarded to the environment.  If you want
-to provide a loader yourself pass it a loader keyword argument.
-
-Rendering Templates
--------------------
-
-To render a template you can use the functions `render_to_string` or
-`render_to_response` from the `django.contrib.jinja` module::
-
-    from django.contrib.jinja import render_to_response
-    resp = render_to_response('Hello {{ username }}!', {
-        'username':     req.session['username']
-    }, req)
-
-`render_to_string` and `render_to_response` take at least the name of
-the template as argument, then the optional dict which will become the
-context.  If you also provide a request object as third argument the
-context processors will be applied.
-
-`render_to_response` also takes a forth parameter which can be the
-content type which defaults to `DEFAULT_CONTENT_TYPE`.
-
-Converting Filters
-------------------
-
-One of the useful objects provided by `django.contrib.jinja` is the
-`register` object which can be used to register filters, tests and
-global objects.  You can also convert any filter django provides in
-a Jinja filter using `convert_django_filter`::
-
-    from django.contrib.jinja import register, convert_django_filter
-    from django.template.defaultfilters import floatformat
-
-    register.filter(convert_django_filter(floatformat), 'floatformat')
-
-Available methods on the `register` object:
-
-``object (obj[, name])``
-    Register a new global as name or with the object's name.
-    Returns the function object unchanged so that you can use
-    it as decorator if no name is provided.
-
-``filter (func[, name])``
-    Register a function as filter with the name provided or
-    the object's name as filtername.
-    Returns the function object unchanged so that you can use
-    it as decorator if no name is provided.
-
-``test (func[, name])``
-    Register a function as test with the name provided or the
-    object's name as testname.
-    Returns the function object unchanged so that you can use
-    it as decorator if no name is provided.
-
-``context_inclusion (func, template[, name])``
-    Register a function with a name provided or the func object's
-    name in the global namespace that acts as subrender function.
-
-    func is called with the callers context as dict and the
-    arguments and keywords argument of the inclusion function.
-    The function should then process the context and return a
-    new context or the same context object. Afterwards the
-    template is rendered with this context.
-
-    Example::
-
-        def add_author(context, author=None):
-            if author is not None:
-                author = Author.objects.get(name=author)
-            context['author'] = author
-            return context
-
-        register.context_inclusion(add_author, 'author_details.html',
-                                   'render_author_details')
-
-    You can use it in the template like this then::
-
-        {{ render_author_details('John Doe') }}
-
-``clean_inclusion (func, template[, name[, run_processors]])``
-    Works like `context_inclusion` but doesn't use the calles
-    context but an empty context. If `run_processors` is `True`
-    it will lookup the context for a `request` object and pass
-    it to the render function to apply context processors.
-
-
-
-.. _Pylons: http://www.pylonshq.com/
-.. _General Template Interface: http://trac.pocoo.org/wiki/GeneralTemplateInterface
-.. _plugin module: http://trac.pocoo.org/browser/jinja/trunk/jinja/plugin.py
-.. _developer recipies: devrecipies.txt
diff --git a/docs/src/fromdjango.txt b/docs/src/fromdjango.txt
deleted file mode 100644
index 23d0b78..0000000
--- a/docs/src/fromdjango.txt
+++ /dev/null
@@ -1,108 +0,0 @@
-===============================
-Differences To Django Templates
-===============================
-
-If you have previously worked with Django templates, you should find Jinja very
-familiar. In fact, most of the syntax elements look and work the same.
-
-However, Jinja provides some more syntax elements covered in the documentation
-and some work a bit different.
-
-Method Calls
-============
-
-In Django method calls work implicitly. With Jinja you have to specify that you
-want to call an object. Thus this Django code:
-
-.. sourcecode:: django
-
-    {% for page in user.get_created_pages %}
-      ...
-    {% endfor %}
-
-will look like this in Jinja:
-
-.. sourcecode:: jinja
-
-    {% for page in user.get_created_pages() %}
-      ...
-    {% endfor %}
-
-This allows you to pass variables to the function which is also used for
-macros and loop recursion, both features that don't exist in Django.
-
-Conditions
-==========
-
-In Django you can use the following constructs to check for equality:
-
-.. sourcecode:: django
-
-    {% ifequals foo "bar" %}
-        ...
-    {% else %}
-        ...
-    {% endifequals %}
-
-In Jinja you can use the normal ``if`` statement in combination with
-operators:
-
-.. sourcecode:: jinja
-
-    {% if foo == 'bar' %}
-        ...
-    {% else %}
-        ...
-    {% endif %}
-
-You can also have multiple ``elif`` branches in your template:
-
-.. sourcecode:: jinja
-
-    {% if something %}
-        ...
-    {% elif otherthing %}
-        ...
-    {% elif foothing %}
-        ...
-    {% else %}
-        ...
-    {% endif %}
-
-Filter Arguments
-================
-
-Jinja provides more than one argument for filters. Also the syntax for argument
-passing is different. A template that looks like this in Django:
-
-.. sourcecode:: django
-
-    {{ items|join:", " }}
-
-looks like this in jinja:
-
-.. sourcecode:: jinja
-
-    {{ items|join(', ') }}
-
-In fact it's a bit more verbose but it allows different types of arguments - including
-variables - and more than one of them.
-
-Tests
-=====
-
-In addition to filters there also are tests you can perform using the `is` operator.
-Here are some examples:
-
-.. sourcecode:: jinja
-
-    {% if user.user_id is odd %}
-        {{ user.username|e }} is odd
-    {% else %}
-        hmm. {{ user.username|e }} looks pretty normal
-    {% endif %}
-
-For a list of supported tests head over to the `syntax reference`_.
-
-
-.. _syntax reference: designerdoc.txt
diff --git a/docs/src/i18n.txt b/docs/src/i18n.txt
deleted file mode 100644
index 91af491..0000000
--- a/docs/src/i18n.txt
+++ /dev/null
@@ -1,113 +0,0 @@
-====================
-Internationalization
-====================
-
-Jinja includes support for internationalized templates. Because usually the
-application includes i18n/l10n code too there is no script to collect
-translatable strings and no default translation interface. A simple
-implementation wouldn't fit into every application so there are a few things
-you have to do.
-
-
-Writing A Translator
-====================
-
-The most important thing is writing a translator and subclassing the
-Environment so that Jinja knows about the translator. Then you have to
-think of how to resolve the current language. You probably use Jinja in a
-multithreaded environment where each thread (request) might want to have
-a different language. The best way is putting the current language into
-the context, this can work automatically if you create a helper function
-for template rendering. But that's up to you.
-
-However. For many web applications this might be a way:
-
-.. sourcecode:: python
-
-    from jinja import Environment
-    from myapplication import get_translator
-
-    class ApplicationTranslator(object):
-
-        def __init__(self, language):
-            self.language = language
-            self.translator = get_translator(language)
-
-        def gettext(self, string):
-            return self.translator.ugettext(string)
-
-        def ngettext(self, singular, plural, n):
-            return self.translator.ungettext(singuarl, plural, n)
-
-
-    class ApplicationEnvironment(Environment):
-
-        def get_translator(self, context):
-            return ApplicationTranslator(context['LANGUAGE'])
-
-
-    env = ApplicationEnvironment()
-    tmpl = env.get_template('index.html')
-    tmpl.render(LANGUAGE='de_DE')
-
-This example assumes that you use gettext and have a gettext `Translations`
-object which is returned by the `get_translator` function. But you don't
-have to use gettext. The only thing Jinja requires is an object with to
-functions/methods on it that return and accept unicode strings:
-``gettext(string)`` that takes a string, translates and returns it, a
-``ngettext(singular, plural, count)`` function that returns the correct plural
-form for `count` items. Because some languages have no or multiple plural
-forms this is necessary.
-
-
-Translator Factory
-==================
-
-With Jinja 1.2 onwards it's possible to use a translator factory
-instead of an enviornment subclass to create a translator for a context.
-A translator factory is passed a context and has to return a translator.
-Because of the way classes work you can also assign a translator class
-that takes a context object as only argument as factory.
-
-Example:
-
-.. sourcecode:: python
-
-    from jinja import Environment
-    from myapplication import get_translator
-
-    def translator_factory(context):
-        return get_translator(context['LANGUAGE'])
-
-    env = ApplicationEnvironment(translator_factory=translator_factory)
-    tmpl = env.get_template('index.html')
-    tmpl.render(LANGUAGE='de_DE')
-
-This example assumes that the translator returned by `get_translator`
-already has a gettext and ngettext function that returns unicode strings.
-
-
-Collecting Translations
-=======================
-
-The next step is to collect the translations. Every Jinja environment
-provides a function called `get_translations` which collects all
-translatable strings from an template.
-
-Example:
-
-.. sourcecode:: pycon
-
-    >>> env.get_translations('index.html')
-    [(1, u'foo', None), (2, u'Foo', None), (3, u'%(count)s Foo', u'%(count)s Foos')]
-
-The first item in the tuple is the linenumer, the second one is the
-singular form and the third is the plural form if given.
-
-Because Jinja is not bound to gettext you can now use these strings to
-create translation files for any translation system.
-
-*New in Jinja 1.1* You can now extract translations from strings according
-to the current envrionment settings too by using the environment method
-`get_translations_for_string` which takes a string containing a template
-as only argument. The return value is the same as for `get_translations`.
diff --git a/docs/src/index.txt b/docs/src/index.txt
deleted file mode 100644
index ba1c4eb..0000000
--- a/docs/src/index.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-======================
-Documentation Overview
-======================
-
-Welcome in the Jinja documentation.
-
-- `Installing Jinja <installation.txt>`_
-
-- **Application Developer Documentation**:
-
-  - `Quickstart <devintro.txt>`_ - getting started with Jinja
-
-  - `Template Loaders <loaders.txt>`_ - documentation for the different
-    loader types and how to write custom ones.
-
-  - `Filter Functions <filters.txt>`_ - information about how to write
-    custom filter functions.
-
-  - `Test Functions <tests.txt>`_ - information about how to write
-    custom test functions.
-
-  - `Global Objects <objects.txt>`_ - information about the special global
-    namespace in Jinja templates.
-
-  - `Streaming Interface <streaming.txt>`_ - using Jinja for big templates
-    by streaming the output.
-
-  - `Internationalization <i18n.txt>`_ - how to internationalize applications
-    using Jinja templates.
-
-  - `Alternative Syntax <altsyntax.txt>`_ - changing the default Jinja
-    block / variable / comment delimiters.
-
-  - `API Documentation <api.txt>`_ - API documentation for public Jinja
-    objects like `Environment`.
-
-  - `Translators <translators.txt>`_ - explanation about the Jinja template
-    translation interface.
-
-  - `Framework Integration <frameworks.txt>`_ - integrating Jinja into
-    python frameworks.
-
-  - `Debugging Support <debugging.txt>`_ - debugging Jinja templates.
-
-  - `Developer Recipies <devrecipies.txt>`_ - tips and tricks for application
-    developers.
-
-- **Template Designer Documentation**:
-
-  - `Syntax Reference <designerdoc.txt>`_ - quick overview over the Jinja
-    syntax elements.
-
-  - `Template Inheritance <inheritance.txt>`_ - template inheritance howto.
-
-  - `Filters, Tests and Helper Functions <builtins.txt>`_ - list of filters
-    and test/helper functions.
-
-  - `Whitespace and Escaping <escaping.txt>`_ - how to escape markup and
-    control whitespace.
-
-  - `Scopes and Variable Behavior <scopes.txt>`_ - behavior of undefined
-    variables and scoping rules.
-
-  - `Template Internationalization <templatei18n.txt>`_ - how to internationalize
-    Jinja templates.
-
-  - `Differences To Django <fromdjango.txt>`_ - coming from django? Then this
-    document is for you.
-
-  - `Designer Recipies <recipies.txt>`_ - various tips and tricks for designers.
-
-- `Changelog <changelog.txt>`_
-
-There is also support via IRC on the ``#pocoo`` channel on `irc.freenode.net`.
diff --git a/docs/src/inheritance.txt b/docs/src/inheritance.txt
deleted file mode 100644
index d9d0cdc..0000000
--- a/docs/src/inheritance.txt
+++ /dev/null
@@ -1,186 +0,0 @@
-====================
-Template Inheritance
-====================
-
-The most powerful part of Jinja is template inheritance. Template inheritance
-allows you to build a base "skeleton" template that contains all the common
-elements of your site and defines **blocks** that child templates can override.
-
-Sounds complicated but is very basic. It's easiest to understand it by starting
-with an example.
-
-
-Base Template
-=============
-
-This template, which we'll call ``base.html``, defines a simple HTML skeleton
-document that you might use for a simple two-column page. It's the job of
-"child" templates to fill the empty blocks with content:
-
-.. sourcecode:: html+jinja
-
-    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
-     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-    <html xmlns="http://www.w3.org/1999/xhtml">
-    <head>
-      <link rel="stylesheet" href="style.css" />
-      <title>{% block title %}{% endblock %} - My Webpage</title>
-      {% block html_head %}{% endblock %}
-    </head>
-    <body>
-      <div id="content">
-        {% block content %}{% endblock %}
-      </div>
-
-      <div id="footer">
-        {% block footer %}
-        &copy; Copyright 2006 by <a href="http://mydomain.tld">myself</a>.
-        {% endblock %}
-      </div>
-    </body>
-
-In this example, the ``{% block %}`` tags define four blocks that child templates
-can fill in. All the `block` tag does is to tell the template engine that a
-child template may override those portions of the template.
-
-
-Child Template
-==============
-
-A child template might look like this:
-
-.. sourcecode:: html+jinja
-
-    {% extends "base.html" %}
-    {% block title %}Index{% endblock %}
-
-    {% block html_head %}
-      <style type="text/css">
-        .important {
-          color: #336699;
-        }
-      </style>
-    {% endblock %}
-    
-    {% block content %}
-        <h1>Index</h1>
-        <p class="important">
-          Welcome on my awsome homepage.
-        </p>
-    {% endblock %}
-
-The ``{% extends %}`` tag is the key here. It tells the template engine that
-this template "extends" another template. When the template system evaluates
-this template, first it locates the parent.  It must be always the first tag
-in a template but whitespace or a comment is allowed before.  This was not
-enforced with Jinja 1.0 and 1.1, it does however raise a syntax error with
-1.2 or later.
-
-The filename of the template depends on the template loader. For example the
-``FileSystemLoader`` allows you to access other templates by giving the
-filename. You can access templates in subdirectories with an slash:
-
-.. sourcecode:: jinja
-
-    {% extends "layout/default.html" %}
-
-But this behavior can depend on the application using Jinja.
-
-Note that since the child template didn't define the ``footer`` block, the
-value from the parent template is used instead.
-
-.. admonition:: Note
-
-    You can't define multiple ``{% block %}`` tags with the same name in the
-    same template. This limitation exists because a block tag works in "both"
-    directions. That is, a block tag doesn't just provide a hole to fill - it
-    also defines the content that fills the hole in the *parent*. If there were
-    two similarly-named ``{% block %}`` tags in a template, that template's
-    parent wouldn't know which one of the blocks' content to use.
-
-
-How Inheritance Works Internally
-================================
-
-Inheritance in Jinja is straightforward. If a template contains an
-``{% extends %}`` tag it's considered being a child template, otherwise it's
-a layout template. In a layout template you can place blocks basically
-everywhere. In a child template blocks can only be located either at the
-top level or inside another block.
-
-Data outside of a block in a child template is executed before the layout
-template is rendered, thus you can use it to propagate data to the whole
-inheritance chain. Having a block in an invalid position you will receive
-an syntax error. Here some examples:
-
-**impossible**:
-
-    .. sourcecode:: jinja
-
-        {% extends 'master.html' %}
-        {% if some_condition %}
-          {% block body %}
-            ...
-          {% endblock %}
-        {% endif %}
-
-    This can't work because template inheritance works at translation /
-    compilation time not at template execution.
-
-**possible**:
-
-    .. sourcecode:: jinja
-
-        {% extends 'master.html' %}
-        {% block body %}
-          {% if some_condition %}
-            {% block myblock %}
-              ...
-            {% endblock %}
-          {% endif %}
-        {% endblock %}
-
-    This can work although it probably makes no sense in this specific case.
-    However the condition is handled at runtime because it's in a valid block
-    and defines a new block subtemplates can override.
-
-
-.. admonition:: Note
-
-    Unlike Python Jinja does not support multiple inheritance.  So you can
-    only have one extends tag with only one constant string argument.
-
-
-Super Blocks
-============
-
-Starting with `Jinja 1.1` it's possible to render the contents of the parent
-block. By calling it you get the results of the parent block back. If you want
-to get the data of the parent you can give it an offset:
-
-.. sourcecode:: jinja
-
-    {{ super() }}
-        return the parent data
-
-    {{ super(1) }}
-        the same as above
-
-    {{ super(2) }}
-        return the data of the second parent block
-
-
-Block Shortcuts
-===============
-
-With Jinja 1.1 onwards it's possible to have a shortcut syntax for blocks
-with few content. The following constructs do the same:
-
-.. sourcecode:: jinja
-
-    {% block title %}{{ page_title }}{% endblock %}
-
-    {% block title page_title %}
-
-Note that as soon as you specify a second argument it's threated as
-short block and Jinja won't look for an closing tag.
diff --git a/docs/src/installation.txt b/docs/src/installation.txt
deleted file mode 100644
index 8f7cbad..0000000
--- a/docs/src/installation.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-============
-Installation
-============
-
-Jinja requires at least Python 2.3 to work correctly.
-
-
-Installing a released version
-=============================
-
-As a Python egg (via easy_install)
-----------------------------------
-
-You can install the most recent Jinja version using `easy_install`_::
-
-    sudo easy_install Jinja
-
-This will install a Jinja egg in your Python installation's site-packages
-directory.
-
-From the tarball release
--------------------------
-
-1.  Download the most recent tarball from the `download page`_
-2.  Unpack the tarball
-3.  ``sudo python setup.py install``
-
-Note that the last command will automatically download and install
-`setuptools`_ if you don't already have it installed. This requires a working
-internet connection.
-
-This will install Jinja into your Python installation's site-packages directory.
-
-
-Installing the development version
-==================================
-
-If you want to play around with the code
-----------------------------------------
-
-1.  Install `mercurial`_
-2.  ``svn co http://dev.pocoo.org/hg/jinja-main jinja``
-3.  ``cd jinja``
-4.  ``ln -s jinja /usr/lib/python2.X/site-packages``
-
-As an alternative to steps 4 you can also do ``python setup.py develop``
-which will install the package via setuptools in development mode.  This also
-has the advantage that the c extensions are compiled.
-
-If you just want the latest features and use them
--------------------------------------------------
-
-::
-    
-    sudo easy_install Jinja==dev
-
-This will install a Jinja egg containing the latest Subversion trunk code
-in your Python installation's site-packages directory. Every time the command
-is run, the sources are updated from Subversion.
-
-
-Windows Installation Information
-================================
-
-On windows computers without Visual Studio 2003 Jinja is unable to compile the
-C extensions.  This is usually not a problem because there is a fallback for
-native Python implementations of those C libraries.  However under certain
-conditions the installation may fail with an error message.  In that case try
-to disable the extensions by passing the following parameters to setup.py::
-
-    python setup.py install --without-speedups --without-extended-debugger
-
-
-Documentation
-=============
-
-The egg builds include a documentation which is available in the ``docs`` folder
-of the egg. If you're running linux you will find the documentation here::
-
-    file:///usr/lib/python2.X/site-packages/Jinja-Y.Z-py2.X.egg/docs/index.html
-
-where ``X``, ``Y`` and ``Z`` must be replaced by the python / jinja version
-number.
-
-
-.. _download page: http://jinja.pocoo.org/download.html
-.. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
-.. _easy_install: http://peak.telecommunity.com/DevCenter/EasyInstall
-.. _mercurial: http://www.selenic.com/mercurial/
diff --git a/docs/src/loaders.txt b/docs/src/loaders.txt
deleted file mode 100644
index f4480ac..0000000
--- a/docs/src/loaders.txt
+++ /dev/null
@@ -1,245 +0,0 @@
-================
-Template Loaders
-================
-
-This part of the documentation explains how to use and write a template loader.
-
-Builtin Loaders
-===============
-
-This list contains the builtin loaders you can use without further
-modification:
-
-[[list_of_loaders]]
-
-Loader Baseclasses
-==================
-
-With Jinja 1.1 onwards all the loaders have (except of the uncached)
-baseclasses. You can use them to mix your own caching layer in. This technique
-is described below. The `BaseLoader` itself is also a loader baseclass but
-because it's the baseclass of all loaders it's covered in the "Developing
-Loaders" section.
-
-[[list_of_baseloaders]]
-
-Developing Loaders
-==================
-
-Template loaders are just normal Python classes that have to provide some
-functions used to load and translate templates. Because some of the tasks
-a loader has to do are redundant there are some classes that make loader
-development easier.
-
-Here the implementation of a simple loader based on the `BaseLoader` from
-`jinja.loaders`:
-
-.. sourcecode:: python
-
-    import codecs
-    from os.path import join
-    from jinja.loaders import BaseLoader
-    from jinja.exceptions import TemplateNotFound
-
-    class SimpleLoader(BaseLoader):
-        
-        def __init__(self, path):
-            self.path = path
-
-        def get_source(self, environment, name, parent):
-            filename = join(self.path, name)
-            if not path.exists(filename):
-                raise TemplateNotFound(name)
-            f = codecs.open(filename, 'r', environment.template_charset)
-            try:
-                return f.read()
-            finally:
-                f.close()
-
-The functions `load` and `parse` which are a requirement for a loader are
-added automatically by the `BaseLoader`. Instead of the normal `BaseLoader`
-you can use one of the other base loaders that already come with a proper
-`get_source` method for further modification. Those loaders however are
-new in Jinja 1.1.
-
-CachedLoaderMixin
------------------
-
-Additionally to the `BaseLoader` there is a mixin class called
-`CachedLoaderMixin` that implements memory and disk caching of templates.
-Note that you have to give it a higher priority in the MRO than the
-`BaseLoader` which means that's the first base class when inheriting from it:
-
-.. sourcecode:: python
-
-    import codecs
-    from os.path import join, getmtime, exists
-    from jinja.loaders import BaseLoaderCachedLoaderMixin
-    from jinja.exceptions import TemplateNotFound
-
-    class CachedLoader(CachedLoaderMixin, BaseLoader):
-        
-        def __init__(self, path):
-            self.path = path
-            CachedLoaderMixin.__init__(self,
-                True,       # use memory caching
-                40,         # for up to 40 templates
-                '/tmp',     # additionally save the compiled templates in /tmp
-                True,       # and reload cached templates automatically if changed
-                'foo'       # optional salt used to keep templates with the same
-                            # name in the same cache folder, but from different
-                            # loaders. New in Jinja 1.1 and can be omitted.
-            )
-
-        def get_source(self, environment, name, parent):
-            filename = join(self.path, name)
-            if not path.exists(filename):
-                raise TemplateNotFound(name)
-            f = codecs.open(filename, 'r', environment.template_charset)
-            try:
-                return f.read()
-            finally:
-                f.close()
-
-        def check_source_changed(self, environment, name):
-            fn = join(self.path, name)
-            if exists(fn):
-                return getmtime(fn)
-            return -1
-
-You don't have to provide the `check_source_changed` method. If it doesn't
-exist the option `auto_reload` won't have an effect. Also note that the
-`check_source_changed` method must not raise an exception if the template
-does not exist but return ``-1``. The return value ``-1`` is considered
-"always reload" whereas ``0`` means "do not reload". The default return
-value for not existing templates should be ``-1``.
-
-For the default base classes that come with Jinja 1.1 onwards there exist
-also concrete implementations that support caching. The implementation
-just mixes in the `CachedLoaderMixin`.
-
-MemcachedLoaderMixin
---------------------
-
-*New in Jinja 1.1*
-
-The `MemcachedLoaderMixin` class adds support for `memcached`_ caching.
-There is only one builtin loader that mixes it in: The
-`MemcachedFileSystemLoader`. If you need other loaders with this mixin
-you can easily subclass one of the existing base loaders. Here an example
-for the `FunctionLoader`:
-
-.. sourcecode:: python
-
-    from jinja.loaders import FunctionLoader, MemcachedLoaderMixin
-
-    class MemcachedFunctionLoader(MemcachedLoaderMixin, FunctionLoader):
-
-        def __init__(self, loader_func):
-            BaseFunctionLoader.__init__(self, loader_func)
-            MemcachedLoaderMixin.__init__(self,
-                True,                   # use memcached
-                60 * 60 * 24 * 7,       # 7 days expiration
-                ['127.0.0.1:11211'],    # the memcached hosts
-                'template/'             # string prefix for the cache keys
-            )
-
-This mixin requires the `python-memcached`_ library.
-
-.. _memcached: http://www.danga.com/memcached/
-.. _python-memcached: http://www.tummy.com/Community/software/python-memcached/
-
-
-How Mixin Classes Work
-======================
-
-The idea of the cached loader mixins is that you override the `load`
-method of the other base class so that it's only called to get the data
-from the loader and put it into a cache and then bypass the original `load`.
-
-This works because mixin classes, as well as the loaders are so called "new
-style classes" with a MRO (method resolution order). So it's possible to
-access the parent without actually knowing the name of it.
-
-Here as small mixin class that stores everything after loading in a
-dict:
-
-.. sourcecode:: python
-
-    class SimpleCacheMixin(object):
-
-        def __init__(self):
-            self.__cache = {}
-
-        def load(self, environment, name, translator):
-            if name in self.__cache:
-                return self.__cache[name]
-            tmpl = super(SimpleCacheMixin, self).load(environment, name,
-                                                      translator)
-            self.__cache[name] = tmpl
-            return tmpl
-
-You can then mix the class in like any other mixin class. Note that
-all non public attributes **must** be prefixed with two underscores to
-enable the name mangling. Otherwise the mixin class could break the
-internal structure of the loader.
-
-The ``super(SimpleCacheMixin, self)`` call returns an object that looks
-up all the attributes you request in all the parent classes. The
-`SimpleCacheMixin` just has the `object` parent which makes it a new
-style class, but as soon as a loader is mixed in it will call the
-`load` method of the loader that is the other parent of the resulting
-class. Here a full example.
-
-Combining Everything
-====================
-
-Here a full example with a custom cache mixin and a custom base loader:
-
-.. sourcecode:: python
-
-    import codecs
-    from os.path import join
-    from jinja.loaders import BaseLoader
-    from jinja.exceptions import TemplateNotFound
-
-    class SimpleBaseLoader(BaseLoader):
-        
-        def __init__(self, path):
-            self.path = path
-
-        def get_source(self, environment, name, parent):
-            filename = join(self.path, name)
-            if not path.exists(filename):
-                raise TemplateNotFound(name)
-            f = codecs.open(filename, 'r', environment.template_charset)
-            try:
-                return f.read()
-            finally:
-                f.close()
-
-
-    class SimpleCacheMixin(object):
-
-        def __init__(self):
-            self.__cache = {}
-
-        def load(self, environment, name, translator):
-            if name in self.__cache:
-                return self.__cache[name]
-            tmpl = super(SimpleCacheMixin, self).load(environment, name,
-                                                      translator)
-            self.__cache[name] = tmpl
-            return tmpl
-
-
-    class SimpleLoader(SimpleBaseLoader, SimpleCacheMixin):
-
-        def __init__(self, path):
-            SimpleBaseLoader.__init__(self, path)
-            SimpleCacheMixin.__init__()
-
-You can of course put all the functionallity into the `SimpleLoader` but then
-you cannot exchange parts of it without rewriting much code. In the example
-above replacing the `SimpleCacheMixin` with a `MemcachedLoaderMixin` is a
-matter of 20 seconds.
diff --git a/docs/src/objects.txt b/docs/src/objects.txt
deleted file mode 100644
index d1551ac..0000000
--- a/docs/src/objects.txt
+++ /dev/null
@@ -1,154 +0,0 @@
-==============
-Global objects
-==============
-
-This section covers the behavior of global objects in the Jinja namespace and
-also the behavior of their attributes.
-
-
-Functions
-=========
-
-`Filters`_ and `Tests`_ are special kind of functions you cannot call without
-and argument. Global functions are different. Those are really just ordinary
-python functions. You can register them on the global namespace easily:
-
-.. sourcecode:: python
-
-    def my_function():
-        return [1, 2, 3]
-
-    env.globals['my_function'] = my_function
-
-In the template you can not call it like this:
-
-.. sourcecode:: jinja
-
-    {{ my_function() }}
-
-Of couse you can pass any argument to it. But what if you want to access the
-context or environment? In that case you have to decorate a function or mark
-it (both work exactly the same, but the decorator way is probably nicer if you
-have python >= 2.4):
-
-.. sourcecode:: python
-
-    from cgi import escape
-    from pprint import pformat
-    from jinja.datastructure import contextcallable
-
-    @contextcallable
-    def printcontext(env, context):
-        result = []
-        for key, value in context.to_dict():
-            result.append('<tr><th>%s</th><td>%r</td></tr>' %
-                          (escape(unicode(key)), escape(pformat(value))))
-        return '<table>%s</table>' % u'\n'.join(result)
-
-If this function is registered in the environment namespace then and called
-from the template it should return the content of the context as simple html
-template. Of course you can modify the context too. For more informations about
-the context object have a look at the `context object`_ documentation.
-
-The new ``{% call %}`` tag that exists with Jinja 1.1 onwards can not only
-be used with Jinja macros but also with Python functions. If a template
-designers uses the ``{% call %}`` tag to call a function provided by the
-application Jinja will call this function with a keyword argument called
-`caller` which points to a `function`. If you call this function (optionally
-with keyword arguments that appear in the context) you get a string back
-that was the content of that block. This should explain this:
-
-.. sourcecode:: python
-
-    def make_dialog(title, caller=None):
-        body = ''
-        if caller:
-            body = caller(title=title)
-        return '<div class="dialog"><h2>%s</h2>%s</div>' % (title, body)
-
-This can be used like this in the template now:
-
-.. sourcecode:: html+jinja
-
-    {% call make_dialog('Dialog Title') %}
-        This is the body of the dialog entitled "{{ title }}".
-    {% endcall %}
-
-Deferred Values
-===============
-
-You can pass functions to the template that are called to provide values at
-first access. Say you want to pass the list of recently written comments to
-all templates. But not necessarily every template will render that. In that
-situation you can create a function that returns that value and wrap it in an
-`Deferred` object. The first time a template accesses the variable then the
-`Deferred` object is resolved:
-
-.. sourcecode:: python
-
-    from jinja.datastructure import Deferred
-    from yourapplication.models import Comments
-
-    def get_recent_comments(env, context, name):
-        # do what ever you want here.
-        return Comments.get_recent(10)
-
-    env.globals['recent_comments'] = Deferred(get_recent_comments)
-
-The function is always called with the same arguments. The first one is the
-current environment, the second the context and the third is the name of the
-variable. In this example ``recent_comments``.
-
-The value is cached until rendering/streaming finished.
-
-Unsafe Methods / Attributes
-===========================
-
-Because Jinja is sandboxed it provides several ways to prevent unsafe attribute
-access. You can mark both attributes and methods as unsafe:
-
-.. sourcecode:: python
-
-    from jinja.datastructure import unsafe
-
-    class MyModel(...):
-
-        # just give access to a and b. Default is all
-        # note that this also disallows the functions from below.
-        # if you use jinja_allowed_attributes you don't have add the
-        # code below since methods are treated as attributes too.
-        jinja_allowed_attributes = ['a', 'b']
-
-        def __init__(self, ...):
-            ...
-            self.a = ...
-            self.b = ...
-
-        # python2.4 way of marking methods
-        @unsafe
-        def save(self):
-            """Save the model."""
-
-        # python2.3 way for the same
-        def delete(self):
-            """Delete the model."""
-        delete.jinja_unsafe_call = True
-
-
-Bypassing Automatic Filtering
-=============================
-
-With Jinja 1.1 it's possible to assign filters to any variable printed. Of
-course there are ways to bypass that in order to make sure an object does
-not get escaped etc.
-
-In order to disable automatic filtering for an object you have to make
-sure that it's either an subclass of `unicode` or implements a
-`__unicode__` method. `__str__` will work too as long as the return value
-only contains ASCII values. Additionally you have to add an attribute to
-that object named `jinja_no_finalization` and set that to `True`.
-
-
-.. _Filters: filters.txt
-.. _Tests: tests.txt
-.. _context object: contextenv.txt
diff --git a/docs/src/recipies.txt b/docs/src/recipies.txt
deleted file mode 100644
index 08ce8bb..0000000
--- a/docs/src/recipies.txt
+++ /dev/null
@@ -1,184 +0,0 @@
-========
-Recipies
-========
-
-Here are some typical recipes for the usage of Jinja templates.
-
-Alternating Rows
-================
-
-If you want to have different styles for each row of a table or
-list you can use the ``cycle`` tag:
-
-.. sourcecode:: html+jinja
-
-    <ul>
-    {% for row in sequence %}
-      <li class="{% cycle 'even', 'odd' %}">{{ row|e }}</li>
-    {% endfor %}
-    </ul>
-
-``cycle`` can take an unlimited amount of strings. Each time this
-tag is encountered the next item from the list is rendered.
-If you pass it just one argument it's meant to be a sequence.
-
-
-Active Menu Item
-================
-
-Often you want to have a navigation bar with an active navigation
-item. This is really simple to achieve. Because ``set`` tags outside
-of ``blocks`` are global you can do something like this:
-
-**layout.html**:
-
-    .. sourcecode:: html+jinja
-
-        {% set navigation_bar = [
-            ('/', 'index', 'Index'),
-            ('/downloads/', 'downloads', 'Downloads'),
-            ('/about/', 'about', 'About')
-        ] %}
-        ...
-        <ul id="navigation">
-        {% for href, id, caption in navigation_bar %}
-          <li{% if id == active_page %} class="active"{% endif
-          %}><a href="{{ href|e }}">{{ caption|e }}</a>/li>
-        {% endfor %}
-        </ul>
-        ...
-
-**index.html**:
-
-    .. sourcecode:: jinja
-
-        {% extends "layout.html" %}
-        {% set active_page = "index" %}
-
-
-Sitemap
-=======
-
-To create a sitemap you can either use the ``for`` tag or a ``macro``
-that calls itself. The datastructures should look like this:
-
-.. sourcecode:: python
-
-    {'sitemap': [
-        dict(
-            caption='Pages',
-            children=[
-                dict(href='index.html', caption='Index'),
-                dict(href='downloads.html', caption='Downloads'),
-                dict(
-                    caption='Users',
-                    children=[
-                        dict(href='peter.html',
-                             caption='Peter'),
-                        dict(href='max.html',
-                             caption='Max'),
-                        dict(href='suzan.html',
-                             caption='Suzan')
-                    ]
-                ),
-                dict(
-                    caption='Files',
-                    children=[
-                        dict(
-                            caption='Images',
-                            children=[
-                                dict(href='vienna.html',
-                                     caption='Vienna'),
-                                dict(href='roma.html',
-                                     caption='Roma'),
-                                dict(href='tokyo.html',
-                                     caption='Tokyo')
-                            ]
-                        ),
-                        dict(
-                            caption='Videos',
-                            children=[
-                                dict(href='party.html',
-                                     caption='Party')
-                            ]
-                        )
-                    ]
-                )
-            ]
-        ),
-        dict(caption='Foo', href='foo.html')
-        dict(caption='About', href='about.html')
-    ]}
-
-Now you can create a sitemap using ``for``:
-
-.. sourcecode:: html+jinja
-
-    <ul class="sitemap">
-    {% for item in sitemap recursive %}
-      <li><a href="{{ item.href|e }}">{{ item.caption|e }}</a>
-      {% if item.children %}<ul>{{ loop(item.children) }}</ul>{% endif %}</li>
-    {% endfor %}
-    </ul>
-
-Or by using a ``macro`` that calls itself:
-
-.. sourcecode:: html+jinja
-
-    {% macro render_sitemap items %}
-      {% for item in items %}
-        <li><a href="{{ item.href|e }}">{{ item.caption|e }}</a>
-        {% if item.children %}<ul>{{ render_sitemap(item.children) }}</ul>{% endif %}</li>
-      {% endfor %}
-    {% endmacro %}
-    <ul class="sitemap">{{ render_sitemap(sitemap) }}</ul>
-
-
-Using A Block Multiple Times
-============================
-
-Blocks have the small disadvantage that they work both ways which is a problem
-if you want to render a block two times on a page. Here a nice little
-workaround for this limitation:
-
-.. sourcecode:: html+jinja
-
-    <html>
-      <head>
-        <title>{% filter capture('title') %}{%
-                  block title %}{% endblock %}{%
-                  endfilter %}</title>
-      </head>
-      <body>
-        <div class="head">{{ title }}</div>
-      </body>
-    </html>
-
-Or if you use the `capture` filter in `clean` mode:
-
-.. sourcecode:: html+jinja
-
-    {% filter capture('title', True)|trim %}
-      {% block title %}{% endblock %}
-    {% endfilter %}
-    <html>
-      <head>
-        <title>{{ title }}</title>
-      </head>
-      <body>
-        <div class="head">{{ title }}</div>
-      </body>
-    </html>
-
-
-Vim Syntax Highlighting
-=======================
-
-Because of the similar syntax to django you can use the django highlighting
-plugin for jinja too. There is however a Jinja syntax highlighting plugin
-too which supports all of the syntax elements.
-
-You can download it from the vim webpage: `jinja.vim`_
-
-
-.. _jinja.vim: http://www.vim.org/scripts/script.php?script_id=1856
diff --git a/docs/src/scopes.txt b/docs/src/scopes.txt
deleted file mode 100644
index 8dd1e43..0000000
--- a/docs/src/scopes.txt
+++ /dev/null
@@ -1,186 +0,0 @@
-============================
-Scopes and Variable Behavior
-============================
-
-This section of the documentation covers the Jinja behavior regarding
-variable visibility.
-
-
-Scopes
-======
-
-Jinja has multiple scopes. A scope is something like a new transparent foil on
-a stack of foils. You can only write to the outermost foil but read all of them
-since you can look through them. If you remove the top foil all data on that
-foil disappears. Some tags in Jinja add a new layer to the stack. Currently
-these are `block`, `for`, `macro` and `filter`. This means that variables and
-other elements defined inside a macro, loop or some of the other tags listed
-above will be only available in that block. Here an example:
-
-.. sourcecode:: jinja
-
-    {% macro angryhello name %}
-      {% set angryname = name|upper %}
-      Hello {{ name }}. Hello {{ name }}!
-      HELLO {{ angryname }}!!!!!!111
-    {% endmacro %}
-
-The variable ``angryname`` just exists inside the macro, not outside it.
-
-Defined macros appear on the context as variables. Because of this, they are
-affected by the scoping too. A macro defined inside of a macro is just available
-in those two macros (the macro itself and the macro it's defined in).
-
-
-Template Globals
-================
-
-A special threatment exists for template code outside of visible blocks in
-child templates. This code will be executed **before** the layout template
-code. Thus it can be used to propagate values back to the layout template or
-import macros from templates for rendering.
-
-Such code can output data but it won't appear in the final rendering. So no
-additional whitespace will pollute the template.
-
-Because this code is executed before the actual layout template code it's
-possible that the layout code overrides some of those variables. Usually
-this is not a problem because of different variable names but it can be
-a problem if you plan to specify default values.
-
-In that case you have to test if the variable is not defined before setting
-it:
-
-.. sourcecode:: jinja
-
-    {% if not page_title %}
-      {% set page_title = 'Default Page Title' %}
-    {% endif %}
-
-You can of course also use the `|default` filter.
-
-.. admonition:: Explanation
-
-    This template stored as `a.html`:
-
-    .. sourcecode:: html+jinja
-
-        <title>{{ title|default('Untitled') }}</title>
-        <body>{% block body %}{% endblock %}
-
-    ...and this child template stored as `b.html`:
-
-    .. sourcecode:: html+jinja
-
-        {% extends 'a.html' %}
-        {% include 'macros.tmpl' %}
-        {% set title = 'My Page' %}
-        {% block body %}{{ wrap(42) }}{% endblock %}
-
-    ...and this code in `macros.tmpl`:
-
-    .. sourcecode:: html+jinja
-
-        {% macro wrap(text) %}
-          [{{ text }}]
-        {% endmacro %}
-
-    ..will translate to something with the same semantics as this (just
-    that the value is not stored in a variable):
-
-    .. sourcecode:: html+jinja
-
-        {% filter capture('captured', true) %}
-          {% macro wrap(text) %}
-            [{{ text }}]
-          {% endmacro %}
-          {% set title='My Page' %}
-        {% endfilter %}
-        <title>{{ title|default('Untitled') }}</title>
-        <body>
-          {{ wrap(42) }}
-        </body>
-
-.. admonition:: Note
-
-    This implementation was improved in Jinja 1.1. In Jinja 1.0 blocks that
-    were not top-level were not propagated to the layout template. This made
-    it impossible to use conditional expressions for inclusion in non root
-    templates.
-
-
-Undefined Variables
-===================
-
-If you have already worked with python you probably know about the fact that
-undefined variables raise an exception. This is different in Jinja. There is a
-special value called `undefined` that represents values that do not exist.
-
-Depending on the configuration it will behave different.
-
-In order to check if a value is defined you can use the `defined` test:
-
-.. sourcecode:: jinja
-
-    {{ myvariable is not defined }}
-        will return true if the variable does not exist.
-
-`SilentUndefined`:
-
-    The silent `undefined` is the default behavior. The `undefined` object works
-    complete different from any variables you maybe know. If you print it
-    using ``{{ variable }}`` it will not appear because it's literally empty.
-    If you try to iterate over it, it will work. But no items are returned.
-
-    In order to check if a value is defined you can use the `defined` test:
-
-    There are also some additional rules regarding this special value. Any
-    mathematical operators (``+``, ``-``, ``*``, ``/``) return the operand
-    as result:
-
-    .. sourcecode:: jinja
-
-        {{ undefined + "foo" }}
-            returns "foo"
-
-        {{ undefined - 42 }}
-            returns 42. Note: not -42!
-
-    In any expression `undefined` evaluates to `false`. It has no length, all
-    attribute calls return undefined, calling too:
-
-    .. sourcecode:: jinja
-
-        {{ undefined.attribute().attribute_too[42] }}
-            still returns `undefined`.
-
-`ComplainingUndefined`:
-
-    Starting with Jinja 1.1 it's possible to replace the default undefined
-    object with different values. The other common undefined object which
-    comes with Jinja is the `ComplainingUndefined` object.
-
-    It raises exceptions as soon as you either render it or want to iterate
-    over it or try to access attributes etc.
-
-
-Overriding Variables Of Outer Scopes
-====================================
-
-*New in Jinja 1.2*
-
-Normally you cannot override a variable from an outer scope, you can just hide
-it. There is however a way to override a variable from an outer scope using the
-`set` tag, postfixed with a bang (!):
-
-.. sourcecode:: jinja
-
-    {% set last_item = none %}
-    {% for item in seq %}
-        {% set last_item = item! %}
-    {% endfor %}
-
-After the iteration `last_item` will point to the item of the last iteration.
-
-If `last_item` was not defined in the outer scope it would be defined in the
-outermost scope.
diff --git a/docs/src/streaming.txt b/docs/src/streaming.txt
deleted file mode 100644
index d872dc1..0000000
--- a/docs/src/streaming.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-===================
-Streaming Interface
-===================
-
-With Jinja 1.1 onwards it's possible to stream the template output. This is
-usually a bad idea because it's slower than `render()` but there are some
-situations where it's useful.
-
-If you for example generate a file with a couple of megabytes you may want
-to pass the stream to the WSGI interface in order to keep the amount of
-memory used low and deliver the output to the browser as fast as possible.
-
-The streaming interface is straightforward. Instead of using `render()` you
-can call `stream()` which does pretty much the same but doesn't return a
-string but a `TemplateStream`:
-
-.. sourcecode:: pycon
-
-    >>> tmpl = env.from_string("<ul>{% for item in seq %}\n  <li>{{ loop.index "
-    ...                        "}} - {{ item }}</li>\n{%- endfor %}</ul>")
-    >>> stream = tmpl.stream(seq=range(4))
-    >>> stream.next()
-    '<ul>'
-    >>> stream.next()
-    u'\n  <li>1 - 0</li>'
-    >>> stream.next()
-    u'\n  <li>2 - 1</li>'
-    >>> stream.next()
-    u'\n  <li>3 - 2</li>'
-    >>> stream.next()
-    u'\n  <li>4 - 3</li>'
-    >>> stream.next()
-    '</ul>'
-
-As you can see each iteration is threated as template event here. But also
-other tags trigger events. Basically every tag yields one event, the
-`print` tag too. The only exception is the variable substitution syntax which
-is inserted into the template text data.
-
-Because some protocols like `WSGI` flush after each iteration if passed as
-response iterable it's better to buffer some events internally. You can do
-this by enable buffering using `enable_buffering` and passing it the buffer
-size which must be greater than one:
-
-.. sourcecode:: pycon
-
-    >>> stream.enable_buffering(size=3)
-    >>> stream.next()
-    u'<ul>\n  <li>1 - 0</li>\n  <li>2 - 1</li>'
-    >>> stream.next()
-    u'\n  <li>3 - 2</li>\n  <li>4 - 3</li></ul>'
-
-This will buffer 3 events before yielding. Disabling buffering works using the
-`disable_buffering` method. You can enable and disable buffering on the fly also
-if you have already iterated over that stream. To check if you are in buffered
-or unbuffered mode you can use the `.buffered` property:
-
-.. sourcecode:: pycon
-
-    >>> stream.buffered
-    False
-    >>> stream.enable_buffering(20)
-    >>> stream.buffered
-    True
-    >>> stream.disable_buffering()
-    >>> stream.buffered
-    False
-
-.. admonition:: Note
-
-    Jinja uses buffering internally for some constructs like macros. A macro
-    call is yielded as one event, independently of the internal structure.
-
-    The same applies to recursive for loops and `{% filter %}` tags.
diff --git a/docs/src/templatei18n.txt b/docs/src/templatei18n.txt
deleted file mode 100644
index debd82b..0000000
--- a/docs/src/templatei18n.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-=============================
-Template Internationalization
-=============================
-
-If the application is configured for i18n, you can define translatable blocks
-for translators using the `trans` tag or the special underscore function:
-
-.. sourcecode:: jinja
-
-    {% trans %}
-        this is a translatable block
-    {% endtrans %}
-
-    {% trans "This is a translatable string" %}
-
-    {{ _("This is a translatable string") }}
-
-The latter one is useful if you want translatable arguments for filters etc.
-If you want to use the ``_()`` syntax in an expression and have variables in
-the string you can add a substituation marker (``%s``) and use the `|format`
-filter to fill the slot:
-
-.. sourcecode:: jinja
-
-    {{ _('Hello %s!')|format(username) }}
-
-If you have more than one substitution variable consider using the
-``{% trans %}`` tags or the `|dformat` filter, the latter however is new
-in Jinja 1.1.
-
-If you want to have plural forms too, use the `pluralize` block:
-
-.. sourcecode:: jinja
-
-    {% trans users=users %}
-        One user found.
-    {% pluralize %}
-        {{ users }} users found.
-    {% endtrans %}
-
-    {% trans first=(users|first).username|escape, user=users|length %}
-        one user {{ first }} found.
-    {% pluralize users %}
-        {{ users }} users found, the first one is called {{ first }}.
-    {% endtrans %}
-
-If you have multiple arguments, the first one is assumed to be the indicator (the
-number that is used to determine the correct singular or plural form. If you
-don't have the indicator variable on position 1 you have to tell the `pluralize`
-tag the correct variable name.
-
-Inside translatable blocks you cannot use blocks or expressions (however you can
-still use the ``raw`` block which will work as expected). The variable
-print syntax (``{{ variablename }}``) is the only way to insert the variables
-defined in the ``trans`` header. Filters must be applied in the header.
-
-.. admonition:: note
-
-    Please make sure that you always use pluralize blocks where required.
-    Many languages have more complex plural forms than the English language.
-    
-    Never try to workaround that issue by using something like this:
-
-    .. sourcecode:: jinja
-
-        {% if count != 1 %}
-            {{ count }} users found.
-        {% else %}
-            one user found.
-        {% endif %}
-
-*New in Jinja 1.1*: It's now possible to use the marker name as implicit
-default:
-
-.. sourcecode:: jinja
-
-    instead of this version:
-
-        {% trans username=username %}Hello {{ username }}!{% endtrans %}
-
-    you can now write this:
-
-        {% trans username %}Hello {{ username }}!{% endtrans %}
diff --git a/docs/src/tests.txt b/docs/src/tests.txt
deleted file mode 100644
index 21ce64f..0000000
--- a/docs/src/tests.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-==============
-Test Functions
-==============
-
-In addition to filters, Jinja also supports test functions. Test functions
-always return either ``True`` or ``False``. Inside the template they are available
-using the `is` operator.
-
-Jinja comes with some builtin tests listed in the `designer documentation`_.
-
-Writing Test Functions
-======================
-
-Test functions look exactly like filters mentioned in the `filter documentation`_:
-
-.. sourcecode:: python
-
-    def is_even():
-        def wrapped(env, context, value):
-            return value % 2 == 0
-        return wrapped
-
-Now you have to register that test on an environment:
-
-.. sourcecode:: python
-
-    env.tests['even'] = is_even
-
-.. _designer documentation: builtins.txt
-.. _filter documentation: filters.txt
diff --git a/docs/src/translators.txt b/docs/src/translators.txt
deleted file mode 100644
index dd77746..0000000
--- a/docs/src/translators.txt
+++ /dev/null
@@ -1,10 +0,0 @@
-===========
-Translators
-===========
-
-Jinja translates the template sourcecode into executable python code behind
-the secenes. This is done by the python translator which is currently the
-only shipped translator. Because the interface isn't stable it's also not
-recommended yet to write other translators. However for one of the next Jinja
-versions a JavaScript translator is planned which allows you to translate
-Jinja templates into executable JavaScript code.