You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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/shakesselect * from character```
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:
knitr
engineCons:
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 toexplain
who runs what cells. I can imagine a TypeScript API that could do so.The text was updated successfully, but these errors were encountered: