docs: `DEBUG, SERVER_NAME, PATH_INFO`

docs/config.rst

@@ -57,8 +57,8 @@ The following configuration values are used internally by Flask:
 ``PROPAGATE_EXCEPTIONS``          explicitly enable or disable the
                                   propagation of exceptions.  If not set or
                                   explicitly set to ``None`` this is
-                                  implicitly true if either `TESTING` or
-                                  `DEBUG` is true.
+                                  implicitly true if either ``TESTING`` or
+                                  ``DEBUG`` is true.
 ``PRESERVE_CONTEXT_ON_EXCEPTION`` By default if the application is in
                                   debug mode the request context is not
                                   popped on exceptions to enable debuggers
@@ -260,7 +260,7 @@ So a common pattern is this::
 
 This first loads the configuration from the
 `yourapplication.default_settings` module and then overrides the values
-with the contents of the file the :envvar:`YOURAPPLICATION_SETTINGS`
+with the contents of the file the :envvar:``YOURAPPLICATION_SETTINGS``
 environment variable points to.  This environment variable can be set on
 Linux or OS X with the export command in the shell before starting the
 server::

docs/deploying/fastcgi.rst

@@ -182,7 +182,7 @@ A basic Flask FastCGI configuration for nginx looks like this::
 
 This configuration binds the application to `/yourapplication`.  If you
 want to have it in the URL root it's a bit simpler because you don't
-have to figure out how to calculate `PATH_INFO` and `SCRIPT_NAME`::
+have to figure out how to calculate ``PATH_INFO`` and ``SCRIPT_NAME``::
 
     location / { try_files $uri @yourapplication; }
     location @yourapplication {

docs/deploying/uwsgi.rst

@@ -53,7 +53,7 @@ A basic flask uWSGI configuration for nginx looks like this::
 
 This configuration binds the application to `/yourapplication`.  If you want
 to have it in the URL root it's a bit simpler because you don't have to tell
-it the WSGI `SCRIPT_NAME` or set the uwsgi modifier to make use of it::
+it the WSGI ``SCRIPT_NAME`` or set the uwsgi modifier to make use of it::
 
     location / { try_files $uri @yourapplication; }
     location @yourapplication {

docs/deploying/wsgi-standalone.rst

@@ -74,8 +74,8 @@ Proxy Setups
 
 If you deploy your application using one of these servers behind an HTTP proxy
 you will need to rewrite a few headers in order for the application to work.
-The two problematic values in the WSGI environment usually are `REMOTE_ADDR`
-and `HTTP_HOST`.  You can configure your httpd to pass these headers, or you
+The two problematic values in the WSGI environment usually are ``REMOTE_ADDR``
+and ``HTTP_HOST``.  You can configure your httpd to pass these headers, or you
 can fix them in middleware.  Werkzeug ships a fixer that will solve some common
 setups, but you might want to write your own WSGI middleware for specific
 setups.

docs/patterns/fabric.rst

@@ -142,7 +142,7 @@ The Configuration File
 ----------------------
 
 Now as mentioned above, the application will find the correct
-configuration file by looking up the `YOURAPPLICATION_CONFIG` environment
+configuration file by looking up the ``YOURAPPLICATION_CONFIG`` environment
 variable.  So we have to put the configuration in a place where the
 application will able to find it.  Configuration files have the unfriendly
 quality of being different on all computers, so you do not version them

docs/patterns/fileuploads.rst

@@ -32,8 +32,8 @@ bootstrapping code for our application::
 
 So first we need a couple of imports.  Most should be straightforward, the
 :func:`werkzeug.secure_filename` is explained a little bit later.  The
-`UPLOAD_FOLDER` is where we will store the uploaded files and the
-`ALLOWED_EXTENSIONS` is the set of allowed file extensions.  Then we add a
+``UPLOAD_FOLDER`` is where we will store the uploaded files and the
+``ALLOWED_EXTENSIONS`` is the set of allowed file extensions.  Then we add a
 URL rule by hand to the application.  Now usually we're not doing that, so
 why here?  The reasons is that we want the webserver (or our development
 server) to serve these files for us and so we only need a rule to generate
@@ -98,7 +98,7 @@ before storing it directly on the filesystem.
       filename = "../../../../home/username/.bashrc"
 
    Assuming the number of ``../`` is correct and you would join this with
-   the `UPLOAD_FOLDER` the user might have the ability to modify a file on
+   the ``UPLOAD_FOLDER`` the user might have the ability to modify a file on
    the server's filesystem he or she should not modify.  This does require some
    knowledge about how the application looks like, but trust me, hackers
    are patient :)