read: two lists side by side come back as one list
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 72/100
Direzione di ricerca
Begin with the read and export entry points and the table property test referenced in #55; trace how adjacent ordered and unordered lists are rendered and read back. Confirm the fix preserves separate lists across top-level blocks, layout cells, macro bodies, and raw table cells, and that the property test's round trip no longer merges them.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
read and export write two adjacent lists of the same kind with a blank line between them, and Markdown reads that as one loose list, so the next publish merges them. Found by the table property test in #55.
Reproduced 2026-09-25 (read → publish):
| storage | read writes | publish sends |
|---|---|---|
<ol><li>a</li></ol><ol><li>b</li></ol> |
1. a blank line 1. b |
one <ol> with two items, each wrapped in <p> (a loose list) |
<ul><li>a</li></ul><ul><li>b</li></ul> |
- a blank line - b |
one <ul> with two items, each wrapped in <p> |
Two lists become one, and the items gain paragraph spacing. It happens anywhere read writes blocks: the top level, layout cells, macro bodies and raw table cells. The table property test's generator avoids writing adjacent lists so that it does not fail on this.
Notes
- CommonMark ends a list when the bullet character changes (
-then*) or the ordered delimiter changes (.then)), and an HTML comment between the two (<!-- -->) also separates them. Changing the marker is the least noisy fix, but it has to survive the next read, so the Markdown stays a fixed point.
- Lingua principale
- Go
- Stelle
- 2
- Fork
- 0
- Merge medio
- 2h 29m
- PR unite (30g)
- 60
Preparare l'ambiente
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di mozilla/markfluence
-
enhancement
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
mozilla/markfluence#210 ·
I maintainer di solito rispondono entro 1 giorno
-
Move plans out of the repository so a stale plan cannot be mistaken for how markfluence worksApertadocumentation
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
mozilla/markfluence#209 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 76/100
mozilla/markfluence#204 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 74/100
mozilla/markfluence#203 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
mozilla/markfluence#181 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di mozilla/markfluence
Issue simili
-
bug needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
netdata/netdata#24062 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
meshery/meshery#22119 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
automation documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno