Visuele modus herschrijft blokinhoud in een lijstitem, zonder terugval of waarschuwing #1925

New issue

Closed

opened 2026-09-02 15:59:01 +00:00 by brenno · 0 comments

brenno commented

2026-09-02 15:59:01 +00:00

Owner

Probleem

Blokinhoud die binnen een lijstitem staat, overleeft de rondgang door de
visuele modus niet. De inhoud wordt uit zijn inspringing gehaald en aan de
bulletregel geplakt; bij een codeblok verdwijnen de fence-regels zelfs
helemaal.

Dit is geen nieuw gedrag en niet iets wat #1920 introduceert — het gold al
voor codeblokken en tabellen. Het kwam boven bij een randproef op de nieuwe
mermaid-embed, en die proef liet zien dat mermaid het er nog het beste vanaf
brengt.

Gemeten

MarkdownQuillCodec.markdownFromDocument(documentFromMarkdown(bron)), drie
keer dezelfde vorm — een lijstitem, een witregel, een ingesprongen blok:

Codeblok in — het ergste geval, de fences zijn weg en de code staat in de
bulletregel:

- Stap een:

  ```dart
  void main() {}

Stap twee


uit:

Stap een:void main() {}
Stap twee


**Tabel in — het item verliest zijn bullet, de tabel krijgt er een:**

uit:

Stap een:

A B

1 2
Stap twee

A	B
1	2


**Mermaid in (met de embed uit #1920) — inhoud blijft heel, maar plakt aan de
bulletregel:**

uit:

Stap een:```mermaid
graph TD; A-->B;



- Stap twee

Waarom dit ertoe doet

De belofte van de visuele modus is dat hij een document niet stilzwijgend
herschrijft: wat de rijke-tekstlaag niet verliesvrij aankan, valt zichtbaar
terug op brontekst (markdownVisualLimitations). Hier gebeurt precies het
tegenovergestelde. De scanner slaat alles binnen een fence bewust over en kent
geen inspringing, dus er is geen terugval, geen waarschuwing, en de gebruiker
ziet pas na het opslaan dat zijn code uit elkaar is gevallen. Stil verlies is
erger dan een zichtbare beperking — dat is de afweging die bij #1565 ook al
gemaakt is.

Richting

Twee mogelijke uitkomsten, en de keuze is een productkeuze:

Zichtbaar terugvallen. De scanner leert ingesprongen blokinhoud
herkennen en geeft er een MarkdownVisualLimitation voor, zodat de editor
naar Bron wisselt in plaats van te herschrijven. Klein, eerlijk, en het
past bij hoe de andere beperkingen werken — maar het duwt documenten met
een codeblok in een lijst uit de visuele modus.
Werkelijk dragen. De codec houdt de inspringing vast, als attribuut op
de embed of door het blok als kind van het lijstitem te laten reizen. Dat
is het echte antwoord, en een stuk groter.

Optie 1 is de ondergrens: liever zichtbaar minder kunnen dan stil kapotmaken.

Reproductie

test/zz_edge_probe_test.dart uit de sessie van 2026-09-02 (niet
gecommit — de drie gevallen staan hierboven letterlijk). Een regressietest
hoort bij de fix; hij faalt vandaag op alle drie.

Referenties

lib/utils/markdown_quill_codec.dart — de heen- en terugweg
lib/utils/markdown_visual_compatibility.dart regel 72-77 — de fence-scanner
die inspringing niet kent
#1565 — dezelfde afweging voor de tabelcel
#1920 — waar dit bovenkwam

## Probleem Blokinhoud die binnen een lijstitem staat, overleeft de rondgang door de visuele modus niet. De inhoud wordt uit zijn inspringing gehaald en aan de bulletregel geplakt; bij een codeblok verdwijnen de fence-regels zelfs helemaal. Dit is **geen** nieuw gedrag en niet iets wat #1920 introduceert — het gold al voor codeblokken en tabellen. Het kwam boven bij een randproef op de nieuwe mermaid-embed, en die proef liet zien dat mermaid het er nog het beste vanaf brengt. ## Gemeten `MarkdownQuillCodec.markdownFromDocument(documentFromMarkdown(bron))`, drie keer dezelfde vorm — een lijstitem, een witregel, een ingesprongen blok: **Codeblok in — het ergste geval, de fences zijn weg en de code staat in de bulletregel:** ``` - Stap een: ```dart void main() {} ``` - Stap twee ``` uit: ``` - Stap een:void main() {} - Stap twee ``` **Tabel in — het item verliest zijn bullet, de tabel krijgt er een:** uit: ``` Stap een: - | A | B | | --- | --- | | 1 | 2 | - Stap twee ``` **Mermaid in (met de embed uit #1920) — inhoud blijft heel, maar plakt aan de bulletregel:** uit: ``` - Stap een:```mermaid graph TD; A-->B; ``` - Stap twee ``` ## Waarom dit ertoe doet De belofte van de visuele modus is dat hij een document niet stilzwijgend herschrijft: wat de rijke-tekstlaag niet verliesvrij aankan, valt zichtbaar terug op brontekst (`markdownVisualLimitations`). Hier gebeurt precies het tegenovergestelde. De scanner slaat alles binnen een fence bewust over en kent geen inspringing, dus er is geen terugval, geen waarschuwing, en de gebruiker ziet pas na het opslaan dat zijn code uit elkaar is gevallen. Stil verlies is erger dan een zichtbare beperking — dat is de afweging die bij #1565 ook al gemaakt is. ## Richting Twee mogelijke uitkomsten, en de keuze is een productkeuze: 1. **Zichtbaar terugvallen.** De scanner leert ingesprongen blokinhoud herkennen en geeft er een `MarkdownVisualLimitation` voor, zodat de editor naar Bron wisselt in plaats van te herschrijven. Klein, eerlijk, en het past bij hoe de andere beperkingen werken — maar het duwt documenten met een codeblok in een lijst uit de visuele modus. 2. **Werkelijk dragen.** De codec houdt de inspringing vast, als attribuut op de embed of door het blok als kind van het lijstitem te laten reizen. Dat is het echte antwoord, en een stuk groter. Optie 1 is de ondergrens: liever zichtbaar minder kunnen dan stil kapotmaken. ## Reproductie `test/zz_edge_probe_test.dart` uit de sessie van 2026-09-02 (niet gecommit — de drie gevallen staan hierboven letterlijk). Een regressietest hoort bij de fix; hij faalt vandaag op alle drie. ## Referenties - `lib/utils/markdown_quill_codec.dart` — de heen- en terugweg - `lib/utils/markdown_visual_compatibility.dart` regel 72-77 — de fence-scanner die inspringing niet kent - #1565 — dezelfde afweging voor de tabelcel - #1920 — waar dit bovenkwam

brenno added the

bug

label

2026-09-02 15:59:01 +00:00

brenno referenced this issue

2026-09-02 15:59:17 +00:00

Visuele editor toont mermaid-fence als codeblok (MermaidEmbedBuilder ontbreekt) #1920

brenno referenced this issue

2026-09-02 16:42:39 +00:00

fix(document): mermaid-fence als gerenderde kaart in de visuele editor (#1920) #1926

brenno referenced this issue

2026-09-02 23:10:00 +00:00