Do not override rmarkdown theme for pdf vignettes

[jeroen]

If the vignette is intended to be rendered to PDF, that is probably better.

[HenrikBengtsson]

Makes sense; I guess that's how it already works for other PDF producing vignette engines, e.g. utils::Sweave, knitr::knitr, R.rsp::rsp, ...

[jeroen]

I haven't figured out what is the canonical way to determine if a given vignette would produce a pdf

[HenrikBengtsson]

I don't think you can. You need to build each vignette and check what you've got. I guess you can try to make a clever guess based on a known vignette engines to minimize the risk of having to rebuild the vignette.

Technically, I think you could write a vignette engine that randomly output a PDF or a HTML file and passes all R checks. Also, FWIW, tools::buildVignette() uses tools:::find_vignette_product() to search for a ^<vignette-name>[.](pdf|html)$ after vignette engine's "weave" method has run.

[jeroen]

R is really weird like that, you render a document and you have no idea what output it will produce.

Even when we know the vignette engine, e.g. %\VignetteEngine{knitr::rmarkdown} then we still can't be sure because the format could be determined by the output property.

[jeroen]

One thing I did fix now is that md.rsp vignettes also get rendered in our standard html theme, just like Rmd vignettes.

[HenrikBengtsson]

I wonder what the solution to inferring the type of vignette product a vignette produces. It would be nice if tools::vignetteInfo() could somehow return this info. Currently, it gives:

> tools::vignetteInfo("vignettes/future-2-output.md.rsp")
$file
[1] "future-2-output.md.rsp"

$title
[1] "A Future for R: Text and Message Output"

$depends
character(0)

$keywords
 [1] "R"               "package"         "vignette"        "future"         
 [5] "promise"         "output"          "standard output" "stdout"         
 [9] "standard error"  "stderr"          "message"         "condition"      

$engine
[1] "R.rsp::rsp"

Maybe it could gain argument tools::vignetteInfo(..., product=TRUE). This could run something like tools::buildVignette(dryrun=TRUE), which would tell the vignette engine to do a dryrun but return mockup information such as weave and tangle output filenames. For vignette engines that don't support "dryrun", it could either give an error, or take the expensive approach and actually run the full vignette.

PS. I mention this since I was actually part of introducing generic vignette engines back in R 3.0.0 (but you can only blame me for part of the design - lots of it was already there, but it would have only worked for knitr). Since then, I've occasionally worked/discussed with Kurt H with some small stuff around vignette engines. My guess there's room and a possibility for improvements.

[jeroen]

My main annoyance with the vignette system is that the "weaving step" (i.e. running the R code to convert a Rmd / md.rsp into a regular md file) is tightly coupled to the rendering step (converting markdown to pdf/html).

It would have been much better if those two steps would be completely decoupled. Often what we want from R is only to do the first part. Once we have the plain markdown file with output, we know what to do. We can convert it to any format with pandoc, or just upload it to github to see it rendered pretty.

[HenrikBengtsson]

Interesting. I agree. FWIW, I've actually got a rudimentary version of this in R.rsp - R.rsp::rfile(..., postprocess = FALSE) - for this purpose but of course, it only works there. It would be useful if something like this would be supported by the weave() function.

There's been very little community discussion on how the vignette framework could be improved and what the needs are. (If not addressed, there's a risk we're ending up with various special hacks (e.g. assuming everything is Rmarkdown because it covers 80%), and then these hacks become the new de facto standard without a solid foundation.)