Do not apply epigraph style to all block quotes

Correct indentation where appropriate for stanzas that should not be
rendered as `<blockquote>` HTML elements.

Closes GH-10686

doc/_themes/sphinx13/static/sphinx13.css

@@ -273,7 +273,7 @@ div.quotebar {
     margin-left: 1em;
 }
 
-blockquote {
+blockquote.epigraph {
     font-size: 1.5em;
     padding-left: 1rem;
     margin-left: 0;

doc/extdev/index.rst

@@ -97,49 +97,49 @@ in which a Sphinx project is built: this works in several phases.
 
 **Phase 0: Initialization**
 
-   In this phase, almost nothing of interest to us happens.  The source
-   directory is searched for source files, and extensions are initialized.
-   Should a stored build environment exist, it is loaded, otherwise a new one is
-   created.
+In this phase, almost nothing of interest to us happens.  The source
+directory is searched for source files, and extensions are initialized.
+Should a stored build environment exist, it is loaded, otherwise a new one is
+created.
 
 **Phase 1: Reading**
 
-   In Phase 1, all source files (and on subsequent builds, those that are new or
-   changed) are read and parsed.  This is the phase where directives and roles
-   are encountered by docutils, and the corresponding code is executed.  The
-   output of this phase is a *doctree* for each source file; that is a tree of
-   docutils nodes.  For document elements that aren't fully known until all
-   existing files are read, temporary nodes are created.
+In Phase 1, all source files (and on subsequent builds, those that are new or
+changed) are read and parsed.  This is the phase where directives and roles
+are encountered by docutils, and the corresponding code is executed.  The
+output of this phase is a *doctree* for each source file; that is a tree of
+docutils nodes.  For document elements that aren't fully known until all
+existing files are read, temporary nodes are created.
 
-   There are nodes provided by docutils, which are documented `in the docutils
-   documentation <https://docutils.sourceforge.io/docs/ref/doctree.html>`__.
-   Additional nodes are provided by Sphinx and :ref:`documented here <nodes>`.
+There are nodes provided by docutils, which are documented `in the docutils
+documentation <https://docutils.sourceforge.io/docs/ref/doctree.html>`__.
+Additional nodes are provided by Sphinx and :ref:`documented here <nodes>`.
 
-   During reading, the build environment is updated with all meta- and cross
-   reference data of the read documents, such as labels, the names of headings,
-   described Python objects and index entries.  This will later be used to
-   replace the temporary nodes.
+During reading, the build environment is updated with all meta- and cross
+reference data of the read documents, such as labels, the names of headings,
+described Python objects and index entries.  This will later be used to
+replace the temporary nodes.
 
-   The parsed doctrees are stored on the disk, because it is not possible to
-   hold all of them in memory.
+The parsed doctrees are stored on the disk, because it is not possible to
+hold all of them in memory.
 
 **Phase 2: Consistency checks**
 
-   Some checking is done to ensure no surprises in the built documents.
+Some checking is done to ensure no surprises in the built documents.
 
 **Phase 3: Resolving**
 
-   Now that the metadata and cross-reference data of all existing documents is
-   known, all temporary nodes are replaced by nodes that can be converted into
-   output using components called transforms.  For example, links are created
-   for object references that exist, and simple literal nodes are created for
-   those that don't.
+Now that the metadata and cross-reference data of all existing documents is
+known, all temporary nodes are replaced by nodes that can be converted into
+output using components called transforms.  For example, links are created
+for object references that exist, and simple literal nodes are created for
+those that don't.
 
 **Phase 4: Writing**
 
-   This phase converts the resolved doctrees to the desired output format, such
-   as HTML or LaTeX.  This happens via a so-called docutils writer that visits
-   the individual nodes of each doctree and produces some output in the process.
+This phase converts the resolved doctrees to the desired output format, such
+as HTML or LaTeX.  This happens via a so-called docutils writer that visits
+the individual nodes of each doctree and produces some output in the process.
 
 .. note::
 

doc/latex.rst

@@ -407,12 +407,16 @@ Keys that don't need to be overridden unless in special cases are:
 ``'geometry'``
    "geometry" package inclusion, the default definition is:
 
-     ``'\\usepackage{geometry}'``
+   .. code:: latex
+
+      '\\usepackage{geometry}'
 
    with an additional ``[dvipdfm]`` for Japanese documents.
    The Sphinx LaTeX style file executes:
 
-     ``\PassOptionsToPackage{hmargin=1in,vmargin=1in,marginpar=0.5in}{geometry}``
+   .. code:: latex
+
+      \PassOptionsToPackage{hmargin=1in,vmargin=1in,marginpar=0.5in}{geometry}
 
    which can be customized via corresponding :ref:`'sphinxsetup' options
    <latexsphinxsetup>`.

doc/usage/configuration.rst

@@ -14,12 +14,12 @@ This file (containing Python code) is called the "build configuration file"
 and contains (almost) all configuration needed to customize Sphinx input
 and output behavior.
 
-  An optional file `docutils.conf`_ can be added to the configuration
-  directory to adjust `Docutils`_ configuration if not otherwise overridden or
-  set by Sphinx.
+An optional file `docutils.conf`_ can be added to the configuration
+directory to adjust `Docutils`_ configuration if not otherwise overridden or
+set by Sphinx.
 
-  .. _`docutils`: https://docutils.sourceforge.io/
-  .. _`docutils.conf`: https://docutils.sourceforge.io/docs/user/config.html
+.. _`docutils`: https://docutils.sourceforge.io/
+.. _`docutils.conf`: https://docutils.sourceforge.io/docs/user/config.html
 
 The configuration file is executed as Python code at build time (using
 :func:`importlib.import_module`, and with the current directory set to its
@@ -419,9 +419,9 @@ General configuration
    :literal:`:manpage:`man(1)`` role will link to
    <https://manpages.debian.org/man(1)>. The patterns available are:
 
-     * ``page`` - the manual page (``man``)
-     * ``section`` - the manual section (``1``)
-     * ``path`` - the original manual page and section specified (``man(1)``)
+   * ``page`` - the manual page (``man``)
+   * ``section`` - the manual section (``1``)
+   * ``path`` - the original manual page and section specified (``man(1)``)
 
    This also supports manpages specified as ``man.1``.
 

doc/usage/extensions/autosummary.rst

@@ -48,14 +48,14 @@ The :mod:`sphinx.ext.autosummary` extension does this in two parts:
 
    produces a table like this:
 
-       .. currentmodule:: sphinx
+   .. currentmodule:: sphinx
 
-       .. autosummary::
+   .. autosummary::
 
-          environment.BuildEnvironment
-          util.relative_uri
+      environment.BuildEnvironment
+      util.relative_uri
 
-       .. currentmodule:: sphinx.ext.autosummary
+   .. currentmodule:: sphinx.ext.autosummary
 
    Autosummary preprocesses the docstrings and signatures with the same
    :event:`autodoc-process-docstring` and :event:`autodoc-process-signature`

doc/usage/extensions/napoleon.rst

@@ -94,38 +94,38 @@ Docstring Sections
 
 All of the following section headers are supported:
 
-    * ``Args`` *(alias of Parameters)*
-    * ``Arguments`` *(alias of Parameters)*
-    * ``Attention``
-    * ``Attributes``
-    * ``Caution``
-    * ``Danger``
-    * ``Error``
-    * ``Example``
-    * ``Examples``
-    * ``Hint``
-    * ``Important``
-    * ``Keyword Args`` *(alias of Keyword Arguments)*
-    * ``Keyword Arguments``
-    * ``Methods``
-    * ``Note``
-    * ``Notes``
-    * ``Other Parameters``
-    * ``Parameters``
-    * ``Return`` *(alias of Returns)*
-    * ``Returns``
-    * ``Raise`` *(alias of Raises)*
-    * ``Raises``
-    * ``References``
-    * ``See Also``
-    * ``Tip``
-    * ``Todo``
-    * ``Warning``
-    * ``Warnings`` *(alias of Warning)*
-    * ``Warn`` *(alias of Warns)*
-    * ``Warns``
-    * ``Yield`` *(alias of Yields)*
-    * ``Yields``
+* ``Args`` *(alias of Parameters)*
+* ``Arguments`` *(alias of Parameters)*
+* ``Attention``
+* ``Attributes``
+* ``Caution``
+* ``Danger``
+* ``Error``
+* ``Example``
+* ``Examples``
+* ``Hint``
+* ``Important``
+* ``Keyword Args`` *(alias of Keyword Arguments)*
+* ``Keyword Arguments``
+* ``Methods``
+* ``Note``
+* ``Notes``
+* ``Other Parameters``
+* ``Parameters``
+* ``Return`` *(alias of Returns)*
+* ``Returns``
+* ``Raise`` *(alias of Raises)*
+* ``Raises``
+* ``References``
+* ``See Also``
+* ``Tip``
+* ``Todo``
+* ``Warning``
+* ``Warnings`` *(alias of Warning)*
+* ``Warn`` *(alias of Warns)*
+* ``Warns``
+* ``Yield`` *(alias of Yields)*
+* ``Yields``
 
 Google vs NumPy
 ~~~~~~~~~~~~~~~

doc/usage/installation.rst

@@ -208,9 +208,9 @@ You can read more about them in the `Python Packaging User Guide`_.
    Note that in some Linux distributions, such as Debian and Ubuntu,
    this might require an extra installation step as follows.
 
-    .. code-block:: console
+   .. code-block:: console
 
-       $ apt-get install python3-venv
+      $ apt-get install python3-venv
 
 Docker
 ------

doc/usage/restructuredtext/domains.rst

@@ -516,7 +516,8 @@ For functions with optional parameters that don't have default values
 (typically functions implemented in C extension modules without keyword
 argument support), you can use brackets to specify the optional parts:
 
-   .. py:function:: compile(source[, filename[, symbol]])
+.. py:function:: compile(source[, filename[, symbol]])
+   :noindex:
 
 It is customary to put the opening bracket before the comma.