Formaat: een nieuw dia-directief overleeft geen opslag — weggegooid, of het wordt een notitie #1810

New issue

Closed

opened 2026-08-27 13:24:28 +00:00 by brenno · 0 comments

brenno commented

2026-08-27 13:24:28 +00:00

Owner

Wat er misgaat

Een nieuw ocideck_*-commentaar in een diablok overleeft geen enkele opslag.
Gemeten op main, parse → generateSlide, met
 op vier plaatsen:

plaats	uitkomst
in `split-text`, getypeerde `bulletsImage`	weggegooid
bovenaan het blok	weggegooid
bovenaan een gewone bullets-dia	weggegooid
onderaan een gewone bullets-dia	wordt een presentatienotitie (`_isTailNote`)

Er is dus geen plaats waar hij heel blijft: drie keer stil verlies, één keer
stille verandering van betekenis — de waarde landt in de notities van de
gebruiker, waar hij niet hoort en waar hij bij de volgende opslag als notitie
wordt teruggeschreven.

Waarom dit nu een issue is en niet "gewoon hoe het werkt"

Het formaatcontract (FILE_FORMAT.md §3.0) belooft dit voor de front matter:
sleutels die OciDeck niet kent blijven exact staan. Voor per-dia-directieven
bestaat die belofte niet, en het gevolg is dat élk toekomstig dia-directief bij
een oudere lezer verdwijnt. Dat is niet hypothetisch: het is precies de reden dat
het callout-ontwerp (#1801) zijn gegevens níet in een dia-commentaar kan zetten
en moest uitwijken naar de front matter.

Zolang dit blijft staan, is "een nieuw dia-directief" geen begaanbare weg — niet
voor callouts, en niet voor wat er daarna komt.

Twee gaten, en ze verdienen allebei een reparatie

De notitie-val. _isTailNote in
lib/services/markdown_parse/markdown_service_parse_directives.dart maakt van
elk onbekend commentaar aan het eind van een blok een presentatienotitie. Een
commentaar dat met ocideck_ begint is per definitie een directief en hoort
dat nooit te worden. Dit is klein en op zichzelf al winst: het voorkomt dat
gegevens in andermans notities landen.
De doorgeeflus. Voor de andere drie plaatsen moet er een bewaarroute zijn:
een onbekend ocideck_*-directief wordt bij het lezen apart gezet en bij het
schrijven onveranderd teruggezet, zoals preservedMarpLines dat al doet voor
Marp-syntaxis die OciDeck niet modelleert. Dat is het echte werk, en het is
wat "een oud bestand blijft leesbaar én bij te werken" ook de andere kant op
waar maakt.

Toetsen

Een regressietest die een onbekend directief op alle vier de plaatsen door een
parse-en-opslag haalt en eist dat het er byte-voor-byte nog staat. Die test
faalt vandaag vier keer.

Herkomst

Gemeten tijdens het formaatontwerp voor #1801, met wegwerpprobes tegen main.
git diff v0.4.9..HEAD over het parse/serialiseer-pad is leeg, dus dit geldt
onverkort voor de uitgebrachte lezer.

**Wat er misgaat** Een nieuw `ocideck_*`-commentaar in een diablok overleeft geen enkele opslag. Gemeten op `main`, parse → `generateSlide`, met `` op vier plaatsen: | plaats | uitkomst | | --- | --- | | in `split-text`, getypeerde `bulletsImage` | **weggegooid** | | bovenaan het blok | **weggegooid** | | bovenaan een gewone bullets-dia | **weggegooid** | | onderaan een gewone bullets-dia | **wordt een presentatienotitie** (`_isTailNote`) | Er is dus geen plaats waar hij heel blijft: drie keer stil verlies, één keer stille verandering van betekenis — de waarde landt in de notities van de gebruiker, waar hij niet hoort en waar hij bij de volgende opslag als notitie wordt teruggeschreven. **Waarom dit nu een issue is en niet "gewoon hoe het werkt"** Het formaatcontract (`FILE_FORMAT.md` §3.0) belooft dit voor de **front matter**: sleutels die OciDeck niet kent blijven exact staan. Voor per-dia-directieven bestaat die belofte niet, en het gevolg is dat élk toekomstig dia-directief bij een oudere lezer verdwijnt. Dat is niet hypothetisch: het is precies de reden dat het callout-ontwerp (#1801) zijn gegevens níet in een dia-commentaar kan zetten en moest uitwijken naar de front matter. Zolang dit blijft staan, is "een nieuw dia-directief" geen begaanbare weg — niet voor callouts, en niet voor wat er daarna komt. **Twee gaten, en ze verdienen allebei een reparatie** 1. **De notitie-val.** `_isTailNote` in `lib/services/markdown_parse/markdown_service_parse_directives.dart` maakt van elk onbekend commentaar aan het eind van een blok een presentatienotitie. Een commentaar dat met `ocideck_` begint is per definitie een directief en hoort dat nooit te worden. Dit is klein en op zichzelf al winst: het voorkomt dat gegevens in andermans notities landen. 2. **De doorgeeflus.** Voor de andere drie plaatsen moet er een bewaarroute zijn: een onbekend `ocideck_*`-directief wordt bij het lezen apart gezet en bij het schrijven onveranderd teruggezet, zoals `preservedMarpLines` dat al doet voor Marp-syntaxis die OciDeck niet modelleert. Dat is het echte werk, en het is wat "een oud bestand blijft leesbaar én bij te werken" ook de andere kant op waar maakt. **Toetsen** Een regressietest die een onbekend directief op alle vier de plaatsen door een parse-en-opslag haalt en eist dat het er byte-voor-byte nog staat. Die test faalt vandaag vier keer. **Herkomst** Gemeten tijdens het formaatontwerp voor #1801, met wegwerpprobes tegen `main`. `git diff v0.4.9..HEAD` over het parse/serialiseer-pad is leeg, dus dit geldt onverkort voor de uitgebrachte lezer.

brenno added the

bug

label

2026-08-27 13:24:28 +00:00

brenno referenced this issue

2026-08-27 16:41:29 +00:00

Formaat: een spreeknotitie die met "Woord:" begint laat de dia stil haar type verliezen #1815

brenno referenced this issue

2026-08-27 16:41:35 +00:00

Formaat: een spreeknotitie die met "Woord:" begint laat de dia stil haar type verliezen #1815

brenno referenced this issue from a commit

2026-08-27 17:13:37 +00:00