I would like to transform an original Rmd file into another Rmd file before it is passed to knitr, so I'm attempting to use pre_knit listed in output_format(). Consider the following .Rmd input,
---
output:
pdf_document
---
```{r preformat, echo=FALSE}
cap = function(x){if(knitr::is_latex_output()) sprintf("\\textsc{%s}",x) else x}
```
## R Markdown
This is an R Markdown ~cap(document with formatting)~.
but ideally I would like to specify all this in the Rmd YAML header. I can't seem to make this work though; what would be the right place for this custom pre_knit hook in YAML? (and how to avoid an infinite loop by removing it for the next run?) Something like this,
---
output:
pdf_document:
pre_knit: mypkg::custom_format
---
```{r preformat, echo=FALSE}
cap = function(x){if(knitr::is_latex_output()) sprintf("\\textsc{%s}",x) else x}
```
## R Markdown
This is an R Markdown ~cap(document with formatting)~.
Side-note: currently the two ways I can think of to achieve this with arbitrarily-defined formatting tags would be:
pandoc filters
a valid R syntax, as in ``r cap("document with formatting")`, which is quite burdensome.
It kind of works, as a workaround; it might be tidier to modify the metadata between the two runs rather than create a temporary file. I'm still curious if there's a way to directly call pre_knit somewhere in the YAML.
I think one option could be that you create your own output format using rmarkdown::output_format(). This function as the pre_knit argument your are looking for. You can get inspired by how existing format in rmarkdown works or other package that offer new format.
I guess the lack of documentation reflects the fact that knit: (and the elusive pre_knit: functionality I was after) isn't something one is expected to use. For what it's worth I think it is a workable strategy with the existing toolchain, i.e. in one knit click I get the desired transformation
but it feels very hackish. I've been reflecting on the whole Rmd toolchain, and in my view instead of pursuing this pre_knit tag further, with a setup like this
pandoc filters aren't easy to get into (and the pandocfilters package is seriously lacking in documentation), but this feels like a robust and powerful approach, by-passing many current limitations in knitr and rmarkdown (because basically R could do literally anything between both ASTs, with full access to the document's structure – which node is code, text, header, etc.)