posit-dev / posit-dev/air

Double check if `fn( # comment` has to move `# comment` to its own line

Open
#392 6 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
446
Forks
32
Avg merge
16h 48m
Merged PRs (30d)
1

Description

Formatting code on save in a .qmd file in vscode is messing up my nicely formatted quarto markup for an annotated code block

For example, with the following file:

---
title: test
---

```{r}
runif(1)                          # <1>

data.frame(                       # <2>
  a = runif(1),
  b = runif(2)                    # <3>
)
```

1. alice
2. bob
3. charlie

formatting on save is producing this:

---
title: test
---

```{r}
runif(1)                          # <1>

data.frame( # <2>
  a = runif(1),
  b = runif(2)                    # <3>
)
```

1. alice
2. bob
3. charlie

I expect it not to mess with the indentation on # <2>

This is with Quarto 1.7.32, air 0.14.0, and my air.toml

[format]
line-width = 80
indent-width = 2
indent-style = "space"
line-ending = "auto"
persistent-line-breaks = true
exclude = []
default-exclude = true
skip = []

Editor: vscodium

Version: 1.102.24914
Commit: 9e6954323e23e2f62c1ea78348dbd1b53e5b827e
Date: 2025-07-23T18:25:03.797Z
Electron: 35.6.0
ElectronBuildId: undefined
Chromium: 134.0.6998.205
Node.js: 22.15.1
V8: 13.4.114.21-electron.0
OS: Darwin arm64 24.5.0

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the formatting-on-save case in a .qmd file using the supplied air.toml, and compare the annotated data.frame() comment before and after formatting. Done means the # <2> comment retains its original indentation while the surrounding formatting remains valid; no source file or test is named in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
r, rust
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.