update some documentation pages due to option syntax change (#142)

_posts/2012-01-25-output.md

@@ -16,7 +16,7 @@ As introduced in the [main manual](https://github.com/downloads/yihui/knitr/knit
 
 These options are orthogonal to each other, so you are free to turn on/off one type of output without affecting other pieces.
 
-By default, `echo` and `eval` can take values from an R expression, which brings the feature of conditional evaluation introduced in the main manual. In short, `eval=dothis` means the real value of `eval` is taken from a variable named `dothis` in the global environment; by manipulating this variable, we can turn on/off the evaluation of a batch of chunks.
+Note all [options](/knitr/options) in **knitr** can take values from R expressions, which brings the feature of conditional evaluation introduced in the main manual. In short, `eval=dothis` means the real value of `eval` is taken from a variable named `dothis` in the global environment; by manipulating this variable, we can turn on/off the evaluation of a batch of chunks.
 
 ## Advanced usage of the `echo` option
 
@@ -34,11 +34,11 @@ plot(mtcars[, 4:5])
 
 The `par()` expression is not essential to this code chunk, and it is even distracting to the readers, so we may want to hide it in the output. In this particular case, we do not want the first expression (comments) either; `echo=3:4` means the third and fourth expressions are to be included in the output. Note the index of an expression is not necessarily the same as its line number. Alternatively, we can use `echo=-(1:2)` to remove the first two expressions.
 
-R code for `echo` that contains commas should be treated carefully because the commas will be parsed as option separators (e.g. `echo=c(1, 3)`), so you must escape the commas as `\,` (e.g. `echo=c(1\, 3)`). It may be confusing to the reader if you select a discrete subset of the source code; often times we should use `a:b` or `-(a:b)` to select a (relatively) complete subset.
+It may be confusing to the reader if you select a discrete subset of the source code; often times we should use `a:b` or `-(a:b)` to select a (relatively) complete subset. However, nobody can stop you from doing so:
 
 {% highlight r %}
 % select 3rd and 5th expressions
-<<hide-par, echo=c(3\, 5)>>=
+<<hide-par, echo=c(3, 5)>>=
 ## 'ugly' code that I do not want to show
 par(mar = c(4, 4, 0.1, 0.1), cex.lab = 0.95, cex.axis = 0.9, 
     mgp = c(2, 0.7, 0), tcl = -0.3) 

index.md

@@ -29,23 +29,24 @@ The ideas are borrowed from other packages, and some of them are re-implemented
 - *faithful* output: using [**evaluate**](http://cran.r-project.org/package=evaluate) as the backend to evaluate R code, **knitr** writes everything that you see in an R terminal into the output by default, including printed results, plots and even warnings, messages as well as errors (they should not be ignored in serious computations, especially warnings)
   - a minor issue is that for grid-based graphics packages like **ggplot2** or **lattice**, users often forget to `print()` the plot objects, because they can get the output in an R terminal without really `print()`ing; in **knitr**, what you get is what you expected
 - built-in cache: ideas like **cacheSweave** but **knitr** directly uses base R functions to fulfill cache and lazy loading, and another significant difference is that a cached chunk can still have output (in **cacheSweave**, cached chunks no longer have any output, even you explicitly `print()` an object; **knitr** actually caches the chunk output as well)
-- formatting R code: the [**formatR**](https://github.com/yihui/formatR/wiki) package is used to reformat R code automatically (wrap long lines, add spaces and indent, etc), without sacrificing comments as `keep.source = FALSE` does
-- more than 20 graphics devices are directly supported: with `dev = CairoPNG` in the chunk options, you can switch to the `CairoPNG()` device in [**Cairo**](http://cran.r-project.org/package=Cairo) in a second; with `dev = tikz`, the `tikz()` device in [**tikzDevice**](http://cran.r-project.org/package=tikzDevice) is used; how things can be even easier? These built-in devices (strictly speaking, wrappers) use inches as units, even for bitmap devices (pixels are converted to inches by the option `dpi`, which defaults to 72)
+- formatting R code: the [**formatR**](https://github.com/yihui/formatR/wiki) package is used to reformat R code automatically (wrap long lines, add spaces and indent, etc), without sacrificing comments as `keep.source=FALSE` does
+- more than 20 graphics devices are directly supported: with `dev='CairoPNG'` in the chunk options, you can switch to the `CairoPNG()` device in [**Cairo**](http://cran.r-project.org/package=Cairo) in a second; with `dev='tikz'`, the `tikz()` device in [**tikzDevice**](http://cran.r-project.org/package=tikzDevice) is used; how things can be even easier? These built-in devices (strictly speaking, wrappers) use inches as units, even for bitmap devices (pixels are converted to inches by the option `dpi`, which defaults to 72)
 - even more flexibility on graphics: 
-  - width and height in the output document of plots can be additionally specified (the `fig.width` option is for the graphics device, and `out.width` is for the output document; think `out.width=.8\textwidth`)
-  - locations of plots can be rearranged: they can either appear exactly in the place where they are created, or go to the end of a chunk together (option `fig.show=hold`)
-  - multiple plots per code chunk are recorded, unless you really  want to keep the last plot only (option `fig.keep=last`)
+  - width and height in the output document of plots can be additionally specified (the `fig.width` option is for the graphics device, and `out.width` is for the output document; think `out.width='.8\\textwidth'`)
+  - locations of plots can be rearranged: they can either appear exactly in the place where they are created, or go to the end of a chunk together (option `fig.show='hold'`)
+  - multiple plots per code chunk are recorded, unless you really  want to keep the last plot only (option `fig.keep='last'`)
 - R code not only can come from code chunks in the input document, but also may be from an external R script, which makes it easier to run the code as you write the document (this will especially benefit LyX)
 - for power users, further customization is still possible:
   - the regular expressions to parse R code can be defined, i.e., you do not have to use `<<>>=` and `@` or `\Sexpr{}`; if you like, you can use any patterns, e.g., `%% begin.rcode` and `%% end.rcode`
   - hooks can be defined to control the output; e.g. you may want to put errors in red bold texts, or you want the source code to be italic, etc; hooks can also be defined to be executed before or after a code chunk, and there are infinite possibilities to extend the power of this package by hooks (e.g. animations, rgl 3D plots, ...)
 
-Lots of efforts have been made to producing beautiful output and enhancing readability by default. For example, code chunks are highlighted and put in a shaded environment in LaTeX with a very light gray background (the [**framed**](http://www.ctan.org/pkg/framed) package), so they can stand out a little bit from other texts. The reading experience is hopefully better than the `verbatim` or `Verbatim` environments. The leading characters `>` and `+` (called prompts) in the output are *not* added by default (you can bring them back by `prompt = TRUE`, though). I find them really annoying in the output when I read the output document, because it is so very inconvenient to copy and run the code which is messed up by these characters.
+Lots of efforts have been made to producing beautiful output and enhancing readability by default. For example, code chunks are highlighted and put in a shaded environment in LaTeX with a very light gray background (the [**framed**](http://www.ctan.org/pkg/framed) package), so they can stand out a little bit from other texts. The reading experience is hopefully better than the `verbatim` or `Verbatim` environments. The leading characters `>` and `+` (called prompts) in the output are *not* added by default (you can bring them back by `prompt=TRUE`, though). I find them really annoying in the output when I read the output document, because it is so very inconvenient to copy and run the code which is messed up by these characters.
 
 ## Acknowledgements
 
 I thank the authors of Sweave, pgfSweave, cacheSweave, brew, decumar, R2HTML, tikzDevice, highlight, digest, evaluate, roxygen2 and of course, R, for the many inspiring ideas and tools. I really appreciate the [feedback](https://github.com/yihui/knitr/issues) from many early beta testers. This package was initiated based on the design of decumar.
 
 ## Misc
 
-Obviously the package name `knitr` was coined with `weave` in mind, and it also aims to be *neater*. I thank [Hadley](http://had.co.nz), [Di](http://dicook.public.iastate.edu) and [Andrew](http://www.stat.tamu.edu/~aredd/site/) for discussions on this neat name.
+Obviously the package name `knitr` was coined with `weave` in mind, and it also aims to be *neater*. I thank [Hadley](http://had.co.nz), [Di](http://dicook.public.iastate.edu) and [Andrew](http://www.stat.tamu.edu/~aredd/site/) for discussions on this neat name.
+