Formatting doesn't work for indented blocks

[DavisVaughan]

It is somewhat common to have indented code blocks, like within a bulleted list.

These get borked by Quarto when invoking a formatter on them because the formatter gets a virtual document and removes the "extraneous" indentation

This is enough to make someone turn off formatting in quarto docs (like @hadley) because it completely borks them

* My item

  ```{r}
  1 + 1
  ```

* My other item

Screen.Recording.2025-09-04.at.9.31.32.AM.mov

[cscheid]

This will be a lot easier to handle when we go to https://github.com/quarto-dev/quarto-markdown. (We have started experimenting with it earlier this week, so it's coming sooner rather than later)

[cscheid]

I want to explain the whole situation here so we can discuss a design.

For this kind of problem, formatters (and quarto-cli both) need to worry not only about indentation but also other trivia like > (block quotes):

> ```{r}
> cat("hello, world")
> ```

There are other tangential concerns that are quarto-cli specific, but still interact with the location of executable code cells. The first one is uniformity across engine execution.

Currently, engine: jupyter and engine: julia both fundamentally don't support code cells anywhere besides the top level of the document. (This is because code cells must exist by themselves in a separate ipynb cell, and engine: julia uses the .ipynb format as a transport format.)

engine: knitr goes through knitr, and knitr supports indented code cells (inside bulletlist and orderedlist items). At the same time, knitr also (in my opinion, buggily) executes everything that matches a regular expression, including executable code cells inside other code-block-like nodes (like RawBlock and CodeBlock nodes). If knitr users want code cells to not be executed, they need to use the {{r}} ("escaped syntax")

I think every engine in quarto misbehaves in some way:

• julia and jupyter should support code cells in non-toplevel locations
• knitr shouldn't execute code cells inside raw blocks and non-executable code blocks.

This distinction matters for Positron because .qmd documents that contain Python code cells execute through engine: jupyter by default, and so the experience in Positron is disjointed because the experience in quarto-cli is disjointed.

Instead, my opinion is that quarto should plan to deprecate this escaped syntax, and that the determination of the execution of code cells should happen based on the syntax of the document (instead of the lexical structure). We should try to make the rules consistent across all engines, and across all tooling.

In other words, the same determination should control the behavior of air. Alternatively, quarto-cli could take over formatting in these cases, delegating the code cells to air, ruff, or whatever, and then assembling the formatted .qmd file.

This is all doable when we have https://github.com/quarto-dev/quarto-markdown up and running solidly.