Merge pull request #1957 from stevepiercy/master

wrap 79 cols

1 files changed, 46 insertions, 49 deletions

diff --git a/docs/narr/startup.rst b/docs/narr/startup.rst
index b8d3bfac9..485f6b181 100644
--- a/docs/narr/startup.rst
+++ b/docs/narr/startup.rst
@@ -12,9 +12,9 @@ you'll see something much like this show up on the console:
   Starting server in PID 16601.
   serving on 0.0.0.0:6543 view at http://127.0.0.1:6543
 
-This chapter explains what happens between the time you press the "Return"
-key on your keyboard after typing ``pserve development.ini`` and the time the
-line ``serving on 0.0.0.0:6543 ...`` is output to your console.
+This chapter explains what happens between the time you press the "Return" key
+on your keyboard after typing ``pserve development.ini`` and the time the line
+``serving on 0.0.0.0:6543 ...`` is output to your console.
 
 .. index::
    single: startup process
@@ -26,9 +26,8 @@ The Startup Process
 The easiest and best-documented way to start and serve a :app:`Pyramid`
 application is to use the ``pserve`` command against a :term:`PasteDeploy`
 ``.ini`` file.  This uses the ``.ini`` file to infer settings and starts a
-server listening on a port.  For the purposes of this discussion, we'll
-assume that you are using this command to run your :app:`Pyramid`
-application.
+server listening on a port.  For the purposes of this discussion, we'll assume
+that you are using this command to run your :app:`Pyramid` application.
 
 Here's a high-level time-ordered overview of what happens when you press
 ``return`` after running ``pserve development.ini``.
@@ -40,30 +39,29 @@ Here's a high-level time-ordered overview of what happens when you press
 
 #. The framework finds a section named either ``[app:main]``,
    ``[pipeline:main]``, or ``[composite:main]`` in the ``.ini`` file.  This
-   section represents the configuration of a :term:`WSGI` application that
-   will be served.  If you're using a simple application (e.g.,
-   ``[app:main]``), the application's ``paste.app_factory`` :term:`entry
-   point` will be named on the ``use=`` line within the section's
-   configuration.  If instead of a simple application, you're using a WSGI
-   :term:`pipeline` (e.g., a ``[pipeline:main]`` section), the application
-   named on the "last" element will refer to your :app:`Pyramid` application.
-   If instead of a simple application or a pipeline, you're using a
-   "composite" (e.g., ``[composite:main]``), refer to the documentation for
-   that particular composite to understand how to make it refer to your
-   :app:`Pyramid` application.  In most cases, a Pyramid application built
-   from a scaffold will have a single ``[app:main]`` section in it, and this
-   will be the application served.
-
-#. The framework finds all :mod:`logging` related configuration in the
-   ``.ini`` file and uses it to configure the Python standard library logging
-   system for this application.  See :ref:`logging_config` for more
-   information.
+   section represents the configuration of a :term:`WSGI` application that will
+   be served.  If you're using a simple application (e.g., ``[app:main]``), the
+   application's ``paste.app_factory`` :term:`entry point` will be named on the
+   ``use=`` line within the section's configuration.  If instead of a simple
+   application, you're using a WSGI :term:`pipeline` (e.g., a
+   ``[pipeline:main]`` section), the application named on the "last" element
+   will refer to your :app:`Pyramid` application.  If instead of a simple
+   application or a pipeline, you're using a "composite" (e.g.,
+   ``[composite:main]``), refer to the documentation for that particular
+   composite to understand how to make it refer to your :app:`Pyramid`
+   application.  In most cases, a Pyramid application built from a scaffold
+   will have a single ``[app:main]`` section in it, and this will be the
+   application served.
+
+#. The framework finds all :mod:`logging` related configuration in the ``.ini``
+   file and uses it to configure the Python standard library logging system for
+   this application.  See :ref:`logging_config` for more information.
 
 #. The application's *constructor* named by the entry point referenced on the
-   ``use=`` line of the section representing your :app:`Pyramid` application
-   is passed the key/value parameters mentioned within the section in which
-   it's defined.  The constructor is meant to return a :term:`router`
-   instance, which is a :term:`WSGI` application.
+   ``use=`` line of the section representing your :app:`Pyramid` application is
+   passed the key/value parameters mentioned within the section in which it's
+   defined.  The constructor is meant to return a :term:`router` instance,
+   which is a :term:`WSGI` application.
 
    For :app:`Pyramid` applications, the constructor will be a function named
    ``main`` in the ``__init__.py`` file within the :term:`package` in which
@@ -79,11 +77,11 @@ Here's a high-level time-ordered overview of what happens when you press
    which is a dictionary of key/value pairs mentioned in the ``[DEFAULT]``
    section of an ``.ini`` file (if :ref:`[DEFAULT]
    <defaults_section_of_pastedeploy_file>` is present).  It also accepts a
-   ``**settings`` argument, which collects another set of arbitrary
-   key/value pairs.  The arbitrary key/value pairs received by this function in
-   ``**settings`` will be composed of all the key/value pairs that are
-   present in the ``[app:main]`` section (except for the ``use=`` setting)
-   when this function is called when you run ``pserve``.
+   ``**settings`` argument, which collects another set of arbitrary key/value
+   pairs.  The arbitrary key/value pairs received by this function in
+   ``**settings`` will be composed of all the key/value pairs that are present
+   in the ``[app:main]`` section (except for the ``use=`` setting) when this
+   function is called when you run ``pserve``.
 
    Our generated ``development.ini`` file looks like so:
 
@@ -93,8 +91,8 @@ Here's a high-level time-ordered overview of what happens when you press
 
    In this case, the ``myproject.__init__:main`` function referred to by the
    entry point URI ``egg:MyProject`` (see :ref:`MyProject_ini` for more
-   information about entry point URIs, and how they relate to callables)
-   will receive the key/value pairs ``{'pyramid.reload_templates':'true',
+   information about entry point URIs, and how they relate to callables) will
+   receive the key/value pairs ``{'pyramid.reload_templates':'true',
    'pyramid.debug_authorization':'false', 'pyramid.debug_notfound':'false',
    'pyramid.debug_routematch':'false', 'pyramid.debug_templates':'true',
    'pyramid.default_locale_name':'en'}``.  See :ref:`environment_chapter` for
@@ -112,13 +110,13 @@ Here's a high-level time-ordered overview of what happens when you press
 
 #. The ``main`` function then calls various methods on the instance of the
    class :class:`~pyramid.config.Configurator` created in the previous step.
-   The intent of calling these methods is to populate an
-   :term:`application registry`, which represents the :app:`Pyramid`
-   configuration related to the application.
+   The intent of calling these methods is to populate an :term:`application
+   registry`, which represents the :app:`Pyramid` configuration related to the
+   application.
 
-#. The :meth:`~pyramid.config.Configurator.make_wsgi_app` method is called.
-   The result is a :term:`router` instance.  The router is associated with
-   the :term:`application registry` implied by the configurator previously
+#. The :meth:`~pyramid.config.Configurator.make_wsgi_app` method is called. The
+   result is a :term:`router` instance.  The router is associated with the
+   :term:`application registry` implied by the configurator previously
    populated by other methods run against the Configurator.  The router is a
    WSGI application.
 
@@ -140,9 +138,9 @@ Here's a high-level time-ordered overview of what happens when you press
 
 .. seealso::
    Logging configuration is described in the :ref:`logging_chapter` chapter.
-   There, in :ref:`request_logging_with_pastes_translogger`, you will also
-   find an example of how to configure :term:`middleware` to add
-   pre-packaged functionality to your application.
+   There, in :ref:`request_logging_with_pastes_translogger`, you will also find
+   an example of how to configure :term:`middleware` to add pre-packaged
+   functionality to your application.
 
 .. index::
    pair: settings; deployment
@@ -155,8 +153,7 @@ Deployment Settings
 
 Note that an augmented version of the values passed as ``**settings`` to the
 :class:`~pyramid.config.Configurator` constructor will be available in
-:app:`Pyramid` :term:`view callable` code as ``request.registry.settings``.
-You can create objects you wish to access later from view code, and put them
-into the dictionary you pass to the configurator as ``settings``.  They will
-then be present in the ``request.registry.settings`` dictionary at
-application runtime.
+:app:`Pyramid` :term:`view callable` code as ``request.registry.settings``. You
+can create objects you wish to access later from view code, and put them into
+the dictionary you pass to the configurator as ``settings``.  They will then be
+present in the ``request.registry.settings`` dictionary at application runtime.