Update misc.Rmd (#1018)

Fixed typos in chapter 8 (Other components)

misc.Rmd

@@ -9,7 +9,7 @@ But that's not all it takes to make an R package.
 There are other package components that are either required, such as a `DESCRIPTION` file, or highly recommended, such as tests and documentation.
 
 The next few parts of the book are organized around important concepts: dependencies, testing, and documentation.
-But before we dig in to those topics, this chapter demystifies some package parts that are not needed in every package, but that are nice to be aware of.
+But before we dig into those topics, this chapter demystifies some package parts that are not needed in every package, but that are nice to be aware of.
 
 ## Other directories
 
@@ -20,7 +20,7 @@ Here are some top-level directories you might encounter in an R source package,
     As of the second edition, the book no longer covers this topic, since a truly useful treatment of compiled code requires more space than we can give it here.
     The tidyverse generally uses the [cpp11 package](https://cpp11.r-lib.org) to connect C++ to R; most other packages use [Rcpp](https://www.rcpp.org), the most well-established package for integrating R and C++.
 
--   `inst/`: for arbitrary additional files that you want include in your package.
+-   `inst/`: for arbitrary additional files that you want to include in your package.
     This includes a few special files, like the `CITATION`, described below in @sec-misc-inst.
     Other examples of files that might appear below `inst/` include R Markdown templates (see `usethis::use_rmarkdown_template()`) or [RStudio add-ins](https://docs.posit.co/ide/user/ide/guide/productivity/add-ins.html).
 
@@ -35,7 +35,7 @@ Here are some top-level directories you might encounter in an R source package,
 
 -   `exec/`: for executable scripts.
     Unlike files placed in other directories, files in `exec/` are automatically flagged as executable.
-    Empirically, to the extent that R packages are shipping scripts for external interpreters, the `inst/` directory seems to be preferred location these days.
+    Empirically, to the extent that R packages are shipping scripts for external interpreters, the `inst/` directory seems to be the preferred location these days.
 
 -   `po/`: translations for messages.
     This is useful, but beyond the scope of this book.
@@ -92,7 +92,7 @@ Read the `?bibentry` help topic for more details.
 
 ## Configuration tools {#sec-misc-tools}
 
-If a package has a configuration script (`configure` on Unix-alikes, `configure.win` on Windows), it is executed as the first step by `R CMD  INSTALL`. This is typically associated with a package that has a `src/` subdirectory containing C/C++ code and the `configure` script is needed at compile time.
+If a package has a configuration script (`configure` on Unix-alikes, `configure.win` on Windows), it is executed as the first step by `R CMD INSTALL`. This is typically associated with a package that has a `src/` subdirectory containing C/C++ code and the `configure` script is needed at compile time.
 If that script needs auxiliary files, those should be located in the `tools/` directory.
 The scripts below `tools/` can have an effect on the installed package, but the contents of `tools/` will not ultimately be present in the installed package.
 In any case, this is mostly (but not solely) relevant to packages with compiled code, which is beyond the scope of this book.
@@ -101,7 +101,7 @@ We bring this up because, in practice, some packages use the `tools/` directory
 Some packages have periodic maintenance tasks for which it is helpful to record detailed instructions.
 For example, many packages embed some sort of external resource, e.g. code or data:
 
--   Source code and headers for an embedded third party C/C++ library.
+-   Source code and headers for an embedded third-party C/C++ library.
 
 -   Web toolkits.
 
@@ -114,7 +114,7 @@ For example, many packages embed some sort of external resource, e.g. code or da
 These external assets are also usually evolving over time, so they need to be re-ingested on a regular basis.
 This makes it particularly rewarding to implement such housekeeping programmatically.
 
-This is the second, unofficial use of the `tools/` directory, characterized by two big differences with its official purpose: The packages that do this generally do not have a `configure` script and they list `tools/` in `.Rbuildignore`, meaning that these scripts are not included in the package bundle.
-These scripts are maintained in the source package for developer convenience, but are never shipped with the package.
+This is the second, unofficial use of the `tools/` directory, characterized by two big differences from its official purpose: The packages that do this generally do not have a `configure` script and they list `tools/` in `.Rbuildignore`, meaning that these scripts are not included in the package bundle.
+These scripts are maintained in the source package for developer convenience but are never shipped with the package.
 
 This practice is closely related to our recommendation to store the instructions for the creation of package data in `data-raw/` (section @sec-data-data-raw) and to record the method of construction for any test fixtures (section @sec-testing-advanced-concrete-fixture).