djvanderlaan
Add a new top-level flag `eval=...` ?
I have one vignette where in the top-level setup bit a logical variable is set, and depending on its value knitr will eval a chunk, or just pass it to pandoc for pretty printing.
Could you add a toggle like that?
I am not completely sure I understand what you mean. Is it something like
---
eval: false
---
```{.R}
x <- 1+1
```
where none of the .R blocks are evaluated? So that would be the same as just like running pandoc directly on the original file.
My initial thought when reading your suggestion was that you wanted something like:
```{.R}
foo <- TRUE
```
```{.R eval=foo}
x <- 1+1
```
```{.R}
y <- 1+1
```
where the first block is not evaluated but second is; or, simpler, just:
```{.R eval=false}
x <- 1+1
```
```{.R}
y <- 1+1
```
I think that actually, all three options are already possible (the behaviour; not the syntax of course) with a bit of creative use of custom filter functions. However, that doesn't mean that the package shouldn't support this with a simpler syntax.
I ended up switching the vignette where I needed this to a simple 'no knit' mode of using your package chiefly to call pandoc to typeset. In conjunction with the css file I use there we other side effects. I will try to take a look on the about a simple example ( like the above). My ideal would have to have the 'just call pandoc' feature use be (visually) indistinguishable from the (programmatically) 'skip eval here' use, that wasn't yet the case (and the blame may well be with the css I 'borrowed / adapted' from minidown).
I put a really quick and simple example together: one input file, the resulting html and the css it uses. The bases non-weaving parts work. On the weaving part I am confused. There are two issue:
- a 'silent' block is not silent (possibly a side effect of my css use, but can you may not create any output?
- a conditional block appears to ignore the (boolean) toggle and runs in both cases.
I fixed the first issue. Not completely sure what the best solution is for the second one. Problem is that the arguments of the code blocks are parsed by pandoc. I could of course, in cases where the parsed argument is not a logical but a string, evaluate the string.
There is already a solution withing the existing 'framework': define your own output function:
```{.R #setup results=FALSE echo=FALSE}
isWindows <- Sys.info()[["sysname"]] == "Windows"
on_windows <- function(...) {
if (isWindows) output_eval(...) else ""
}
on_linux <- function(...) {
if (!isWindows) output_eval(...) else ""
}
```
### Use it
This should not show the date as I am Linux.
```{.R #use1 fun=on_windows}
Sys.Date()
```
### Use other case
This shouls show the date as I am on Linux.
```{.R #use2 fun=on_linux}
Sys.Date()
```
which results in (on my system, which is linux):
### Use it
This should not show the date as I am Linux.
### Use other case
This shouls show the date as I am on Linux.
``` {#use2 .R}
> Sys.Date()
[1] "2022-02-04"
```
Not sure if this is a user friendly enough solution, but it is flexible. Any ideas on this?
That's pretty good! And a further generalization would be just one function (say, fun=my_output) which then outputs or not given on some system resource (say something else installed, or platform, or network connectivity). I presume it will 'listen' to a global toggle we set in the setup block (and possibly even alter later) ?
The 'display' issue is a bit of a nag but I agree that it is likely from the CSS. For that reason, I switched (for now) away from any eval in that one vignette.
One other thing I realized was that I could not call bash or python or ... from simplermarkdown. That may be out of scope so for a new vignette where I needed it I switched back to knitr/rmarkdown and pdf.
Yes, I translated your example as literally as possible. But there is a lot of flexibility. Your function can read any global variables or options that you have set in your environment, so the logic can be quite complex.
The fix from issue #23 fixes the display issue you mention right? Empty code blocks are now removed by default.
There is a function evaluate_code_block that currently calls the function in the fun= argument of the block when the language is equal to R. It is quite easy to call other functions when the language is something else. I did leave room for other languages than R. For bash this should not be too difficult. For python, assuming you want to keep state between code blocks, you will probably have to use something like reticulate. I'll make issues for these. The bash one I might pick up. I'll leave the python one for somebody else to pick up for now :smile:
Sorry. Still too early here and I got up two hours ago :) I completely missed #23 in the above. Will rebuild and test -- thanks a big bunch for that.
'Other languages' is clearly tertiary. I was noodling a little with a vignette for RcppRedis where showing shell and python is cute. Just being able to do shell would alread be pretty cool and other 'shebang' entry points like Python may be simple if we simply say 'if it runs we capture it' -- i.e don't aim for complexity or reticulate here. Doable? (I still luuuuv the overall 'we just wrap pandoc sanely approach.)
FWIW the input for a simple 'let me talk with three languages' to a local Redis server (if you have one) is here for now: https://github.com/eddelbuettel/rcppredis/blob/master/vignettes/rmd/redis-intro.Rmd
It's tucked away in a subdir when I use the Mark vdL trick to sweave around pre-made pdf vignettes -- another blunt tool to avoid complexity :). The resulting pdf (in my own / somewhat specific / used in a few vignettes) two-column style is attached for kicks. Not saying simplermarkdown should do all that, but doing other shell and alike tricks may be feasible.
redis-intro.pdf
I think I have this working (of course without the persistence of variables etc between code blocks). See the fix for issue #24.