LibreKAT/Ocideck

Watch

Fork 1

Opsommingseditor knipt het derde niveau van een lijst met 4 spaties inspringing af #1558

New issue

Closed

opened 2026-08-18 19:53:25 +00:00 by brenno · 1 comment

brenno commented

2026-08-18 19:53:25 +00:00

Owner

Wat er misgaat

De parser rekent 2 spaties per niveau
(lib/services/markdown_parse/markdown_service_parse_body.dart:195-206), maar
Markdown schrijf en plak je doorgaans met 4 spaties. Een lijst van drie
zichtbare niveaus landt daardoor intern op niveau 0, 2 en 4 — en vier niveaus op
0, 2, 4 en 6.

De visuele opsommingseditor kent een plafond van 4:

lib/widgets/editors/bullets_editor.dart:65 — static const _maxLevel = 4;
:150 — _levelOf stopt met tellen bij _maxLevel
:192 — _emit schrijft het geklemde niveau terug

Gevolg: open zo'n dia in de visuele editor en raak er iets aan, dan zakt het
vierde zichtbare niveau naar het derde. Dat is niet terug te draaien met
ongedaan maken in het bronvenster, want de dia is dan al herschreven.

Wat wél goed gaat

De rondrit door de bron zelf is tekenstabiel — gemeten:

- Primary bullet level.
    - Secondary bullet level.
        - A third bullet level.
            - A fourth bullet level.

parseren geeft niveaus [0, 2, 4, 6] en serialiseren zet er weer 0/4/8/12
spaties neer. Het verlies zit uitsluitend in de visuele editor.

Wat het zou moeten doen

Twee dingen om te wegen, niet allebei tegelijk:

Het plafond uitdrukken in zichtbare niveaus in plaats van in tabs, zodat
_maxLevel meebeweegt met de 2-spaties-conventie. Dan haalt een lijst van
vier zichtbare niveaus het wél.
Of, als 4 tabs het echte ontwerpplafond is: niet stil afknippen. Wie een
dieper genest niveau opent, hoort dat te zien — en het niveau hoort te
blijven staan zolang hij er niet aan komt.

Voorkeur gaat uit naar 2 met behoud: _emit mag geen niveau terugschrijven dat
de gebruiker niet zelf heeft gezet.

Waar het vandaan komt

Gevonden bij het toetsen van #1556. Van alles wat ik daar tegenkwam lijkt dit
het meest op "de inspringing is verdwenen", al is het niet het geplakte pad dat
de indiener beschrijft.

Bestandsformaat

Raakt het formaat niet — tabs blijven de opslagvorm voor niveaus. Wel raakt het
de inhoud van een bestaand deck, want het schrijft dia's stil om.

Regressietest

Een dia met vier zichtbare niveaus door de opsommingseditor halen, één los veld
bewerken, en bewijzen dat de niveaus van de andere regels onveranderd zijn.

**Wat er misgaat** De parser rekent **2 spaties per niveau** (`lib/services/markdown_parse/markdown_service_parse_body.dart:195-206`), maar Markdown schrijf en plak je doorgaans met **4 spaties**. Een lijst van drie zichtbare niveaus landt daardoor intern op niveau 0, 2 en 4 — en vier niveaus op 0, 2, 4 en 6. De visuele opsommingseditor kent een plafond van 4: - `lib/widgets/editors/bullets_editor.dart:65` — `static const _maxLevel = 4;` - `:150` — `_levelOf` stopt met tellen bij `_maxLevel` - `:192` — `_emit` schrijft het *geklemde* niveau terug Gevolg: open zo'n dia in de visuele editor en raak er iets aan, dan zakt het vierde zichtbare niveau naar het derde. Dat is niet terug te draaien met ongedaan maken in het bronvenster, want de dia is dan al herschreven. **Wat wél goed gaat** De rondrit door de bron zelf is tekenstabiel — gemeten: ``` - Primary bullet level. - Secondary bullet level. - A third bullet level. - A fourth bullet level. ``` parseren geeft niveaus `[0, 2, 4, 6]` en serialiseren zet er weer 0/4/8/12 spaties neer. Het verlies zit uitsluitend in de visuele editor. **Wat het zou moeten doen** Twee dingen om te wegen, niet allebei tegelijk: 1. Het plafond uitdrukken in *zichtbare* niveaus in plaats van in tabs, zodat `_maxLevel` meebeweegt met de 2-spaties-conventie. Dan haalt een lijst van vier zichtbare niveaus het wél. 2. Of, als 4 tabs het echte ontwerpplafond is: niet stil afknippen. Wie een dieper genest niveau opent, hoort dat te zien — en het niveau hoort te blijven staan zolang hij er niet aan komt. Voorkeur gaat uit naar 2 met behoud: `_emit` mag geen niveau terugschrijven dat de gebruiker niet zelf heeft gezet. **Waar het vandaan komt** Gevonden bij het toetsen van #1556. Van alles wat ik daar tegenkwam lijkt dit het meest op "de inspringing is verdwenen", al is het niet het geplakte pad dat de indiener beschrijft. **Bestandsformaat** Raakt het formaat niet — tabs blijven de opslagvorm voor niveaus. Wel raakt het de *inhoud* van een bestaand deck, want het schrijft dia's stil om. **Regressietest** Een dia met vier zichtbare niveaus door de opsommingseditor halen, één los veld bewerken, en bewijzen dat de niveaus van de andere regels onveranderd zijn.

brenno added the

bug

label

2026-08-18 19:53:25 +00:00

brenno referenced this issue

2026-08-18 19:54:59 +00:00

[Bug] Indented bullet lists lose indents when pasting into the source editor #1556

brenno referenced this issue

2026-08-18 20:27:17 +00:00

fix(plakken): een geplakte opsomming houdt zijn inspringing #1562

brenno added the

accepted

in-progress

labels

2026-08-18 20:47:04 +00:00

brenno referenced this issue from a pull request that will close it,

2026-08-18 21:00:29 +00:00

fix(editor): een dieper inspringniveau wordt niet meer stil afgeknipt #1563

brenno referenced this issue from a commit

2026-08-18 21:00:31 +00:00

fix(editor): een dieper inspringniveau wordt niet meer stil afgeknipt

brenno

2026-08-18 21:05:15 +00:00

closed this issue
removed the
in-progress
label

brenno commented

2026-08-18 21:05:41 +00:00

Author

Owner

Opgelost op main in ff60cd3b (PR #1563), route A: het klemmen zit alleen nog op de knop.

_levelOf is uit beide opsommingseditors verdwenen; ze lezen nu met dezelfde bulletLevel als de rest van de codebase, ongeklemd. Wat je niet zelf hebt gewijzigd, wordt niet meer teruggeschreven.
Het knopmaximum staat als één gedeelde kMaxIndentButtonLevel naast bulletLevel, met de aantekening dat het formaat, de parser, de dia-render en de HTML-export zélf geen maximum kennen.
De boomeditor hield 6 aan waar de andere twee 4 deden; die loopt nu mee. Daar zat bovendien een eigen fout: _indent klemde met clamp(0, _maxLevel), waardoor uitspringen vanaf niveau 6 met één klik naar 4 sprong in plaats van naar 5.

Twee regressietests, elk gevallen tegen de onherstelde code.

Wat hier bewust níet in zit: de dubbeltelling zelf. De parser rekent twee spaties per niveau terwijl markdown doorgaans met vier wordt geschreven; dat is de reden dat niveau 6 überhaupt ontstaat. Dat omzetten zou elk bestaand deck met twee-spaties-inspringing zijn niveaus kosten — een formaatwijziging vermomd als een constante. Hoort bij een versieveld en een migratiepad, niet hierbij. Vastgelegd in het commentaar bij de constante.

Ook open gebleven: hoe diep de knop mag komen. Vier zichtbare niveaus zou acht tabs vragen; dat is een aparte afweging die los te maken is nu het stille afknippen weg is.

Opgelost op main in ff60cd3b (PR #1563), route A: het klemmen zit alleen nog op de knop. - `_levelOf` is uit beide opsommingseditors verdwenen; ze lezen nu met dezelfde `bulletLevel` als de rest van de codebase, ongeklemd. Wat je niet zelf hebt gewijzigd, wordt niet meer teruggeschreven. - Het knopmaximum staat als één gedeelde `kMaxIndentButtonLevel` naast `bulletLevel`, met de aantekening dat het formaat, de parser, de dia-render en de HTML-export zélf geen maximum kennen. - De boomeditor hield 6 aan waar de andere twee 4 deden; die loopt nu mee. Daar zat bovendien een eigen fout: `_indent` klemde met `clamp(0, _maxLevel)`, waardoor uitspringen vanaf niveau 6 met één klik naar 4 sprong in plaats van naar 5. Twee regressietests, elk gevallen tegen de onherstelde code. Wat hier bewust níet in zit: de dubbeltelling zelf. De parser rekent twee spaties per niveau terwijl markdown doorgaans met vier wordt geschreven; dat is de reden dat niveau 6 überhaupt ontstaat. Dat omzetten zou elk bestaand deck met twee-spaties-inspringing zijn niveaus kosten — een formaatwijziging vermomd als een constante. Hoort bij een versieveld en een migratiepad, niet hierbij. Vastgelegd in het commentaar bij de constante. Ook open gebleven: hoe diep de knop mag komen. Vier zichtbare niveaus zou acht tabs vragen; dat is een aparte afweging die los te maken is nu het stille afknippen weg is.

brenno referenced this issue

2026-08-20 16:00:40 +00:00

Documentmodus: opslaan vanuit de visuele stand herschrijft de hele bron #1613