Apply suggestions from Adam's review

Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>

Author: alecbcs

tutorial_environments.rst

@@ -19,7 +19,7 @@ So far in this tutorial, we've covered the basic commands for managing individua
 .. Customizing Spack's installation with configuration files, like
    `packages.yaml <https://spack.readthedocs.io/en/latest/build_settings.html#build-settings>`_, was also discussed.
 
-Now we'll explore Spack Environments -- a powerful feature that let's us manage collections of packages together in a documented and reproducible way.
+Now we'll explore Spack Environments --- a powerful feature that let's us manage collections of packages together in a documented and reproducible way.
 Spack environments are similar to *virtual environments* in other package managers (e.g., `Python venv <https://docs.python.org/3/library/venv.html>`_ or `nix-env <https://nix.dev/manual/nix/2.24/command-ref/nix-env>`_).
 
 -------------------------------
@@ -54,7 +54,7 @@ This tutorial will teach you the fundamentals of creating and using Spack enviro
 We'll cover:
 1. Command line basics -- Creating and managing environments with Spack commands.
 2. Configuration files -- Editing ``spack.yaml`` and understanding ``spack.lock``.
-3. Environment types -- Understanding Spack-managed vs independent environments.
+3. Environment types -- Understanding Spack-managed vs. independent environments.
 4. Reproducible builds -- Sharing and recreating environments across systems.
 
 -------------------
@@ -148,7 +148,7 @@ Let's try it:
    :language: console
 
 Now, ``tcl`` and ``trilinos`` have been registered as **root specs** in our environment. **Root specs** are packages that we've explicitly requested to be installed in an environment.
-They're called **"roots"** because they sit at the top of the dependency graph—when Spack installs these packages, with their respective dependency packages sitting below them.
+They're called **"roots"** because they sit at the top of the dependency graph---when Spack installs these packages, with their respective dependency packages sitting below them.
 
 Now, let's install:
 
@@ -184,7 +184,7 @@ So, adding specs to an environment at a later point in time will not cause exist
 
    Incrementally creating an environment may give us different package
    versions from an environment created all at once.
-   We'll cover later in the tutorial this after we've discussed different
+   We'll cover this later in the tutorial after we've discussed different
    concretization strategies.
 
    Further, there are two other advantages of concretizing and installing an
@@ -216,7 +216,7 @@ This means that executables, libraries, and other files from your environment's
 
 Let's explore how views work using the ``tcl`` package we just installed in our ``myproject`` environment. The Tcl package includes a shell-like application called ``tclsh``.
 
-To can see the path to ``tclsh`` let's use the ``which`` command:
+To see the path to ``tclsh`` let's use the ``which`` command:
 
 .. literalinclude:: outputs/environments/use-tcl-1.out
    :language: console
@@ -238,7 +238,7 @@ Removing Packages from Environments
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 One of Spack's key features is that you can safely remove packages from specific environments without affecting other environments.
-This works because Spack environments only create links to shared package installations—they don't contain the actual package files.
+This works because Spack environments only create links to shared package installations---they don't contain the actual package files.
 
 Let's demonstrate this capability by creating a second environment.
 Imagine we have two projects:
@@ -291,7 +291,7 @@ We can see that ``myproject`` still has ``trilinos`` as a root spec.
 The ``spack.yaml`` file
 -----------------------
 
-An environment is more than just a list of root specs -- it includes **configuration settings** that control how Spack behaves when the environment it activated.
+An environment is more than just a list of root specs --- it includes **configuration settings** that control how Spack behaves when the environment it activated.
 So far, ``myproject`` relies on configuration defaults, but these can be overridden to customize our environment's behavior.
 
 In this section, we'll learn how to enforce that all the packages in our environment depending on ``mpi`` build with ``mpich`` by modifying our configuration.
@@ -313,7 +313,7 @@ There are several important parts of this file:
 * ``concretizer:unify:`` Determines how package specs in the environment are
   concretized together to reduce duplicated dependencies when possible.
 
-The ``specs`` list should look familiar -- these are the package specs we've been modifying previously with ``spack add`` and ``spack install``.
+The ``specs`` list should look familiar --- these are the package specs we've been modifying previously with ``spack add`` and ``spack install``.
 
 The ``concretizer:unify:true`` setting controls how Spack resolves dependencies across packages specs in an environment:
 
@@ -322,7 +322,7 @@ The ``concretizer:unify:true`` setting controls how Spack resolves dependencies
 * ``false``: specs are concretized *independently* from each other,
   potentially allowing multiple versions of the package to appear in the
   environment twice.
-* ``when_possible``: A middle ground -- Spack attempts to unify dependencies
+* ``when_possible``: A middle ground --- Spack attempts to unify dependencies
   as possible but will backoff to allow duplicates when root specs require
   incompatible versions of dependencies.