Use |Flake8| consistently throughout documentation

4 files changed, 25 insertions, 24 deletions

diff --git a/docs/source/dev/formatters.rst b/docs/source/dev/formatters.rst
index 5beafda..480ada0 100644
--- a/docs/source/dev/formatters.rst
+++ b/docs/source/dev/formatters.rst
@@ -4,7 +4,7 @@
  Developing a Formatting Plugin for Flake8
 ===========================================
 
-Flake8 allowed for custom formatting plugins in version
+|Flake8| allowed for custom formatting plugins in version
 3.0.0. Let's write a plugin together:
 
 .. code-block:: python
@@ -17,11 +17,12 @@ Flake8 allowed for custom formatting plugins in version
 
         pass
 
-We notice, as soon as we start, that we inherit from Flake8's
+We notice, as soon as we start, that we inherit from |Flake8|'s
 :class:`~flake8.formatting.base.BaseFormatter` class. If we follow the
 :ref:`instructions to register a plugin <register-a-plugin>` and try to use
-our example formatter, e.g., ``flake8 --format=example`` then Flake8 will fail
-because we did not implement the ``format`` method. Let's do that next.
+our example formatter, e.g., ``flake8 --format=example`` then
+|Flake8| will fail because we did not implement the ``format`` method.
+Let's do that next.
 
 .. code-block:: python
 
@@ -34,7 +35,7 @@ because we did not implement the ``format`` method. Let's do that next.
 With that we're done. Obviously this isn't a very useful formatter, but it
 should highlight the simplicitly of creating a formatter with Flake8. If we
 wanted to instead create a formatter that aggregated the results and returned
-XML, JSON, or subunit we could also do that. Flake8 interacts with the
+XML, JSON, or subunit we could also do that. |Flake8| interacts with the
 formatter in two ways:
 
 #. It creates the formatter and provides it the options parsed from the
diff --git a/docs/source/dev/index.rst b/docs/source/dev/index.rst
index 4969395..9ef8138 100644
--- a/docs/source/dev/index.rst
+++ b/docs/source/dev/index.rst
@@ -2,8 +2,8 @@
  Writing Plugins for Flake8
 ============================
 
-Since Flake8 2.0, the Flake8 tool has allowed for extensions and custom
-plugins. In Flake8 3.0, we're expanding that ability to customize and
+Since |Flake8| 2.0, the |Flake8| tool has allowed for extensions and custom
+plugins. In |Flake8| 3.0, we're expanding that ability to customize and
 extend **and** we're attempting to thoroughly document it. Some of the
 documentation in this section will reference third-party documentation
 to reduce duplication and to point you, the developer, towards
diff --git a/docs/source/dev/plugin_parameters.rst b/docs/source/dev/plugin_parameters.rst
index 9b074ec..527950c 100644
--- a/docs/source/dev/plugin_parameters.rst
+++ b/docs/source/dev/plugin_parameters.rst
@@ -4,15 +4,15 @@
  Receiving Information For A Check Plugin
 ==========================================
 
-Plugins to Flake8 have a great deal of information that they can request from
-a :class:`~flake8.processor.FileProcessor` instance. Historically, Flake8 has
-supported two types of plugins:
+Plugins to |Flake8| have a great deal of information that they can request
+from a :class:`~flake8.processor.FileProcessor` instance. Historically,
+|Flake8| has supported two types of plugins:
 
 #. classes that accept parsed abstract syntax trees (ASTs)
 
 #. functions that accept a range of arguments
 
-Flake8 now does not distinguish between the two types of plugins. Any plugin
+|Flake8| now does not distinguish between the two types of plugins. Any plugin
 can accept either an AST or a range of arguments. Further, any plugin that has
 certain callable attributes can also register options and receive parsed
 options.
@@ -21,8 +21,8 @@ options.
 Indicating Desired Data
 =======================
 
-Flake8 inspects the plugin's signature to determine what parameters it expects
-using :func:`flake8.utils.parameters_for`.
+|Flake8| inspects the plugin's signature to determine what parameters it
+expects using :func:`flake8.utils.parameters_for`.
 :attr:`flake8.plugins.manager.Plugin.parameters` caches the values so that
 each plugin makes that fairly expensive call once per plugin. When processing
 a file, a plugin can ask for any of the following:
@@ -56,7 +56,7 @@ Any plugin that has callable attributes ``provide_options`` and
 
 Your ``register_options`` function should expect to receive an instance of
 |OptionManager|. An |OptionManager| instance behaves very similarly to
-:class:`optparse.OptionParser`. It, however, uses the layer that Flake8 has
+:class:`optparse.OptionParser`. It, however, uses the layer that |Flake8| has
 developed on top of :mod:`optparse` to also handle configuration file parsing.
 :meth:`~flake8.options.manager.OptionManager.add_option` creates an |Option|
 which accepts the same parameters as :mod:`optparse` as well as three extra
@@ -65,7 +65,7 @@ boolean parameters:
 - ``parse_from_config``
 
   The command-line option should also be parsed from config files discovered
-  by Flake8.
+  by |Flake8|.
 
   .. note::
 
@@ -91,8 +91,8 @@ boolean parameters:
   allow a comma-separated list of paths.
 
 Each of these options works individually or can be combined. Let's look at a
-couple examples from Flake8. In each example, we will have ``option_manager``
-which is an instance of |OptionManager|.
+couple examples from |Flake8|. In each example, we will have
+``option_manager`` which is an instance of |OptionManager|.
 
 .. code-block:: python
 
@@ -143,7 +143,7 @@ documentation of :mod:`optparse`.
 Accessing Parsed Options
 ========================
 
-When a plugin has a callable ``provide_options`` attribute, Flake8 will call
+When a plugin has a callable ``provide_options`` attribute, |Flake8| will call
 it and attempt to provide the |OptionManager| instance, the parsed options
 which will be an instance of :class:`optparse.Values`, and the extra arguments
 that were not parsed by the |OptionManager|. If that fails, we will just pass
diff --git a/docs/source/dev/registering_plugins.rst b/docs/source/dev/registering_plugins.rst
index 53b6dc4..5d01f99 100644
--- a/docs/source/dev/registering_plugins.rst
+++ b/docs/source/dev/registering_plugins.rst
@@ -4,7 +4,7 @@
  Registering a Plugin with Flake8
 ==================================
 
-To register any kind of plugin with Flake8, you need:
+To register any kind of plugin with |Flake8|, you need:
 
 #. A way to install the plugin (whether it is packaged on its own or
    as part of something else). In this section, we will use a ``setup.py``
@@ -15,9 +15,9 @@ To register any kind of plugin with Flake8, you need:
 #. A somewhat recent version of setuptools (newer than 0.7.0 but preferably as
    recent as you can attain).
 
-Flake8 relies on functionality provided by setuptools called
-`Entry Points`_. These allow any package to register a plugin with Flake8 via
-that package's ``setup.py`` file.
+|Flake8| relies on functionality provided by setuptools called
+`Entry Points`_. These allow any package to register a plugin with |Flake8|
+via that package's ``setup.py`` file.
 
 Let's presume that we already have our plugin written and it's in a module
 called ``flake8_example``. We might have a ``setup.py`` that looks something
@@ -82,7 +82,7 @@ Note specifically these lines:
 We tell setuptools to register our entry point "X" inside the specific
 grouping of entry-points that flake8 should look in.
 
-Flake8 presently looks at three groups:
+|Flake8| presently looks at three groups:
 
 - ``flake8.extension``
 
@@ -90,7 +90,7 @@ Flake8 presently looks at three groups:
 
 - ``flake8.report``
 
-If your plugin is one that adds checks to Flake8, you will use
+If your plugin is one that adds checks to |Flake8|, you will use
 ``flake8.extension``. If your plugin automatically fixes errors in code, you
 will use ``flake8.listen``.  Finally, if your plugin performs extra report
 handling (formatting, filtering, etc.) it will use ``flake8.report``.