ideas improvement for Quarto

[cderv]

This is a list we can turn in potential issue of ideas for improving Quarto support. This comes from works done on the R part of Quarto using knitr

• verbatim engine and related should probably be echo: = TRUE even when global is echo = FALSE (e.g I want to hide all chunk source for my R code, but still want to show what I embeded)
• fenced.echo in Quarto should show original code chunk content, even when code or file option is passed
  This would probably require storing original code partition, in addition to yaml option partition.

[malcolmbarrett]

I was just coming to file an issue for the first item, as I just tripped myself up on that. Strong +1!

[atusy]

verbatim engine and related should probably be echo: = TRUE even when global is echo = FALSE

This sounds concordant to the purpose of using the verbatime engine, however, such exceptional behaviors can be confusing...
So I would say no...
Once users face troubles from an exception, they does not only have to solve it, but may also have to examine if similar exceptions would not trouble them.
That can be really time consuming.

I can think of some scenarios that authors may want to globally set echo = FALSE and apply it also to the verbatim engine.
For example, an author may want to control the echo option based on output format:

• when HTML, the author wants to include chunk source and chunk options in the output so that the author can self-review without going back to qmd file
• when PDF, the author wants to exclude chunk source and chunk options because the author only wants to report results

[cderv]

Thanks for your input @atusy !

For the context, this came up in the context of output formats that would set echo: false as a default. (revealjs format does this in Quarto). In such context, using {verbatim} will output nothing unless the user remembers to set echo: true on this verbatim chunk (or add a hook to do it on all verbatim chunks).

verbatim engine is among the engine that does not have outputs. Their outputs is in fact the source code being printed in a special way. So they are already an exception compared to other chunks.

So usually, when verbatim chunk is used in a document, this is for the purpose of having source code formated and shown in the output document. This is different than a source code chunk (e.g. {r}) with eval: false and echo: true, which seems more to me like what you described - "the author wants to exclude chunk source and chunk options because the author only wants to report results" - for verbatim the results in the code source itself, so if they want to include results they need echo: true

So I would have thought the scenario would be

• I don't want to show the code source of all my evaluated chunk, though I want to the have all my raw code formatted example included in my report.
  • Currently for this I need global echo: false and add echo: true to all my verbatim engine.

I did not seem to me as a good default as I view verbatim evaluation as an output.

TBH, when we implemented verbatim code chunk, we did the easy way using already existing cat engine, but I think I would have made more like other chunk where the output of the chunk would have been a raw markdown formatted code chunk.

Anyhow, this is detailed context on why I added this idea for a special hooks behavior for verbatim.

[atusy]

Oops, sorry for misunderstanding the behavior of the verbatim engine.
Now it makes sense to introduce the special hook.

BTW, the context from revealjs is one of the case that I am afraid of.
An exceptional behavior in somewhere would require additional exceptional behaviors in somewhere else...
That may increase the complexity of the whole ecosystem, including implementations.

[yihui]

I don't have a strong opinion on the behavior of the verbatim engine when echo = FALSE. Both the current behavior and the proposed new behavior are acceptable to me. I agree that it will be much less surprising to users if echo = FALSE is ignored for verbatim chunks. If we do that, we also need to consider what if users do want to hide verbatim chunks via a chunk option (i.e., which chunk option should they use?).

On a weakly related note, the complexity here comes from the fact that knitr parses the Rmd document using regular expressions, otherwise we could simply write verbatim content using the normal Markdown syntax, e.g.,

````md
Some *verbatim* content.

```{r}
1 + 1
```
````

instead of

````{verbatim, lang="md"}
Some *verbatim* content.

```{r}
1 + 1
```
````

I have implemented a new parser in another package (not publicly available yet) based on commonmark::markdown_xml(). With that parser, the first example above will work.