Merge cb225aa into 9668a95

docs/designdefense.rst

@@ -106,7 +106,7 @@ When you are in full control of the context of execution with a stack based
 system like Logbook has, there is a lot more you can do.
 
 For example you could immediately after your application boots up
-instanciate a :class:`~logbook.FingersCrossedHandler`.  This handler
+instantiate a :class:`~logbook.FingersCrossedHandler`.  This handler
 buffers *all* log records in memory and does not emit them at all.  What's
 the point?  That handler activates when a certain threshold is reached.
 For example, when the first warning occurs you can write the buffered
@@ -213,7 +213,7 @@ Logging Compatibility
 The last pillar of logbook's design is the compatibility with the standard
 libraries logging system.  There are many libraries that exist currently
 that log information with the standard libraries logging module.  Having
-two separate logging systems in the same process is countrproductive and
+two separate logging systems in the same process is counterproductive and
 will cause separate logfiles to appear in the best case or complete chaos
 in the worst.
 

docs/index.rst

@@ -17,7 +17,7 @@ desktop notification system?  :ref:`Logbook can do that <notifiers>`.
 
 Feedback is appreciated.  The docs here only show a tiny,
 tiny feature set and can be incomplete. We will have better docs
-soon, but until then we hope this gives a sneak peak about how cool
+soon, but until then we hope this gives a sneak peek about how cool
 Logbook is.  If you want more, have a look at the comprehensive suite of tests.
 
 Documentation

docs/performance.rst

@@ -24,7 +24,7 @@ will always be processed, even if the log record ends up being discarded.
 
 This is where the Python ``__debug__`` feature comes in handy.  This
 variable is a special flag that is evaluated at the time where Python
-processes your script.  It can elliminate code completely from your script
+processes your script.  It can eliminate code completely from your script
 so that it does not even exist in the compiled bytecode (requires Python
 to be run with the ``-O`` switch)::
 

docs/setups.rst

@@ -112,7 +112,7 @@ explained using an example::
         # make sure we never bubble up to the stderr handler
         # if we run out of setup handling
         NullHandler(),
-        # then write messages that are at least warnings to to a logfile
+        # then write messages that are at least warnings to a logfile
         FileHandler('application.log', level='WARNING'),
         # errors should then be delivered by mail and also be kept
         # in the application log, so we let them bubble up.

docs/stacks.rst

@@ -75,7 +75,7 @@ handler can decide if it wants to process the record, and then it has a
 flag (the :attr:`~logbook.Handler.bubble` flag) which specifies if the
 next handler in the chain is supposed to get this record passed to.
 
-If a handler is bubbeling it will give the record to the next handler,
+If a handler is bubbling it will give the record to the next handler,
 even if it was properly handled.  If it's not, it will stop promoting
 handlers further down the chain.  Additionally there are so-called
 "blackhole" handlers (:class:`~logbook.NullHandler`) which stop processing

docs/ticketing.rst

@@ -47,7 +47,7 @@ The builtin ticketing handler is called
 it will connect to a relational database with the help of `SQLAlchemy`_
 and log into two tables there: tickets go into ``${prefix}tickets`` and
 occurrences go into ``${prefix}occurrences``.  The default table prefix is
-``'logbook_'`` but can be overriden.  If the tables do not exist already,
+``'logbook_'`` but can be overridden.  If the tables do not exist already,
 the handler will create them.
 
 Here an example setup that logs into a postgres database::