Should code-line-numbers be optionally hidden on echo: fenced?

[jthomasmock]

When teaching I often use the amazing #| code-line-numbers: + echo: fenced to step through code as well as focused chunk options.

It's awkward to need to address code-line-numbers with learners as it's very seldom appropriate for the current lesson to ALSO cover the code-line-numbers option specifically for presentations as opposed to more general topics that are being shown.

Would it make sense to optionally turn off code-line-numbers showing up with echo: fenced? Or is there an optimal way to avoid showing that chunk option today?

[mcanouil]

Getting back on this, as things might have a little bit changed.

Currently, code-line-numbers is enable globally for revealjs which means when adding echo: fenced will output code-line-numbers: true/false (or any code cell option that is not echo if set in the cell on purpose/by design.

---
title: "Quarto Playground"
format: 
  revealjs: default
  html:
    code-line-numbers: true
---

## This is a playground for Quarto.

```{r}
#| echo: fenced
x <- 0
x + 1
```


```{r}
#| echo: fenced
#| code-line-numbers: false
#| code-fold: false
x <- 0
x + 1
```

A workaround is to define a function (possibly as a knitr hook for easier use, https://bookdown.org/yihui/rmarkdown-cookbook/output-hooks.html):

---
title: "Quarto Playground"
format: 
  revealjs: default
  html:
    code-line-numbers: true
---

```{r}
#| include: false
echo_fenced <- function(txt) {
  knitr::asis_output(paste(
    c(
      "````", "```{r}", txt, "```", "````",
      knitr::knit_child(text = knitr::knit_expand(text = c("```{r}", txt, "```")), quiet = TRUE)
    ),
    collapse = "\n"
  ))
}
```

## This is a playground for Quarto.

```{r}
echo_fenced("#| code-fold: false
x <- 0
x + 1")
```

[cderv]

As you mentioned the hooks, here is an example leveraging knitr hooks. It is like the reimplementation of fenced echo above, quite fragile because highly dependent of knitr internals but this should works.

This is using the source hooks, and not the output hooks, as we want to reformat the source part.

---
title: "Quarto Playground"
format: 
  revealjs: default
---

## This is a playground for Quarto.

```{r, include=FALSE}
local({
  hook_source <- knitr::knit_hooks$get('source')
  knitr::knit_hooks$set(source = function(x, options) {
    x <- hook_source(x, options)
    if (options$fenced.echo) {
      x <- gsub('\n#\\| code-line-numbers: [^\n]*', '', x)
    }
    x
  })
})
```


```{r}
#| echo: fenced
#| code-line-numbers: "1|2"
x <- 0
x + 1
```

Basically, we use source hooks defined by Quarto to write the source chunk but if fenced echo was asked, we remove some content in the formatted string. So we are inserting ourselves after the source hook defined by Quarto for knitr (which contains the fenced echo feature BTW).

Hope it helps.

Would it make sense to optionally turn off code-line-numbers showing up with echo: fenced? Or is there an optimal way to avoid showing that chunk option today?

The question will be - what if a user wants to demo the use of code-line-numbers ? If we remove by default, and there is no way to add it back, this is problematic... Unless we find a way to configure that (but this would add a new option probably 🤔 fenced-ignore: ?

[debruine]

I'm using an invisible character between # and | to hack showing options that I don't want to run.

Copy the code below into something that shows invisible characters; the character in #‎| echo: false shows as a red highlighted ° in RStudio.

```{r}
#| echo: fenced
#| fig-cap: "Code chunks with headers"
#| label: fig-fenced-example
#‎| echo: false
hist(rnorm(100000))
```

The downside of this is that these have to be at the end of options that you do want to both show and run. It also doesn't solve the problem of having options that you want to run but not show.

I'd suggest an alternate syntax for fenced chunks, like:

```{r}
#| echo: fenced
#|- code-fold: false # run, don't show
#|+ echo: false # show, don't run
#| label: fig-fenced-example # show and run
hist(rnorm(100000))
```

[cscheid]

I agree that we need to improve the situation, but that syntax feels pretty hard to teach and remember ("which way does - go again?") in addition, the proposed syntax will make our already fraught YAML-in-comment parsing even more fragile because of the indentation differences.

This part of the code base is super finicky, because it needs cooperation from a number of disparate stakeholders: the quarto-cli program, and all the extensions that process code cell headers. It's unlikely that we will change that anytime soon.