docs: :file:/var/www/foo, `/static`

docs/deploying/fastcgi.rst

@@ -40,8 +40,8 @@ socket to the :class:`~flup.server.fcgi.WSGIServer`::
 The path has to be the exact same path you define in the server
 config.
 
-Save the `yourapplication.fcgi` file somewhere you will find it again.
-It makes sense to have that in `/var/www/yourapplication` or something
+Save the :file:`yourapplication.fcgi` file somewhere you will find it again.
+It makes sense to have that in :file:`/var/www/yourapplication` or something
 similar.
 
 Make sure to set the executable bit on that file so that the servers
@@ -56,7 +56,7 @@ Configuring Apache
 
 The example above is good enough for a basic Apache deployment but your
 `.fcgi` file will appear in your application URL e.g.
-example.com/yourapplication.fcgi/news/. There are few ways to configure
+``example.com/yourapplication.fcgi/news/``. There are few ways to configure
 your application so that yourapplication.fcgi does not appear in the URL.
 A preferable way is to use the ScriptAlias and SetHandler configuration
 directives to route requests to the FastCGI server. The following example
@@ -153,7 +153,7 @@ A basic FastCGI configuration for lighttpd looks like that::
     )
 
 Remember to enable the FastCGI, alias and rewrite modules. This configuration
-binds the application to `/yourapplication`.  If you want the application to
+binds the application to ``/yourapplication``.  If you want the application to
 work in the URL root you have to work around a lighttpd bug with the
 :class:`~werkzeug.contrib.fixers.LighttpdCGIRootFix` middleware.
 
@@ -180,7 +180,7 @@ A basic Flask FastCGI configuration for nginx looks like this::
         fastcgi_pass unix:/tmp/yourapplication-fcgi.sock;
     }
 
-This configuration binds the application to `/yourapplication`.  If you
+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``::
 

docs/deploying/mod_wsgi.rst

@@ -65,7 +65,7 @@ If you don't have a factory function for application creation but a singleton
 instance you can directly import that one as `application`.
 
 Store that file somewhere that you will find it again (e.g.:
-`/var/www/yourapplication`) and make sure that `yourapplication` and all
+:file:`/var/www/yourapplication`) and make sure that `yourapplication` and all
 the libraries that are in use are on the python load path.  If you don't
 want to install it system wide consider using a `virtual python`_
 instance.  Keep in mind that you will have to actually install your

docs/deploying/uwsgi.rst

@@ -51,7 +51,7 @@ A basic flask uWSGI configuration for nginx looks like this::
       uwsgi_pass unix:/tmp/uwsgi.sock;
     }
 
-This configuration binds the application to `/yourapplication`.  If you want
+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::
 

docs/patterns/appdispatch.rst

@@ -59,8 +59,8 @@ here is that each Flask application is a valid WSGI application and they
 are combined by the dispatcher middleware into a larger one that
 dispatched based on prefix.
 
-For example you could have your main application run on `/` and your
-backend interface on `/backend`::
+For example you could have your main application run on ``/`` and your
+backend interface on ``/backend``::
 
     from werkzeug.wsgi import DispatcherMiddleware
     from frontend_app import application as frontend

docs/patterns/fabric.rst

@@ -84,8 +84,8 @@ this command::
     $ fab pack deploy
 
 However this requires that our server already has the
-``/var/www/yourapplication`` folder created and
-``/var/www/yourapplication/env`` to be a virtual environment.  Furthermore
+:file:`/var/www/yourapplication` folder created and
+:file:`/var/www/yourapplication/env` to be a virtual environment.  Furthermore
 are we not creating the configuration or `.wsgi` file on the server.  So
 how do we bootstrap a new server into our infrastructure?
 
@@ -100,16 +100,16 @@ command line::
 
 To setup a new server you would roughly do these steps:
 
-1.  Create the directory structure in ``/var/www``::
+1.  Create the directory structure in :file:`/var/www`::
 
         $ mkdir /var/www/yourapplication
         $ cd /var/www/yourapplication
         $ virtualenv --distribute env
 
-2.  Upload a new `application.wsgi` file to the server and the
-    configuration file for the application (eg: `application.cfg`)
+2.  Upload a new :file:`application.wsgi` file to the server and the
+    configuration file for the application (eg: :file:`application.cfg`)
 
-3.  Create a new Apache config for `yourapplication` and activate it.
+3.  Create a new Apache config for ``yourapplication`` and activate it.
     Make sure to activate watching for changes of the `.wsgi` file so
     that we can automatically reload the application by touching it.
     (See :ref:`mod_wsgi-deployment` for more information)
@@ -151,7 +151,7 @@ usually.
 A popular approach is to store configuration files for different servers
 in a separate version control repository and check them out on all
 servers.  Then symlink the file that is active for the server into the
-location where it's expected (eg: ``/var/www/yourapplication``).
+location where it's expected (eg: :file:`/var/www/yourapplication`).
 
 Either way, in our case here we only expect one or two servers and we can
 upload them ahead of time by hand.

docs/patterns/packages.rst

@@ -21,7 +21,7 @@ Simple Packages
 ---------------
 
 To convert that into a larger one, just create a new folder
-`yourapplication` inside the existing one and move everything below it.
+:file:`yourapplication` inside the existing one and move everything below it.
 Then rename :file:`yourapplication.py` to :file:`__init__.py`.  (Make sure to delete
 all `.pyc` files first, otherwise things would most likely break)
 
@@ -42,7 +42,7 @@ But how do you run your application now?  The naive ``python
 yourapplication/__init__.py`` will not work.  Let's just say that Python
 does not want modules in packages to be the startup file.  But that is not
 a big problem, just add a new file called :file:`runserver.py` next to the inner
-`yourapplication` folder with the following contents::
+:file:`yourapplication` folder with the following contents::
 
     from yourapplication import app
     app.run(debug=True)

docs/quickstart.rst

@@ -371,7 +371,7 @@ Dynamic web applications also need static files.  That's usually where
 the CSS and JavaScript files are coming from.  Ideally your web server is
 configured to serve them for you, but during development Flask can do that
 as well.  Just create a folder called :file:`static` in your package or next to
-your module and it will be available at `/static` on the application.
+your module and it will be available at ``/static`` on the application.
 
 To generate URLs for static files, use the special ``'static'`` endpoint name::