Improve knitr engine doc and spell "R Markdown" with a space

Debugging.Rmd

@@ -392,14 +392,14 @@ f(10)
 
 Print debugging is particularly useful for compiled code because it's not uncommon for the compiler to modify your code to such an extent you can't figure out the root problem even when inside an interactive debugger.
 
-### RMarkdown
-\index{debugging!RMarkdown}
+### R Markdown
+\index{debugging!R Markdown}
 
 <!-- Adapted from https://whattheyforgot.org/debugging-r-code.html#debugging-in-rmarkdown-documents -->
 
-Debugging code inside RMarkdown files requires some special tools. First, if you're knitting the file using RStudio, switch to calling `rmarkdown::render("path/to/file.Rmd")` instead. This runs the code in the current session, which makes it easier to debug. If doing this makes the problem go away, you'll need to figure out what makes the environments different.
+Debugging code inside R Markdown files requires some special tools. First, if you're knitting the file using RStudio, switch to calling `rmarkdown::render("path/to/file.Rmd")` instead. This runs the code in the current session, which makes it easier to debug. If doing this makes the problem go away, you'll need to figure out what makes the environments different.
 
-If the problem persists, you'll need to use your interactive debugging skills. Whatever method you use, you'll need an extra step: in the error handler, you'll need to call `sink()`. This removes the default sink that knitr uses to capture all output, and ensures that you can see the results in the console. For example, to use `recover()` with RMarkdown, you'd put the following code in your setup block:
+If the problem persists, you'll need to use your interactive debugging skills. Whatever method you use, you'll need an extra step: in the error handler, you'll need to call `sink()`. This removes the default sink that knitr uses to capture all output, and ensures that you can see the results in the console. For example, to use `recover()` with R Markdown, you'd put the following code in your setup block:
 
 ```{r, eval = FALSE}
 options(error = function() {
@@ -410,7 +410,7 @@ options(error = function() {
 
 This will generate a "no sink to remove" warning when knitr completes; you can safely ignore this warning.
 
-If you simply want a traceback, the easiest option is to use `rlang::trace_back()`, taking advantage of the `rlang_trace_top_env` option. This ensures that you only see the traceback from your code, instead of all the functions called by RMarkdown and knitr.
+If you simply want a traceback, the easiest option is to use `rlang::trace_back()`, taking advantage of the `rlang_trace_top_env` option. This ensures that you only see the traceback from your code, instead of all the functions called by R Markdown and knitr.
 
 ```{r, eval = FALSE}
 options(rlang_trace_top_env = rlang::current_env())

Introduction.Rmd

@@ -28,7 +28,7 @@ If you are new to R, you might wonder what makes learning such a quirky language
   graphic you're trying to do, chances are that someone has already tried
   to do it and you can learn from their efforts.
 
-* Powerful tools for communicating your results. [RMarkdown][rmarkdown] makes
+* Powerful tools for communicating your results. [R Markdown][rmarkdown] makes
   it easy to turn your results into HTML files, PDFs, Word documents,
   PowerPoint presentations, dashboards and more. [Shiny][shiny] allows you to
   make beautiful interactive apps without any knowledge of HTML or javascript.

Names-values.Rmd

@@ -222,7 +222,7 @@ knitr::include_graphics("diagrams/name-value/binding-3.png")
 
 This behaviour is called __copy-on-modify__. Understanding it will radically improve your intuition about the performance of R code. A related way to describe this behaviour is to say that R objects are unchangeable, or __immutable__. However, I'll generally avoid that term because there are a couple of important exceptions to copy-on-modify that you'll learn about in Section \@ref(modify-in-place). 
 
-When exploring copy-on-modify behaviour interactively, be aware that you'll get different results inside of RStudio. That's because the environment pane must make a reference to each object in order to display information about it. This distorts your interactive exploration but doesn't affect code inside of functions, and so doesn't affect performance during data analysis. For experimentation, I recommend either running R directly from the terminal, or using RMarkdown (like this book).
+When exploring copy-on-modify behaviour interactively, be aware that you'll get different results inside of RStudio. That's because the environment pane must make a reference to each object in order to display information about it. This distorts your interactive exploration but doesn't affect code inside of functions, and so doesn't affect performance during data analysis. For experimentation, I recommend either running R directly from the terminal, or using R Markdown (like this book).
 
 ### `tracemem()`
 \indexc{tracemem()}

Perf-improve.Rmd

@@ -70,7 +70,7 @@ mean1 <- function(x) mean(x)
 mean2 <- function(x) sum(x) / length(x)
 ```
 
-I recommend that you keep a record of everything you try, even the failures. If a similar problem occurs in the future, it'll be useful to see everything you've tried. To do this I recommend RMarkdown, which makes it easy to intermingle code with detailed comments and notes.
+I recommend that you keep a record of everything you try, even the failures. If a similar problem occurs in the future, it'll be useful to see everything you've tried. To do this I recommend [R Markdown](https://rmarkdown.rstudio.com/), which makes it easy to intermingle code with detailed comments and notes.
 
 Next, generate a representative test case. The case should be big enough to capture the essence of your problem but small enough that it only takes a few seconds at most. You don't want it to take too long because you'll need to run the test case many times to compare approaches. On the other hand, you don't want the case to be too small because then results might not scale up to the real problem. Here I'm going to use 100,000 numbers:
 

README.md

@@ -29,7 +29,7 @@ Book:
 
 * Preview at 100% matches physical size of book. Maxiumum diagram width is 11cm.
 
-RMarkdown
+R Markdown
 
 * Remove dpi specification from `include_graphics()`, instead relying
   on `common.R`. Chunk should have `output.width = NULL`.

Rcpp.Rmd

@@ -344,7 +344,19 @@ bench::mark(
 
 NB: if you run this code, you'll notice that `meanC()` is much faster than the built-in `mean()`. This is because it trades numerical accuracy for speed.
 
-For the remainder of this chapter C++ code will be presented stand-alone rather than wrapped in a call to `cppFunction`. If you want to try compiling and/or modifying the examples you should paste them into a C++ source file that includes the elements described above. This is easy to do in RMarkdown: all you need to do is specify `engine = "Rcpp"`. 
+For the remainder of this chapter, C++ code will be presented stand-alone rather than wrapped in a call to `cppFunction`. If you want to try compiling and/or modifying the examples, you should paste them into a C++ source file that includes the elements described above. This is easy to do in R Markdown: all you need to do is specifying the right [knitr language engine chunk option](https://yihui.org/knitr/options/#language-engines):
+
+````rmd
+```{engine = "Rcpp"}
+```
+````
+
+or [just](https://bookdown.org/yihui/rmarkdown/language-engines.html)
+
+````rmd
+```{Rcpp}
+```
+````
 
 ### Exercises {#exercise-started}