fix up markdown and text width

Author: rickeylev

peps/pep-0796.rst

@@ -52,16 +52,16 @@ benefits:
 * The simpler the process of re-creating the environment, the more reliable
   software can be achieved, and the faster the process can be.
 
-Making it simpler to copy a virtual environment from one host to another mitigates
-these categories of problems. Additionally, the development tools to create a
-virtual environment and install its dependencies aren't needed on the host that
-intends to run the program.
+Making it simpler to copy a virtual environment from one host to another
+mitigates these categories of problems. Additionally, the development tools to
+create a virtual environment and install its dependencies aren't needed on the
+host that intends to run the program.
 
 When the virtual environment doesn't require modifications to be usable, it
 also allows more advanced deployment mechanisms, e.g. remote mounting and
-caching of artifacts. While this PEP on its own isn't sufficient to enable that, it
-allows tools like `bazel` or `venvstacks` to more easily prepare constrained
-environments that allow for such use cases.
+caching of artifacts. While this PEP on its own isn't sufficient to enable
+that, it allows tools like ``bazel`` or ``venvstacks`` to more easily prepare
+constrained environments that allow for such use cases.
 
 Rationale
 =========
@@ -73,11 +73,13 @@ customizing how it's computed. Without the ability to specify where the
 supporting Python runtime files are, the interpreter can't finish startup,
 so other hook points (e.g. ``site`` initialization) never trigger.
 
-Tools that currently look to enable virtual environment portability across machines do
-so either by relying on undocumented interpreter behaviour (`bazel`, omitting the `home`
-key entirely to trigger an implementation dependent fallback to resolving via a symlinked
-interpreter binary on non-Windows systems) or by requiring a post-installation script to
-be executed after the environment is placed in its target location (`venvstacks`).
+Tools that currently look to enable virtual environment portability across
+machines do so either by relying on undocumented interpreter behaviour
+(``bazel``, omitting the ``home`` key entirely to trigger an implementation
+dependent fallback to resolving via a symlinked interpreter binary on
+non-Windows systems) or by requiring a post-installation script to be executed
+after the environment is placed in its target location (``venvstacks``).
+
 Specification
 =============
 
@@ -138,18 +140,20 @@ Backwards Compatibility
 =======================
 
 
-Tools that work around the absolute `home` key limitation the way `bazel` and `venvstacks`
-currently do (omitting the `home` key, or editing it after moving the environment) will be
-unaffected.
+Tools that work around the absolute ``home`` key limitation the way ``bazel``
+and ``venvstacks`` currently do (omitting the ``home`` key, or editing it after
+moving the environment) will be unaffected.
 
-While the PEP author and sponsor aren't aware of any projects that work around the limitation
-by carefully controlling the current working directory used to launch the deployed Python
-environments on target systems, any such projects would be unaffected if they already ensured
-the working directory was set to the folder containing `pyvenv.cfg` (which seems like a plausible
-choice, since that is typically the root directory of the virtual environment). In the even more
-unlikely case where that assumption doesn't hold, tools generating relative virtual environment
-paths will typically be aware of the underlying base runtime Python version, and hence able to
-update the emitted relative path accordingly.
+While the PEP author and sponsor aren't aware of any projects that work around
+the limitation by carefully controlling the current working directory used to
+launch the deployed Python environments on target systems, any such projects
+would be unaffected if they already ensured the working directory was set to
+the folder containing ``pyvenv.cfg`` (which seems like a plausible choice,
+since that is typically the root directory of the virtual environment). In the
+even more unlikely case where that assumption doesn't hold, tools generating
+relative virtual environment paths will typically be aware of the underlying
+base runtime Python version, and hence able to update the emitted relative path
+accordingly.
 
 
 How to Teach This
@@ -207,8 +211,8 @@ dynamically compute it by checking if the current executable (which is
 typically the venv's ``bin/python3`` symlink) is a symlink and, if so, use
 where that points as ``PYTHONHOME``.
 
-While currently used as a workaround by some tools, *standardising* this behavior
-is undesirable for a couple reasons:
+While currently used as a workaround by some tools, *standardising* this
+behavior is undesirable for a couple reasons:
 
 1. It presents platform-specific issues, namely with Windows. Windows does
    support symlinks, but not by default, and it can require special