From c82f132553e7004240ee1573a921112bea8602de Mon Sep 17 00:00:00 2001 From: John McLear Date: Sun, 17 May 2026 13:02:02 +0100 Subject: [PATCH] fix(ExportHtml): don't poison ol counter when closing a sibling ul When an ordered-list level was the only consumer of olItemCounts, closing any list at that depth (including an unordered list that happens to share the level) reset olItemCounts[level] to 0. A later, unrelated ordered list at the same depth then took the "counter exists but is 0" branch in the ol-opening logic and emitted `
    ` without the start attribute that line.start would have supplied. Round-trip: importing
    1. x
      1. y
    exported the inner ol as `
      ` instead of `
        `, because the closing of the inner bullet ul wrote olItemCounts[2]=0 before the outer ol even opened. Gate the reset on line.listTypeName === 'number' so closing an unordered list never touches the ol bookkeeping. Closing an actual ordered list still resets, as #7470 intended. Fixes #7786 Fixes #7787 Co-Authored-By: Claude Opus 4.7 (1M context) --- src/node/utils/ExportHtml.ts | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/node/utils/ExportHtml.ts b/src/node/utils/ExportHtml.ts index fd83416546e..4871629f0f1 100644 --- a/src/node/utils/ExportHtml.ts +++ b/src/node/utils/ExportHtml.ts @@ -470,7 +470,10 @@ const getHTMLFromAtext = async (pad:PadType, atext: AText, authorColors?: string // preserve counters so numbering can continue after interruptions. // Use 0 as sentinel (not delete) so the ol-opening logic knows this // level was explicitly reset and won't fall back to line.start. - if (diff + 1 > actualNextLevel) { + // Only reset when closing an ordered list — closing an unordered list + // at the same level must not poison the ol counter for a future + // unrelated ol at this level (which would still want line.start). + if (line.listTypeName === 'number' && diff + 1 > actualNextLevel) { olItemCounts[diff + 1] = 0; }