gh-1178: Fix indentation in a few more pages (#1181)

getting-started/pull-request-lifecycle.rst

@@ -241,15 +241,15 @@ should do to help ensure that your pull request is accepted.
 ``patchcheck`` is a simple automated patch checklist that guides a developer
 through the common patch generation checks. To run ``patchcheck``:
 
-   On *Unix* (including macOS)::
+On *Unix* (including macOS)::
 
-      make patchcheck
+   make patchcheck
 
-   On *Windows* (after any successful build):
+On *Windows* (after any successful build):
 
-   .. code-block:: dosbatch
+.. code-block:: dosbatch
 
-      python.bat Tools\patchcheck\patchcheck.py
+   python.bat Tools\patchcheck\patchcheck.py
 
 The automated patch checklist runs through:
 

internals/garbage-collector.rst

@@ -131,15 +131,15 @@ class instances, classes in extension modules, etc. One could think that
 cycles are uncommon but the truth is that many internal references needed by
 the interpreter create cycles everywhere. Some notable examples:
 
-    * Exceptions contain traceback objects that contain a list of frames that
-      contain the exception itself.
-    * Module-level functions reference the module's dict (which is needed to resolve globals),
-      which in turn contains entries for the module-level functions.
-    * Instances have references to their class which itself references its module, and the module
-      contains references to everything that is inside (and maybe other modules)
-      and this can lead back to the original instance.
-    * When representing data structures like graphs, it is very typical for them to
-      have internal links to themselves.
+* Exceptions contain traceback objects that contain a list of frames that
+  contain the exception itself.
+* Module-level functions reference the module's dict (which is needed to resolve globals),
+  which in turn contains entries for the module-level functions.
+* Instances have references to their class which itself references its module, and the module
+  contains references to everything that is inside (and maybe other modules)
+  and this can lead back to the original instance.
+* When representing data structures like graphs, it is very typical for them to
+  have internal links to themselves.
 
 To correctly dispose of these objects once they become unreachable, they need to be
 identified first.  Inside the function that identifies cycles, two doubly linked
@@ -417,13 +417,13 @@ word-aligned addresses end in ``000``, leaving the last 3 bits available.
 The CPython GC makes use of two fat pointers that correspond to the extra fields
 of ``PyGC_Head`` discussed in the `Memory layout and object structure`_ section:
 
-  .. warning::
+.. warning::
 
-      Because the presence of extra information, "tagged" or "fat" pointers cannot be
-      dereferenced directly and the extra information must be stripped off before
-      obtaining the real memory address. Special care needs to be taken with
-      functions that directly manipulate the linked lists, as these functions
-      normally assume the pointers inside the lists are in a consistent state.
+   Because the presence of extra information, "tagged" or "fat" pointers cannot be
+   dereferenced directly and the extra information must be stripped off before
+   obtaining the real memory address. Special care needs to be taken with
+   functions that directly manipulate the linked lists, as these functions
+   normally assume the pointers inside the lists are in a consistent state.
 
 
 * The ``_gc_prev`` field is normally used as the "previous" pointer to maintain the

internals/parser.rst

@@ -890,7 +890,7 @@ To activate verbose mode you can add the ``-d`` flag when executing Python:
     $ python -d file_to_test.py
 
 This will print **a lot** of output to ``stderr`` so is probably better to dump it to a file for further analysis. The output
-consists of trace lines with the following structure:
+consists of trace lines with the following structure::
 
     <indentation> ('>'|'-'|'+'|'!') <rule_name>[<token_location>]: <alternative> ...
 
@@ -902,9 +902,10 @@ character marks the type of the trace:
 * ``+`` indicates that a rule has been parsed correctly.
 * ``!`` indicates that an exception or an error has been detected and the parser is unwinding.
 
-The <token_location> part indicates the current index in the token array, the
-<rule_name> part indicates what rule is being parsed and the <alternative> part
-indicates what alternative within that rule is being attempted.
+The ``<token_location>`` part indicates the current index in the token array,
+the ``<rule_name>`` part indicates what rule is being parsed and
+the ``<alternative>`` part indicates what alternative within that rule
+is being attempted.
 
 
 References

testing/coverage.rst

@@ -111,7 +111,7 @@ long as your venv is activated. For more info on venv see `Virtual Environment
 
 If this does not work for you for some reason, you should try using the
 in-development version of coverage.py to see if it has been updated as needed.
-To do this you should clone/check out the development version of coverage.py:
+To do this you should clone/check out the development version of coverage.py::
 
     git clone https://github.com/nedbat/coveragepy