Clean up class and method references

- In docs/api/cmd.rst, the `cmd2.Cmd` class was defined as `cmd2.cmd2.Cmd`, which required the extraneous `cmd2` every time we referenced it. This extra `cmd2` is no longer required.
- always refer to a bare cmd2 using ``cmd2`` per our documentation conventions

12 files changed, 48 insertions, 56 deletions

diff --git a/docs/features/argument_processing.rst b/docs/features/argument_processing.rst
index 75d92c94..9d98ea93 100644
--- a/docs/features/argument_processing.rst
+++ b/docs/features/argument_processing.rst
@@ -31,20 +31,12 @@ applications.
 .. _argprint: https://github.com/python-cmd2/cmd2/blob/master/examples/arg_print.py
 .. _decorator: https://github.com/python-cmd2/cmd2/blob/master/examples/decorator_example.py
 
-.. _decorators:
-
-Decorators provided by cmd2 for argument processing
----------------------------------------------------
-
 ``cmd2`` provides the following decorators for assisting with parsing arguments
 passed to commands:
 
-.. automethod:: cmd2.decorators.with_argparser
-   :noindex:
-.. automethod:: cmd2.decorators.with_argparser_and_unknown_args
-   :noindex:
-.. automethod:: cmd2.decorators.with_argument_list
-   :noindex:
+* :func:`cmd2.decorators.with_argparser`
+* :func:`cmd2.decorators.with_argparser_and_unknown_args`
+* :func:`cmd2.decorators.with_argument_list`
 
 All of these decorators accept an optional **preserve_quotes** argument which
 defaults to ``False``. Setting this argument to ``True`` is useful for cases
@@ -52,8 +44,8 @@ where you are passing the arguments to another command which might have its own
 argument parsing.
 
 
-Using the argument parser decorator
------------------------------------
+Argument Parsing
+----------------
 
 For each command in the ``cmd2`` subclass which requires argument parsing,
 create a unique instance of ``argparse.ArgumentParser()`` which can parse the
@@ -108,8 +100,8 @@ Here's what it looks like::
 Help Messages
 -------------
 
-By default, cmd2 uses the docstring of the command method when a user asks for
-help on the command. When you use the ``@with_argparser`` decorator, the
+By default, ``cmd2`` uses the docstring of the command method when a user asks
+for help on the command. When you use the ``@with_argparser`` decorator, the
 docstring for the ``do_*`` method is used to set the description for the
 ``argparse.ArgumentParser``.
 
@@ -215,8 +207,8 @@ Which yields:
 .. _argparse: https://docs.python.org/3/library/argparse.html
 
 
-Receiving an argument list
---------------------------
+Argument List
+-------------
 
 The default behavior of ``cmd2`` is to pass the user input directly to your
 ``do_*`` methods as a string. The object passed to your method is actually a
@@ -265,7 +257,7 @@ argument list instead of a string::
             pass
 
 
-Unknown positional arguments
+Unknown Positional Arguments
 ----------------------------
 
 If you want all unknown arguments to be passed to your command as a list of
@@ -295,8 +287,8 @@ Here's what it looks like::
 
         ...
 
-Using custom argparse.Namespace
--------------------------------
+Using A Custom Namespace
+------------------------
 
 In some cases, it may be necessary to write custom ``argparse`` code that is
 dependent on state data of your application.  To support this ability while
@@ -332,7 +324,7 @@ Subcommands are supported for commands using either the ``@with_argparser`` or
 ``@with_argparser_and_unknown_args`` decorator.  The syntax for supporting them
 is based on argparse sub-parsers.
 
-You may add multiple layers of subcommands for your command. Cmd2 will
+You may add multiple layers of subcommands for your command. ``cmd2`` will
 automatically traverse and tab-complete subcommands for all commands using
 argparse.
 
diff --git a/docs/features/builtin_commands.rst b/docs/features/builtin_commands.rst
index 025149b3..d2cefa71 100644
--- a/docs/features/builtin_commands.rst
+++ b/docs/features/builtin_commands.rst
@@ -1,7 +1,7 @@
 Builtin Commands
 ================
 
-Applications which subclass :class:`cmd2.cmd2.Cmd` inherit a number of commands
+Applications which subclass :class:`cmd2.Cmd` inherit a number of commands
 which may be useful to your users. Developers can
 :ref:`features/builtin_commands:Remove Builtin Commands` if they do not want
 them to be part of the application.
@@ -130,9 +130,9 @@ This command lists available shortcuts.  See
 Remove Builtin Commands
 -----------------------
 
-Developers may not want to offer the commands builtin to :class:`cmd2.cmd2.Cmd`
+Developers may not want to offer the commands builtin to :class:`cmd2.Cmd`
 to users of their application. To remove a command you must delete the method
-implementing that command from the :class:`cmd2.cmd2.Cmd` object at runtime.
+implementing that command from the :class:`cmd2.Cmd` object at runtime.
 For example, if you wanted to remove the :ref:`features/builtin_commands:shell`
 command from your application::
 
diff --git a/docs/features/completion.rst b/docs/features/completion.rst
index 41bc3b34..14a98caf 100644
--- a/docs/features/completion.rst
+++ b/docs/features/completion.rst
@@ -36,8 +36,8 @@ similar to the following to your class which inherits from ``cmd2.Cmd``::
 Tab Completion Using Argparse Decorators
 ----------------------------------------
 
-When using one the Argparse-based :ref:`decorators`, ``cmd2`` provides
-automatic tab-completion of flag names.
+When using one the Argparse-based :ref:`api/decorators:Decorators`, ``cmd2``
+provides automatic tab-completion of flag names.
 
 Tab-completion of argument values can be configured by using one of five
 parameters to ``argparse.ArgumentParser.add_argument()``
diff --git a/docs/features/embedded_python_shells.rst b/docs/features/embedded_python_shells.rst
index 0af2f737..68377876 100644
--- a/docs/features/embedded_python_shells.rst
+++ b/docs/features/embedded_python_shells.rst
@@ -5,12 +5,12 @@ The ``py`` command will run its arguments as a Python command.  Entered without
 arguments, it enters an interactive Python session.  The session can call
 "back" to your application through the name defined in ``self.pyscript_name``
 (defaults to ``app``).  This wrapper provides access to execute commands in
-your cmd2 application while maintaining isolation.
+your ``cmd2`` application while maintaining isolation.
 
 You may optionally enable full access to to your application by setting
 ``self_in_py`` to ``True``.  Enabling this flag adds ``self`` to the python
-session, which is a reference to your Cmd2 application. This can be useful for
-debugging your application.
+session, which is a reference to your ``cmd2`` application. This can be useful
+for debugging your application.
 
 The ``app`` object (or your custom name) provides access to application
 commands through raw commands.  For example, any application command call be
diff --git a/docs/features/generating_output.rst b/docs/features/generating_output.rst
index d5224e86..d6484c26 100644
--- a/docs/features/generating_output.rst
+++ b/docs/features/generating_output.rst
@@ -7,26 +7,26 @@ methods::
   print("Greetings, Professor Falken.", file=self.stdout)
   self.stdout.write("Shall we play a game?\n")
 
-While you could send output directly to ``sys.stdout``, :mod:`cmd2.cmd2.Cmd`
+While you could send output directly to ``sys.stdout``, :mod:`cmd2.Cmd`
 can be initialized with a ``stdin`` and ``stdout`` variables, which it stores
 as ``self.stdin`` and ``self.stdout``. By using these variables every time you
 produce output, you can trivially change where all the output goes by changing
 how you initialize your class.
 
-:mod:`cmd2.cmd2.Cmd` extends this approach in a number of convenient ways. See
+:mod:`cmd2.Cmd` extends this approach in a number of convenient ways. See
 :ref:`features/redirection:Output Redirection And Pipes` for information on how
 users can change where the output of a command is sent. In order for those
 features to work, the output you generate must be sent to ``self.stdout``. You
 can use the methods described above, and everything will work fine.
-:mod:`cmd2.cmd2.Cmd` also includes a number of output related methods which you
+:mod:`cmd2.Cmd` also includes a number of output related methods which you
 may use to enhance the output your application produces.
 
 
 Ordinary Output
 ---------------
 
-The :meth:`~.cmd2.Cmd.poutput` method is similar to the Python
-`built-in print function <https://docs.python.org/3/library/functions.html#print>`_. :meth:`~.cmd2.Cmd.poutput` adds two
+The :meth:`~cmd2.Cmd.poutput` method is similar to the Python
+`built-in print function <https://docs.python.org/3/library/functions.html#print>`_. :meth:`~cmd2.Cmd.poutput` adds two
 conveniences:
 
   1. Since users can pipe output to a shell command, it catches
@@ -34,7 +34,7 @@ conveniences:
   ``self.broken_pipe_warning`` to ``stderr``. ``self.broken_pipe_warning``
   defaults to an empty string so this method will just swallow the exception.
   If you want to show an error message, put it in
-  ``self.broken_pipe_warning`` when you initialize :mod:`~cmd2.cmd2.Cmd`.
+  ``self.broken_pipe_warning`` when you initialize :mod:`~cmd2.Cmd`.
 
   2. It examines and honors the :ref:`features/settings:allow_style` setting.
   See :ref:`features/generating_output:Colored Output` below for more details.
diff --git a/docs/features/history.rst b/docs/features/history.rst
index 3c238c3c..54e18683 100644
--- a/docs/features/history.rst
+++ b/docs/features/history.rst
@@ -4,7 +4,7 @@ History
 For Developers
 --------------
 
-- Describe how cmd2 tracks history
+- Describe how ``cmd2`` tracks history
 - how persistent history works
 - differences in history and bash shell history (we only store valid commands
   in history)
@@ -13,7 +13,7 @@ For Developers
 ``cmd2`` adds the option of making this history persistent via optional
 arguments to ``cmd2.Cmd.__init__()``:
 
-.. automethod:: cmd2.cmd2.Cmd.__init__
+.. automethod:: cmd2.Cmd.__init__
 
 
 For Users
diff --git a/docs/features/hooks.rst b/docs/features/hooks.rst
index 17f2884e..ee1d5fbc 100644
--- a/docs/features/hooks.rst
+++ b/docs/features/hooks.rst
@@ -1,7 +1,7 @@
 Hooks
 =====
 
-The typical way of starting a cmd2 application is as follows::
+The typical way of starting a ``cmd2`` application is as follows::
 
     import cmd2
     class App(cmd2.Cmd):
diff --git a/docs/features/initialization.rst b/docs/features/initialization.rst
index 46b4ecd2..9924caa2 100644
--- a/docs/features/initialization.rst
+++ b/docs/features/initialization.rst
@@ -77,7 +77,7 @@ useful as a superclass of a class you define yourself in order to inherit
 Certain things must be initialized within the ``__init__()`` method of your
 class derived from ``cmd2.Cmd``(all arguments to ``__init__()`` are optional):
 
-.. automethod:: cmd2.cmd2.Cmd.__init__
+.. automethod:: cmd2.Cmd.__init__
     :noindex:
 
 Cmd instance attributes
diff --git a/docs/features/misc.rst b/docs/features/misc.rst
index aa791236..0dc1939c 100644
--- a/docs/features/misc.rst
+++ b/docs/features/misc.rst
@@ -23,7 +23,7 @@ Presents numbered options to user, as bash ``select``.
 ``app.select`` is called from within a method (not by the user directly; it is
 ``app.select``, not ``app.do_select``).
 
-.. automethod:: cmd2.cmd2.Cmd.select
+.. automethod:: cmd2.Cmd.select
     :noindex:
 
 ::
diff --git a/docs/features/os.rst b/docs/features/os.rst
index 07afc3cd..89905d17 100644
--- a/docs/features/os.rst
+++ b/docs/features/os.rst
@@ -149,7 +149,7 @@ single or double quotes)::
     (Cmd)
 
 Automating cmd2 apps from other CLI/CLU tools
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 While ``cmd2`` is designed to create **interactive** command-line applications
 which enter a Read-Evaluate-Print-Loop (REPL), there are a great many times
diff --git a/docs/features/packaging.rst b/docs/features/packaging.rst
index 10f347ac..a65fd6dd 100644
--- a/docs/features/packaging.rst
+++ b/docs/features/packaging.rst
@@ -1,6 +1,6 @@
 
 Packaging a cmd2 application for distribution
-=============================================
+=================================================
 
 As a general-purpose tool for building interactive command-line applications,
 ``cmd2`` is designed to be used in many ways. How you distribute your ``cmd2``
diff --git a/docs/features/settings.rst b/docs/features/settings.rst
index 55b6a10d..cece62b7 100644
--- a/docs/features/settings.rst
+++ b/docs/features/settings.rst
@@ -3,8 +3,8 @@ Settings
 
 Settings provide a mechanism for a user to control the behavior of a ``cmd2``
 based application. A setting is stored in an instance attribute on your
-subclass of :class:`cmd2.cmd2.Cmd` and must also appear in the
-:attr:`cmd2.cmd2.Cmd.settable` dictionary. Developers may set default values
+subclass of :class:`cmd2.Cmd` and must also appear in the
+:attr:`cmd2.Cmd.settable` dictionary. Developers may set default values
 for these settings and users can modify them at runtime using the
 :ref:`features/builtin_commands:set` command. Developers can
 :ref:`features/settings:Create New Settings` and can also
@@ -28,12 +28,12 @@ instruct the terminal to apply colors or text styling (i.e. bold) to the
 output. The ``allow_style`` setting controls the behavior of these escape
 sequences in output generated with any of the following methods:
 
-- :meth:`.cmd2.Cmd.poutput`
-- :meth:`.cmd2.Cmd.perror`
-- :meth:`.cmd2.Cmd.pwarning`
-- :meth:`.cmd2.Cmd.pexcept`
-- :meth:`.cmd2.Cmd.pfeedback`
-- :meth:`.cmd2.Cmd.ppaged`
+- :meth:`cmd2.Cmd.poutput`
+- :meth:`cmd2.Cmd.perror`
+- :meth:`cmd2.Cmd.pwarning`
+- :meth:`cmd2.Cmd.pexcept`
+- :meth:`cmd2.Cmd.pfeedback`
+- :meth:`cmd2.Cmd.ppaged`
 
 This setting can be one of three values:
 
@@ -51,7 +51,7 @@ debug
 ~~~~~
 
 The default value of this setting is ``False``, which causes the
-:meth:`~.cmd2.Cmd.pexcept` method to only display the message from an
+:meth:`~cmd2.Cmd.pexcept` method to only display the message from an
 exception. However, if the debug setting is ``True``, then the entire stack
 trace will be printed.
 
@@ -75,14 +75,14 @@ command.
 feedback_to_output
 ~~~~~~~~~~~~~~~~~~
 
-Controls whether feedback generated with the :meth:`~cmd2.cmd2.Cmd.pfeedback`
+Controls whether feedback generated with the :meth:`~cmd2.Cmd.pfeedback`
 method is sent to ``sys.stdout`` or ``sys.stderr``. If ``False`` the output
 will be sent to ``sys.stderr``
 
 If ``True`` the output is sent to ``stdout`` (which is often the screen but may
 be :ref:`redirected <features/redirection:Output Redirection and Pipes>`). The
 feedback output will be mixed in with and indistinguishable from output
-generated with :meth:`~cmd2.cmd2.Cmd.poutput`.
+generated with :meth:`~cmd2.Cmd.poutput`.
 
 
 max_completion_items
@@ -101,7 +101,7 @@ the description text of the CompletionItem.
 quiet
 ~~~~~
 
-If ``True``, output generated by calling :meth:`~.cmd2.Cmd.pfeedback` is
+If ``True``, output generated by calling :meth:`~cmd2.Cmd.pfeedback` is
 suppressed. If ``False``, the :ref:`features/settings:feedback_to_output`
 setting controls where the output is sent.
 
@@ -153,13 +153,13 @@ Hide Builtin Settings
 ----------------------
 
 You may want to prevent a user from modifying a builtin setting. A setting
-must appear in the :attr:`cmd2.cmd2.Cmd.settable` dictionary in order for it
+must appear in the :attr:`cmd2.Cmd.settable` dictionary in order for it
 to be available to the :ref:`features/builtin_commands:set` command.
 
 Let's say that you never want end users of your program to be able to enable
 full debug tracebacks to print out if an error occurs. You might want to hide
 the :ref:`features/settings:debug` setting. To do so, remove it from the
-:attr:`cmd2.cmd2.Cmd.settable` dictionary after you initialize your object::
+:attr:`cmd2.Cmd.settable` dictionary after you initialize your object::
 
   class MyApp(cmd2.Cmd):