SQL cell (and others?) in jupyter engine and ipython kernel

[cscheid]

It might make sense for us to leverage cell magics to support (eg) a native sql cell in the same way that knitr does it.

Pros:

• it's a popular request
• it would us get closer to matching the behavior in the knitr engine

Cons:

• it would make it even harder for beginners to reason about what engine is responsible for what execution. Specifically, cell magics are specific to the ipython kernel
• it would not solve the problem for other jupyter kernels

If we continue to increase the ways in which different engines interpret {language} cells, I think it would be a good idea for quarto to be able to explain who runs what cells. I can imagine a TypeScript API that could do so.

[eitsupi]

How about adding a filter to remove cell magic and an option to set the language of the output code block as desired (Same as knitr's lang chunk option), as like https://github.com/CenterOnBudget/quarto-stata-facade?

I imagine the following. This would be versatile (works with any cell magic).

source

```{python}
#| output-language: sql
%%sql postgresql://will:longliveliz@localhost/shakes
select * from character

output

````markdown
```sql
select * from character

[cscheid]

The problem is that this filter needs to happen before jupyter execution, and our current infrastructure has pandoc running after jupyter (and knitr).

With that said, we will be eventually changing quarto to support two pandoc passes (pre-engine and post-engine), but that's on a 1.5-1.6 timeline.