Feature Request: Logic-less templating for includes

[stephan-koenig]

Hi all,

I was wondering if logic-less templating for includes would be of interest.

Let's say I have a parent.qmd and want to run multiple t-tests by passing variables (referenced maybe by {{< include.var <name> >}}) into an include of _t_test.qmd, before any code engines are evaluated.

parent.qmd

---
format: html
---

## t-test

Let's do some t-tests!

```{r}
df <- filter(iris, Species != virginica)
```

{{< include _t_test.qmd data="df" predictor="Species" outcome="Sepal.Length" >}}

{{< include _t_test.qmd data="df" predictor="Species" outcome="Petal.Width" >}}

_t_test.qmd

---
format: html
---

Let's look at how `{{< include.var outcome >}}` varies for `{{< include.var predictor >}}` in `{{< include.var data >}}`.

```{r}
t.test({{< include.var outcome >}} ~ {{< include.var predictor >}},
       data = {{< include.var data >}})
```

So, for example ,{{< include _t_test.qmd data="df" predictor="Species" outcome="Sepal.Length" >}} would generate the following from _t_test.qmd and include it in parent.qmd when rendered:

---
format: html
---

Let's look at how `Sepal.Length` varies for `Species` in `df`.

```{r}
t.test(Sepal.Length ~ Species,
       data = df)
```

Would a feature like that make sense, or can a similar effect be achieved another way?

[cscheid]

It's an intriguing suggestion! However, we are quite wary of feature creep on {{< include >}}, because its semantics are surprisingly complicated (we are already on our third implementation of it...)

I wholeheartedly agree that we need a better story around parameterized documents, but I don't think the best implementation is in terms of the current incarnation of include.

[stephan-koenig]

Ok, this follow-up suggestion might fly into the face of how things are implemented, but I think it describes the general idea.

How about creating a new shortcode evaluated before or at the same rendering step as a regular include? Let's call it process, Using one of the examples above:

{{< process _t_test.qmd data="df" predictor="Species" outcome="Sepal.Length" >}}

Inside of _t_test.qmd, maybe one of the existing variable categories (env?) in Quarto could be used. I imagine the following steps:

• process starts rendering _t_test.qmd providing any defined variables as env variables.
• After all variables are filled in _t_test.qmd, a temporary file is created (without executing code, rendering markdown, or any other steps).
• The temporary file is added to the parent document using include.