Documenttijdlijnen en robuust sorteren van tabellen #1571
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!1571
Loading…
Reference in a new issue
No description provided.
Delete branch "codex/document-timeline"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Wat verandert er
<!-- timeline -->-marker.Bewijs
make checkgroen op de actuelemain: 9.822 tests, 87,0% totale dekking, geen bestand onder de 34%-vloer.make check-secretsgroen.make sastgroen.<br>, stabiele sortering en annuleren.Formaatkeuze
De tijdlijn is geen nieuw documenttype en geen JSON-blok. Verwijder de marker en exact dezelfde tabel blijft over; andere Markdownlezers tonen gewoon de tabel.
Meegelezen vanuit #1568, waar de documentkant van FILE_FORMAT is gelijkgetrokken met de code. Drie dingen, waarvan het eerste nu nog goedkoop mee kan.
1.
FILE_FORMAT.nl.mdmist §14.11. De PR raakt vier docs-bestanden en de Nederlandse variant zit er niet bij. Dat is de versie die in de app wordt getoond, entranslate-docs-checkmerkt het niet: die poort toetst of een variant bestaat en geregistreerd is, niet of hij bij is. Zo kon §14.9 (voetnoten) er helemaal uit blijven terwijl alles groen stond. Zeg het maar als ik de Nederlandse sectie erbij zet — hier, of als opvolg-PR direct na het mergen.2. §14.11 zegt niet wat elke uitvoer met de marker doet, terwijl de code dat wél regelt (een eigen blok in de LaTeX-uitvoer, kaarten in de HTML-uitvoer). §14.9 en §14.10 sluiten allebei af met dat rijtje per oppervlak, juist omdat dat is wat een lezer van het bestandsformaat wil weten: wat gebeurt er met mijn bytes als ik exporteer. Eén alinea volstaat.
3. Herkenning is iets ruimer dan de tekst zegt.
TimelineTableSyntaxmatcht^\s*<!-- timeline -->\s*$, dus een ingesprongen marker telt ook mee. De tekst zegt "this exact marker", en dat leest strenger dan de code is. Dezelfde nuance staat sinds #1568 bij<!-- toc -->in §14.10.Verder: de vorm klopt wat mij betreft. Een gewone GFM-tabel met een commentaar erboven, alleen de marker weghalen als volledige omkering, en een vreemde lezer die simpelweg de tabel toont — dat is precies wat §14.1 belooft en niet wat een eigen dialect ervan zou maken.