Toggling between source and visual editor alters spacing of fenced divs

[loganjohnson0]

Bug description

I have a large file with various panel sets in it. I understand the visual mode is not functioning the best. I prefer to work in source mode anyway, but I enjoy the spell checking that visual mode has. When switching between the two, there are a lot of alterations to my document that show up in the code diff that seem unnecessary related to the ::: fenced div options. I haven't noticed any issues with actual rendering, but the problems tab in Positron becomes annoying with many error messages.

Steps to reproduce

1. Create a new directory in Positron.
2. Optionally create a new Quarto project quarto create project default . new_directory. Can probably just create a new Quarto document instead.
3. To your new document, insert the following R code chunk while in Source mode:

::::: {.panel-tabset}

# Tab 1

```{r}

library(tidyverse)

```

# Tab 2

```{r}

library(tidymodels)

```

:::::

::: {.callout-important}

This should not be altered!

:::

4. Save and toggle to Visual mode. Notice that while nothing has changed, Positron asks you to save the file again.
5. Toggle back to Source mode and notice the changes to the ::: fenced div options.

Somewhere along the lines, the white space between the ::: fenced div and the next nearest item is removed. On the top, the space between the text and ::: is removed, the space between the end of the code chunk ``` and ::: is removed, and the space around the text in the callout note is removed. I have tried a callout note with two white spaces above and below the text, and it is all collapsed between toggling. Note: In saving with Air, I don't observe any modifications to these white space options.

Actual behavior

I don't observe any issues with the document rendering. That all happens as normal. The GitHub diff is annoying across a document, with many of these options. I guess I also prefer to have spaces around these and code chunks so that they are easier to modify and see in a document. There is a problems call in the second screenshot related to a syntax error, but again, the document renders without error regardless.

Start in Source

Next, Toggle to Visual

Return to Source

Expected behavior

I would expect the white spacing around these ::: fenced divs to remain unchanged when toggling between Source and Visual modes.

Your environment

Positron Version: 2025.07.0 build 204
Code - OSS Version: 1.100.3
Commit: 03ae7a5393c776bb24c23d2aa6a6bfbba90cbc5e
Date: 2025-06-30T16:29:03.492Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.5.0

quarto check
Quarto 1.7.31
[✓] Checking environment information...
      Quarto cache location: /Users/logan.johnson/Library/Caches/quarto
[✓] Checking versions of quarto binary dependencies...
      Pandoc version 3.6.3: OK
      Dart Sass version 1.85.1: OK
      Deno version 1.46.3: OK
      Typst version 0.13.0: OK
[✓] Checking versions of quarto dependencies......OK
[✓] Checking Quarto installation......OK
      Version: 1.7.31
      Path: /Applications/quarto/bin

[✓] Checking tools....................OK
      TinyTeX: v2025.05
      Chromium: (not installed)

[✓] Checking LaTeX....................OK
      Using: TinyTex
      Path: /Users/logan.johnson/Library/TinyTeX/bin/universal-darwin
      Version: 2025

[✓] Checking Chrome Headless....................OK
      Using: Chrome found on system
      Path: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
      Source: MacOS known location

[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
      Version: 3.9.18 (Conda)
      Path: /Users/logan.johnson/opt/anaconda3/bin/python
      Jupyter: 5.5.0
      Kernels: python3

[✓] Checking Jupyter engine render....OK

[✓] Checking R installation...........OK
      Version: 4.4.2
      Path: /Library/Frameworks/R.framework/Resources
      LibPaths:
        - /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/library
      knitr: 1.47
      rmarkdown: 2.27

[✓] Checking Knitr engine render......OK

[cscheid]

We could probably do a better job with spacing.

But, in general, we don't offer a promise of character-for-character preservation on a round-trip between source and visual editors. We definitely don't want to lose structure or content, but we don't consider whitespace differences to be bugs unless these differences themselves cause downstream issues (that wouldn't themselves be bugs).

[cscheid]

Note: In saving with Air, I don't observe any modifications to these white space options.

Air handles r formatting; it doesn't handle formatting of the markdown in .qmd documents.

[cscheid]

It'd be good to understand the ultimate cause of that syntax error, but I don't believe that to be an issue with the visual editor itself.

Expanding further, Pandoc's markdown parser produces the same output for both versions of the .qmd.

Before the roundtripping:

$ pandoc -t native
::::: {.panel-tabset}

# Tab 1

```asdf

library(tidyverse)

```

# Tab 2

```asdf

library(tidymodels)

```

:::::

::: {.callout-important}

This should not be altered!

:::
^D
[ Div
    ( "" , [ "panel-tabset" ] , [] )
    [ Header
        1 ( "tab-1" , [] , [] ) [ Str "Tab" , Space , Str "1" ]
    , CodeBlock
        ( "" , [ "asdf" ] , [] ) "\nlibrary(tidyverse)\n"
    , Header
        1 ( "tab-2" , [] , [] ) [ Str "Tab" , Space , Str "2" ]
    , CodeBlock
        ( "" , [ "asdf" ] , [] ) "\nlibrary(tidymodels)\n"
    ]
, Div
    ( "" , [ "callout-important" ] , [] )
    [ Para
        [ Str "This"
        , Space
        , Str "should"
        , Space
        , Str "not"
        , Space
        , Str "be"
        , Space
        , Str "altered!"
        ]
    ]
]

After the roundtripping:

$ pandoc -t native
::: panel-tabset
# Tab 1

```asdf

library(tidyverse)

```

# Tab 2

```asdf

library(tidymodels)

```
:::

::: callout-important
This should not be altered!
:::
^D
[ Div
    ( "" , [ "panel-tabset" ] , [] )
    [ Header
        1 ( "tab-1" , [] , [] ) [ Str "Tab" , Space , Str "1" ]
    , CodeBlock
        ( "" , [ "asdf" ] , [] ) "\nlibrary(tidyverse)\n"
    , Header
        1 ( "tab-2" , [] , [] ) [ Str "Tab" , Space , Str "2" ]
    , CodeBlock
        ( "" , [ "asdf" ] , [] ) "\nlibrary(tidymodels)\n"
    ]
, Div
    ( "" , [ "callout-important" ] , [] )
    [ Para
        [ Str "This"
        , Space
        , Str "should"
        , Space
        , Str "not"
        , Space
        , Str "be"
        , Space
        , Str "altered!"
        ]
    ]
]

(I'm using asdf instead of {r} on purpose, for reasons unimportant here) The important point is that the resulting AST from Pandoc is identical. In these situations, we will not consider such differences to be bugs in round-tripping process.

I understand that taste differences in formatting Markdown documents run strong. Unfortunately, there's no agreed-upon Markdown formatter (or tooling for formatting Markdown documents to begin with), and we do not believe it's practical for the visual editor to attempt to preserve these differences robustly.

[loganjohnson0]

I don't have a strong preference either way. I understand there are many nuances here. I think I would be fine if these changes were made in the transition as long as the ::: fenced divs are more distinguished from the code cell itself. Notice the highlighting of the ::: fenced div in Line 25 of the second screenshot. This makes it much more difficult going through a larger document trying to edit these positions.

The syntax error is maybe Positron related. I'm not sure if that is the case, though. The problem statement says "no symbol named `` in scope." When I click on the problem statement and open that .vdoc file, Positron highlights the first 2 backticks but doesn't recognize the third backtick in that series.

```
#
#
#
#
#
#
#

Maybe related? These also seem to discuss the code cell highlighting in a similar manner, and the file in source mode -> visual mode, making the file appear as edited.
#447
#582

Also, thanks for the great work with Quarto! I've thoroughly enjoyed how flexible and easy it is to use for my work.

[cscheid]

I think I would be fine if these changes were made in the transition as long as the ::: fenced divs are more distinguished from the code cell itself. Notice the highlighting of the ::: fenced div in Line 25 of the second screenshot. This makes it much more difficult going through a larger document trying to edit these positions.

We're talking in circles around each other a bit, but I think I see where some of the confusion here is coming from.

We can either characterize this issue as a future enhancement for the visual editor, or as a bug (either in the quarto extension or in positron itself). I was responding based on the visual-editor tag; your comment about highlighting is responding to something that doesn't come from the visual editor (and I believe is a duplicate of #447) #582 is unrelated to either - it's about what the behavior should be when the source .qmd file is not "canonical" (ie, it would be saved by the visual editor with different formatting)