-
DescriptionI'm working on exploring a bit more as it relates to custom cell engines, e.g. I am perplexed by "inline options" or options declared immediately after the engine. For example, we have: ---
title: "Cell Options"
format: native
---
### Inline
```{custom-r, option1=value1, option2=value2}
# code here
1 + 1
```
### Hashpipe
```{custom-r}
#| option1: value1
#| option2: value2
# code here
1 + 1
```The rendered output in HTML would be: 
Switching over to the native structure, the inline code cell options seem to be converting the Is this output correct? Shouldn't it be passed down as a |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 5 replies
-
|
What if a you use YAML style which is the style used and recommended in Quarto? There's might be some knitr specific behaviour here (either directly in knitr or the in R codebase in Quarto) |
Beta Was this translation helpful? Give feedback.
-
|
So, the "hashpipe" style or YAML style shown after "inline" works great. I've already implemented a custom per-code cell parser. The issue above crept up as I had someone ask in an e-mail about why the "traditional rmarkdown" syntax wasn't working. I'm not sold that it's a
|
Beta Was this translation helpful? Give feedback.
-
|
I would really recommend to tell Quarto users to use YAML style when using Quarto. This being said, did you try in regular rmarkdown/knitr documents?
Edit: I noticed afterwards you implied that YAML did not work for both engines. |
Beta Was this translation helpful? Give feedback.
-
This is knitr only - It has nothing to do with Quarto. Quarto has no knowledge of inline options. This syntax with options after engine, that was used in R Markdown ecosystem, is the historical knitr way of passing options. When the engine is known by knitr, then what is after the engine is parsed as options provided with R syntax. Quarto does know about YAML options syntax for validation and auto completion, but regarding cell evaluation, it will defer to knitr for options parsing (the YAML parsing code for those options are in knitr). For Jupyter, it will handle it though.
There is no really issue here. You get the same results with knitr or jupyter because And here, your observation is mixed up because you are putting the two cells in one document. The cell with inline option causing the other one to have parsing problem. With Pandoc reader when encountering the cell with inline options, the native representation is what you see (Para), because this is not valid CodeBlock syntax in Pandoc's Markdown. So pandoc parser does not see it as a CodeBlock. Let's me try to be clearer with commenting your code ### Inline
```{custom-r, option1=value1, option2=value2} <-- `custom-r` is unknown, so passed as is by engine to quarto and then to pandoc and this is not valid Pandoc's markdown so Para
# code here
1 + 1
``` <-- This is seen by Pandoc as start of a code block
### Hashpipe
```{custom-r}
#| option1: value1
#| option2: value2
# code here
1 + 1
``` <-- this is matched as the end of the code block. Anything in between being part of it. If you do try to convert only with HAspipe ---
title: "Cell Options"
format: native
---
### Hashpipe
```{custom-r}
#| option1: value1
#| option2: value2
# code here
1 + 1
```
Then you'll get something more clear This representation is I believe what shinylive relies one. I hope this helps understand. Though, let me say you are playing with edge case and internals. Quarto does not have yet an extension mechanism for Custom engines. So anything you can do with it in Lua could be broken when we do decide to add some pre engine processing, or a mechanism for custom engine. Though webR extension, and shinylive are using part of it, so obviously we'll make sure they don't break. Anyhow, I hope my explanation clarifies. Feel free to ask more if still some questions. |
Beta Was this translation helpful? Give feedback.
-
|
@cderv thank you for the detailed explanation! The explanation was a great help in understanding what was happening and why I was seeing oddness in the One quick follow-up, I suppose this means that registered cell engines with ```{custom, option1=value1, option2=value2}
```To: ```{.custom .value1}
# Evaluated code
```
**Custom Option 2** Before being passed into Pandoc? This would (roughly) match with the description of 8.5.2.3 Extension: fenced_code_attributes On the note of edge cases and internals, I'm aware that "here be dragons" 🐉 . Part of the reason for the question was the outputs just didn't make sense. Plus, for some reason, I thought inline support was ubiquitous and wanted to make sure the new cell options system I'm working on supported it. Now I know... |
Beta Was this translation helpful? Give feedback.
-
Not exactly. First inline options or in-chunk YAML options are the same for knitr - they both will be parsed as options for the engine. Using inline chunk options syntax has no relation to Pandoc's syntax. If you were to register Also, knitr won't specifically set some classes or attributes on the output code block. Though in Quarto context, unknown options from knitr and Quarto (so could apply to a new custom engine), engine options will be set as code attributes - not classes. I would not rely on that as this is not a feature per se but an internal behavior useful in some case. Just wanted to be precised in case you happen to do some testing and notice it. Just showing those examples to help understand---
title: "Untitled"
format: native
keep-md: true
---
```{r, custom="nothing"}
# empty
```
```{r}
#| custom: "nothing"
# empty
```
```{r}
#| include: false
knitr::knit_engines$set(custom = function(options) {
options$lang <- "default"
options$code <- "From custom engine"
knitr::knit_engines$get("cat")(options)
})
```
```{custom}
#| custom: nothing
```
See that
Hope it helps |
Beta Was this translation helpful? Give feedback.
-
|
To add to the complication of the scenario: Pandoc 3 does not natively support the following syntax See: In pandoc 2, you get: In order to parse this correctly, quarto needs to use a custom reader (see |
Beta Was this translation helpful? Give feedback.
This is knitr only - It has nothing to do with Quarto. Quarto has no knowledge of inline options.
This syntax with options after engine, that was used in R Markdown ecosystem, is the historical knitr way of passing options.
When the engine is known by knitr, then what is after the engine is parsed as options provided with R syntax.
Quarto does know about YAML options syntax for validation and auto completion, but regarding cell evaluation, it will defer to knitr for options parsing (the YAML parsing code for those options are in knitr). For Jupyter, it will handle it though.