I'm writing a tutorial using knitr and I want to show some of the warnings and errors that students might encounter. While I'm capable of nicely displaying the code chunks within the box using the tidy=TRUE option, I don't understand how to handle the display of warnings and errors. For example, if I have the following code:
\documentclass{article}
\begin{document}
<<setupOp, include=FALSE>>=
opts_chunk$set(tidy=TRUE,
tidy.opts=list(blank=FALSE, width.cutoff=20))
#
<<ErrorTest>>=
warning(paste("A suuuuuuuuuuuuuuuuuper", "loooooooooooong waaaaaaaaaaaaarning"))
#
\end{document}
The warning code line is nicely displayed within the box, but the warning itself stretch beyond the box. I have a feeling that it has to do with the fact that the warning message is one very long string, but I don't know how to tell knitr to keep the warning inside the box. I've looked at the documentation on knitr chunk options and this formatR info, but I can't find the solution.
Thanks!
LaTeX is trying to generate a left and right justified block of text here. That means word-wrapping and hyphenating to get a nice straight right edge. Your warning has long words in it, LaTeX doesn't hyphenate typewriter text, so it overfills the box allocated for it and prints an overfull warning to the TeX log file.
Even if it could hyphenate the text, it might struggle finding a good place to hyphenate an odd word. For example, you should never break "buttoned" across lines as "but-toned". TeX has a complicated algorithm for this.
A solution may be to set \raggedright for your R blocks:
{
\raggedright
<<setupOp, include=FALSE>>=
opts_chunk$set(tidy=TRUE,
tidy.opts=list(blank=FALSE, width.cutoff=20))
#
<<ErrorTest>>=
warning(paste("A suuuuuuuuuuuuuuuuuper", "loooooooooooong waaaaaaaaaaaaarning"))
#
}
Like this, TeX should start a new line whenever a word would go outside the box. Enclose in a curly-bracket pair so normal text is unaffected. I don't know what else this might affect within the code block, so caveat emptor.
Related
Edit: I am using RStudio
Up till now, while commenting something, I was using % symbol. Alternatively, I am just using Ctrl+Shift+C shortcut, which results in commenting with % or %' (or # for chunks).
The problem is, even if I comment something, it still often causes compilation errors. Look at the part of screenshot below:
Lines 1 to 23 are fully commented and document starts at line 24. However, even if parts of the code are commented out and shouldn't affect it, they for some reason still results in errors.
If I move code from lines 24to32 at the very beginning of the file, it compiles without problems. I thought that maybe there can't be comments at the beginning of the file, but looks like it's not an issue, as trying things like moving \documentclass{article} at the very beginning still results in errors, even though there are less of them.
How can I comment lines, so they won't be calling compilation errors?
First, Make sure that all the lines you don't need are "correctely"commented.
Then, i think that you can't put commented code on the top of your document, also avoid to put commented code on your document it's a lousy code.
Let's say you have an R markdown document that will not render cleanly.
I know you can set the knitr chunk option error to TRUE to request that evaluation continue, even in the presence of errors. You can do this for an individual chunk via error = TRUE or in a more global way via knitr::opts_chunk$set(error = TRUE).
But sometimes there are errors that are still fatal to the knitting process. Two examples I've recently encountered: trying to unlink() the current working directory (oops!) and calling rstudioapi::getVersion() from inline R code when RStudio is not available. Is there a general description of these sorts of errors, i.e. the ones beyond the reach of error = TRUE? Is there a way to tolerate errors in inline R code vs in chunks?
Also, are there more official ways to halt knitting early or to automate debugging in this situation?
To exit early from the knitting process, you may use the function knitr::knit_exit() anywhere in the source document (in a code chunk or inline expression). Once knit_exit() is called, knitr will ignore all the rest of the document and write out the results it has collected so far.
There is no way to tolerate errors in inline R code at the moment. You need to make sure inline R code always runs without errors1. If errors do occur, you should see the range of lines that produced the error from the knitr log in the console, of the form Quitting from lines x1-x2 (filename.Rmd). Then you can go to the file filename.Rmd and see what is wrong with the lines from x1 to x2. Same thing applies to code chunks with the chunk option error = FALSE.
Beyond the types of errors mentioned above, it may be tricky to find the source of the problem. For example, when you unintentionally unlink() the current directory, it should not stop the knitting process, because unlink() succeeded anyway. You may run into problems after the knitting process, e.g., LaTeX/HTML cannot find the output figure files. In this case, you can try to apply knit_exit() to all code chunks in the document one by one. One way to achieve this is to set up a chunk hook to run knit_exit() after a certain chunk. Below is an example of using linear search (you can improve it by using bisection instead):
#' Render an input document chunk by chunk until an error occurs
#'
#' #param input the input filename (an Rmd file in this example)
#' #param compile a function to compile the input file, e.g. knitr::knit, or
#' rmarkdown::render
knit_debug = function(input, compile = knitr::knit) {
library(knitr)
lines = readLines(input)
chunk = grep(all_patterns$md$chunk.begin, lines) # line number of chunk headers
knit_hooks$set(debug = function(before) {
if (!before) {
chunk_current <<- chunk_current + 1
if (chunk_current >= chunk_num) knit_exit()
}
})
opts_chunk$set(debug = TRUE)
# try to exit after the i-th chunk and see which chunk introduced the error
for (chunk_num in seq_along(chunk)) {
chunk_current = 0 # a chunk counter, incremented after each chunk
res = try(compile(input))
if (inherits(res, 'try-error')) {
message('The first error came from line ', chunk[chunk_num])
break
}
}
}
This is by design. I think it is a good idea to have error = TRUE for code chunks, since sometimes we want to show errors, for example, for teaching purposes. However, if I allow errors for inline code as well, authors may fail to recognize fatal errors in the inline code. Inline code is normally used to embed values inline, and I don't think it makes much sense if an inline value is an error. Imagine a sentence in a report like The P-value of my test is ERROR, and if knitr didn't signal the error, it will require the authors to read the report output very carefully to spot this issue. I think it is a bad idea to have to rely on human eyes to find such mistakes.
IMHO, difficulty debugging an Rmd document is a warning that something is wrong. I have a rule of thumb: Do the heavy lifting outside the Rmd. Do rendering inside the Rmd, and only rendering. That keeps the Rmd code simple.
My large R programs look like this.
data <- loadData()
analytics <- doAnalytics(data)
rmarkdown::render("theDoc.Rmd", envir=analytics)
(Here, doAnalytics returns a list or environment. That list or environment gets passed to the Rmd document via the envir parameter, making the results of the analytics computations available inside the document.)
The doAnalytics function does the complicated calculations. I can debug it using the regular tools, and I can easily check its output. By the time I call rmarkdown::render, I know the hard stuff is working correctly. The Rmd code is just "print this" and "format that", easy to debug.
This division of responsibility has served me well, and I can recommend it. Especially compared to the mind-bending task of debugging complicated calculations buried inside a dynamically rendered document.
I really like RStudio's code sections because they help me keep my code organized and makes navigation very easy. So, the code/comment line for code sections look like this (the key for RStudio to recognize the code section is that the comment should end with four or more #, - or =).
# Section One ---------------------------------
# Section Two =================================
### Section Three #############################
Now, I also find very useful "Compiling Notebooks from R Scripts" because you can produce reports directly from your script (which I find much more comfortable working with) without having to write an RMarkdown document. You simply have to use roxygen2-style comments (using #' as prefix) and they will be converted to markdown and/or use #+ or #- prefixes to control RMarkdown chunk options.
Now, I want the best of both worlds but I cannot find a way to get it. I want to have code sections (recognizable for RStudio) in the report (with the proper markdown for headings #, but without the extra #### at the end of the line). Seems like an impossible task to me. If I use #' prefix, I get the section in the report but RStudio does not recognize it as a code section. If I do not use roxygen2-style comments, RStudio recognizes the code section but it does not appear in the report (ok, it appears but as an ugly comment in the formatted code). The best solution I have found so far is to use the #+ prefix and simulate a code chunk label. That way I can get RStudio to recognize it as a code section, and it does not appear in the report as an ugly comment.
Any ideas on how to do this better?
I would like to adjust the print margins in tinn-R so the code stays on each line. I am trying to print some code but it wraps on to the next line and becomes less easy to read.
I have found the wrap text option but this simply chops off the end of the line. I use Rstudio but the print options are limited and my colleague suggested tinn-R which is better as it prints code formatted with colour.
I will happily take suggestions of other IDEs with good printing options.
Thanks
David
David,
The best option is decrease font size (the default shortcut is Ctrl+Shift+Down) of the editor (or Rterm) to get the document fits within the print page.
In time, the Tinn-R project has its own discussion list: https://groups.google.com/forum/?fromgroups#!forum/tinn-r
All the best,
J.C.Faria
Right alignment comes handy for letter addresses. Unfortunately, according to the author John MacFarlane:
The pandoc document model does not allow for alignment other than in tables, so the alignment information is simply ignored.
We can resort to raw LaTeX.
Upon trial and error (and googling) I found that this TeX syntax works as intended:
\rightline{Address 1}
\rightline{Address 2}
\rightline{etc}
Also the LaTeX equivalent does:
\begin{flushright}
Address 1\\
Address 2\\
etc
\end{flushright}
The less invasive syntax, based on the LaTeX command raggedleft, unfortunately does not work:
{\raggedleft
Address 1\\
Address 2\\
etc\\
}
This is because braces are passed verbatim (\{, \}) and not as raw LaTeX.
With reference to centre alignment, I found a user claiming that markdown supports this native (beautiful) syntax:
-> This is center align <-
but I didn't find an editor/converter supporting it.
Indeed my working examples are all against the John Gruber markdown philosophy:
A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
Can you find a better way?
Particularly is it possible to simply write a Pandoc template to redefine the alignment of a header, say: ###### Right aligned?
For those that are looking for a similar question here's how to left align/right align on the same line:
**Some bolded text** **\hfill some right aligned on same line bolded text**
You'll have to imagine the result since I'm not sure how to recreate it on SO.
The best way to handle this is to put the address in a YAML metadata block (supported by pandoc 1.12+), and do the alignment in a custom template. Then your source document will be clean, without raw LaTeX, and you can modify templates to get the desired look in any output format.
Source document could look like this:
---
address:
| 23 Main St.
| Somewhere, MT 23434
...
Dear so and so,
Then in your LaTeX template you'd have something like:
\begin{flushright}
$address$
\end{flushright}
If you're writing a letter, though, it would probably be better to write a template using the LaTeX letter class.