fix a few typos and formatting inconsistencies

1 files changed, 18 insertions, 18 deletions

diff --git a/doc/tutorial.txt b/doc/tutorial.txt
index a98bd532..96e08c9b 100644
--- a/doc/tutorial.txt
+++ b/doc/tutorial.txt
@@ -98,7 +98,7 @@ of) the following import chain as a fall-back to the original ElementTree:
               print("Failed to import ElementTree from any known place")
 
 To aid in writing portable code, this tutorial makes it clear in the examples
-which part of the presented API is an extension of lxml.etree over the
+which part of the presented API is an extension of ``lxml.etree`` over the
 original `ElementTree API`_, as defined by Fredrik Lundh's `ElementTree
 library`_.
 
@@ -268,7 +268,7 @@ copy operation as with lists.  The obvious drawback is that modifications
 to such an Element will apply to all places where it appears in a tree,
 which may or may not be intended.
 
-The upside of this difference is that an Element in lxml.etree always
+The upside of this difference is that an Element in ``lxml.etree`` always
 has exactly one parent, which can be queried through the ``getparent()``
 method.  This is not supported in the original ElementTree.
 
@@ -277,7 +277,7 @@ method.  This is not supported in the original ElementTree.
     >>> root is root[0].getparent()  # lxml.etree only!
     True
 
-If you want to *copy* an element to a different position in lxml.etree,
+If you want to *copy* an element to a different position in ``lxml.etree``,
 consider creating an independent *deep copy* using the ``copy`` module
 from Python's standard library:
 
@@ -605,7 +605,7 @@ make sure only Element objects are returned, you can pass the
 Note that passing a wildcard ``"*"`` tag name will also yield all
 ``Element`` nodes (and only elements).
 
-In lxml.etree, elements provide `further iterators`_ for all directions in the
+In ``lxml.etree``, elements provide `further iterators`_ for all directions in the
 tree: children, parents (or rather ancestors) and siblings.
 
 .. _`further iterators`: api.html#iteration
@@ -756,7 +756,7 @@ the root Element:
 
 This serialisation behaviour has changed in lxml 1.3.4.  Before,
 the tree was serialised without DTD content, which made lxml
-loose DTD information in an input-output cycle.
+lose DTD information in an input-output cycle.
 
 
 Parsing from strings and files
@@ -992,11 +992,11 @@ element, but you can control this through the ``events`` keyword argument:
       end,    a, data
       end, root, None
 
-Note that the text, tail and children of an Element are not necessarily there
+Note that the text, tail, and children of an Element are not necessarily present
 yet when receiving the ``start`` event.  Only the ``end`` event guarantees
 that the Element has been parsed completely.
 
-It also allows to ``.clear()`` or modify the content of an Element to
+It also allows you to ``.clear()`` or modify the content of an Element to
 save memory. So if you parse a large tree and you want to keep memory
 usage small, you should clean up parts of the tree that you no longer
 need:
@@ -1017,12 +1017,12 @@ need:
     None
     ** cleaning up the subtree
 
-A very important use cases for ``iterparse()`` is parsing large
+A very important use case for ``iterparse()`` is parsing large
 generated XML files, e.g. database dumps.  Most often, these XML
 formats only have one main data item element that hangs directly below
 the root node and that is repeated thousands of times.  In this case,
-it is best practice to let ``lxml.etree`` do the tree building and to
-only intercept exactly on this one Element, using the normal tree API
+it is best practice to let ``lxml.etree`` do the tree building and only to
+intercept on exactly this one Element, using the normal tree API
 for data extraction.
 
 .. sourcecode:: pycon
@@ -1075,7 +1075,7 @@ events are generated:
      * test = true
 
 You can reuse the parser and its target as often as you like, so you
-should take care that the ``.close()`` methods really resets the
+should take care that the ``.close()`` method really resets the
 target to a usable state (also in the case of an error!).
 
 .. sourcecode:: pycon
@@ -1103,7 +1103,7 @@ Namespaces
 
 The ElementTree API avoids
 `namespace prefixes <http://www.w3.org/TR/xml-names/#ns-qualnames>`_
-wherever possible and deploys the real namespaces (the URI) instead:
+wherever possible and deploys the real namespace (the URI) instead:
 
 .. sourcecode:: pycon
 
@@ -1206,8 +1206,8 @@ an Element, not only those that it defines itself.
 Therefore, modifying the returned dict cannot have any meaningful
 impact on the Element.  Any changes to it are ignored.
 
-Namespaces on attributes work alike, but as of version 2.3, lxml.etree
-will make sure that the attribute uses a prefixed namespace
+Namespaces on attributes work alike, but as of version 2.3, ``lxml.etree``
+will ensure that the attribute uses a prefixed namespace
 declaration.  This is because unprefixed attribute names are not
 considered being in a namespace by the XML namespace specification
 (`section 6.2`_), so they may end up loosing their namespace on a
@@ -1241,7 +1241,7 @@ You can also use XPath with fully qualified names:
     >>> print(results[0].tag)
     {http://www.w3.org/1999/xhtml}body
 
-For convenience, you can use ``"*"`` wildcards in all iterators of lxml.etree,
+For convenience, you can use ``"*"`` wildcards in all iterators of ``lxml.etree``,
 both for tag names and namespaces:
 
 .. sourcecode:: pycon
@@ -1314,7 +1314,7 @@ HTML:
       </body>
     </html>
 
-The Element creation based on attribute access makes it easy to build up a
+Element creation based on attribute access makes it easy to build up a
 simple vocabulary for an XML language:
 
 .. sourcecode:: pycon
@@ -1379,7 +1379,7 @@ available.
 .. _ElementPath: http://effbot.org/zone/element-xpath.htm
 .. _`full XPath implementation`: xpathxslt.html#xpath
 
-In addition to a `full XPath implementation`_, lxml.etree supports the
+In addition to a `full XPath implementation`_, ``lxml.etree`` supports the
 ElementPath language in the same way ElementTree does, even using
 (almost) the same implementation.  The API provides four methods here
 that you can find on Elements and ElementTrees:
@@ -1443,7 +1443,7 @@ expression for an Element:
     True
 
 As long as the tree is not modified, this path expression represents an
-identifier for a given element that can be used to find() it in the same
+identifier for a given element that can be used to ``find()`` it in the same
 tree later.  Compared to XPath, ElementPath expressions have the advantage
 of being self-contained even for documents that use namespaces.