Typo fixes in Environments Tutorial (#12107)

1 files changed, 11 insertions, 11 deletions

diff --git a/lib/spack/docs/tutorial_environments.rst b/lib/spack/docs/tutorial_environments.rst
index 5b46987be1..cbbdc4ab8a 100644
--- a/lib/spack/docs/tutorial_environments.rst
+++ b/lib/spack/docs/tutorial_environments.rst
@@ -5,9 +5,9 @@
 
 .. _environments-tutorial:
 
-================================================
-Environments, ``spack.yaml``, and ``spack.lock``
-================================================
+=====================
+Environments Tutorial
+=====================
 
 We've shown you how to install and remove packages with Spack.  You can
 use :ref:`cmd-spack-install` to install packages,
@@ -19,7 +19,7 @@ customize Spack's installation with configuration files like
 If you build a lot of software, or if you work on multiple projects,
 managing everything in one place can be overwhelming. The default ``spack
 find`` output may contain many packages, but you may want to *just* focus
-on packages a particular project.  Moreover, you may want to include
+on packages for a particular project.  Moreover, you may want to include
 special configuration with your package groups, e.g., to build all the
 packages in the same group the same way.
 
@@ -710,7 +710,7 @@ install the project's dependencies.  They need only clone the repository,
 
 Spack concretizes the specs in the ``spack.yaml`` file and installs them.
 
-What happened here?  If you ``cd`` into a directory tha has a
+What happened here?  If you ``cd`` into a directory that has a
 ``spack.yaml`` file in it, Spack considers this directory's environment
 to be activated.  The directory does not have to live within Spack; it
 can be anywhere.
@@ -754,7 +754,7 @@ So, from ``~/code``, we can actually manipulate ``spack.yaml`` using
 ``spack.lock``
 ^^^^^^^^^^^^^^
 
-Ok, we've covered managed environments, environments in directories, and
+Okay, we've covered managed environments, environments in directories, and
 the last thing we'll cover is ``spack.lock``. You may remember that when
 we ran ``spack install``, Spack concretized all the specs in the
 ``spack.yaml`` file and installed them.
@@ -763,7 +763,7 @@ Whenever we concretize Specs in an environment, all concrete specs in the
 environment are written out to a ``spack.lock`` file *alongside*
 ``spack.yaml``.  The ``spack.lock`` file is not really human-readable
 like the ``spack.yaml`` file.  It is a ``json`` format that contains all
-the information that we need to ``reproduce`` the build of an
+the information that we need to *reproduce* the build of an
 environment:
 
 .. code-block:: console
@@ -802,11 +802,11 @@ be either a ``spack.yaml`` or a ``spack.lock`` file:
 Both of these create a new environment called ``my-project``, but which
 one you choose to use depends on your needs:
 
-  1.  copying the yaml file allows someone else to build your *requirements*,
-      potentially a different way.
+#. copying the yaml file allows someone else to build your *requirements*,
+   potentially a different way.
 
-  2. copying the lock file allows someone else to rebuild your
-     *installation* exactly as you built it.
+#. copying the lock file allows someone else to rebuild your
+   *installation* exactly as you built it.
 
 The first use case can *re-concretize* the same specs on new platforms in
 order to build, but it will preserve the abstract requirements.  The