Open cderv opened 1 year ago
I was just coming to file an issue for the first item, as I just tripped myself up on that. Strong +1!
verbatim
engine and related should probably beecho: = TRUE
even when global isecho = 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:
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
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
.
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.
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.
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 beecho: = TRUE
even when global isecho = 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 whencode
orfile
option is passed This would probably require storing original code partition, in addition to yaml option partition.