Reformating R cell in VSCODE with air does not correctly close chunk

[cderv]

Originally posted at

• Quarto: Reformating R cell in VSCODE does not correctly close chunk posit-dev/air#374 (comment)

But it seems Quarto: Format Cell is a feature from Quarto extension.

---

Not sure where to post this finding, if this is Quarto VSCODE extension that integrates with Air, or Air VSCODE extension that does.

Here is the document

---
title: "kableExtra"
format: html
execute: 
  eval: false
---

## Quarto

```{r}
library(quarto)

# Without helper functions - Markdown won't be processed
basic_data <- data.frame(
  Item = c("Item 1", "Item 2", "Item 3"),
  Description = c("**Bold text**", "*Italic text*", "`Code text`")
)

knitr::kable(basic_data, format = "html", escape = FALSE, caption = "Without Quarto processing")
```

And here is what happens

Positron_ajRdWXG4aJ.mp4

The closing backticks are not correctly placed, and the last parenthesis is removed

[lionel-]

Simpler reprex:

```{r}
list(foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar)
```

The format cell command creates an empty vdoc with the cell contents and calls the language formatter in there. The problem is related to this vdoc containing an extra new line:

quarto/apps/vscode/src/providers/format.ts

Line 208 in 8f99af7

blockLines.push("");

.

If I remove that extra line it fixes the issue. However it causes another issue with:

```{r}

list(foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar, foobar)

```

becomes

```{r}
list(
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar,
    foobar
)```

Which is fixed if I remove the newline added here:

quarto/packages/quarto-core/src/markdown/language.ts

Line 45 in 8f99af7

return token.data + "\n";

With these two fixes we get the expected behaviour with Air because it always adds a newline at the end. I think with a formatter that doesn't do that we'd run into the issue of ending fence at the wrong place again.

Intuitively it seems it would be better to not change the vdoc in any way and then just trim leading and trailing whitespace around the doc. The problem is that our format providers all return text edits (e.g. a diff). They don't change the text eagerly. That's important because AFAIU our document might have been invalidated and our edits might be stale. I guess we could create a new duplicate quarto document, apply the text edits to it, see if we need additional whitespace trimming and generate edits for this that we could append to the formatter edits.

[lionel-]

I think the problem with the newlines inserted at the end of the document is that when a formatter needs to change lines below the original document, it sees the document ends two lines later, and might create an edit that modifies these lines, instead of inserting them from the end. Then we have invalid edits that might not be applied to the document correctly.

This confirms the intuition that we shouldn't modify the cell code before formatting.

[juliasilge]

Specifically, can you also check out and show what happens with a Python chunk and ruff? It also adds a final newline so very likely fine.

Here is some example code if you'd like:
https://docs.astral.sh/ruff/tutorial/#getting-started