Incorrect comments for YAML multiline strings

[arcruz0]

Bug description

Hello, and apologies if this should be reported elsewhere.

When commenting out a .qmd line that's part of a YAML multiline string, I get # in Positron (which leads to an error when rendering). In RStudio, I get <!-- (which renders fine).

Many thanks in advance!

Steps to reproduce

Open the following .qmd in Positron, and then do "Add line comment" on either \setlength... or \usepackage....

---
title: "Hello"
format: 
  pdf:
    include-in-header: 
      text: |
        \setlength\parindent{.2in}
        \usepackage{indentfirst}
---

## Hello

Hello

Hello

The line gets prefixed by #. Finally, render and get and error:

ERROR: compilation failed- error You can't use `macro parameter character #' in vertical mode.

Expected behavior

In RStudio, the lines get commented out in HTML style, e.g.: <!-- \usepackage{indentfirst} -->. This renders without errors.

Your environment

Positron Version: 2026.08.1 build 2
Code - OSS Version: 1.124.0
Commit: 48dc4cee686939f35fe4a714d34375f67fd62082
Date: 2026-08-09T13:35:16-06:00
Electron: 42.2.0
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Linux x64 7.1.8-200.fc44.x86_64

[cscheid]

Thanks for the report. I can see why you'd want this to work better. I have bad news, though: this is going to be an extremely hard thing to solve in general. The way in which that YAML multiline string becomes a comment is dependent on a lot of factors what are plainly invisible for the IDE (positron, rstudio, what have you). The fact that one of them works in one setting isn't predictive of whether it will work in other settings: it's really (bad) luck. In other words:

In RStudio, the lines get commented out in HTML style, e.g.: . This renders without errors.

This renders without errors, but I think that's really just a coincidence. We can't make everything become comments in HTML format because that will break some other settings.

@juliasilge, I'd be comfortable with closing this now with "we are sorry, we know that doesn't work well, but we won't fix because that is really not a possible thing to do in 2026" if you're ok with that.

[arcruz0]

Thanks for the explanation, @cscheid. That's okay; this is probably an obscure enough use case...