Phase 23: pinned reparse windows; serialize without a whole-output parse (v0.1.20)

[lr00rl]

What was wrong

reparseBlocks / reparseFromText reparsed a window around an edit and then appended the old blocks after it, shifted, without checking that the edit had not run into them. An edit that opens a code fence, a display-math block or an HTML comment and does not close it was read as one short block followed by the old suffix. A whole parse runs it to the end of the text.

prior:  a / b / c / d / e      (paragraphs)
edit:   insert "```\n" before b
before: [paragraph a] [fenced-code b..c] [paragraph d] [paragraph e]
whole:  [paragraph a] [fenced-code b..e]

Noto calls this from replaceMarkdown: leaving Source Mode, taking an external change on reload, and plugin transforms.

The fix: pin both edges of the window (src/window.ts)

The scanner decides where a top-level block starts from that block's first line and everything above it. So a window can stand in for the whole parse when:

• Left. It opens at offset 0, or at the start of an untouched block whose first line, and everything before it, read as they did before. That block is re-read, so a line that now continues it (lazy continuation) is picked up.
• Right. It closes at the end of the text, or with an anchor: the untouched block after the dirty ordinals, which must come out exactly as it was (kind and offsets). If it does not, the edit ran into it, and the reparse reads on to the end.

Frontmatter is the one block decided by unbounded lookahead: --- on line 1 is frontmatter if a close comes anywhere later, and a thematic break otherwise. A window that opens the note with one and stops short of its close is refused.

neighborSlack now only trades window size against how often the fallback is needed. It no longer decides whether the result is correct.

Serialize without a whole-output parse

serializeDocument used to parse its entire output again to build the next document. It now records where each unit landed and builds the document from the blocks it moved. It reparses, with the same pinned windows, only around changed units, around seams where blocks were deleted (two lists can merge), and at the ends of the note when those change. If any window does not hold, it falls back to the whole parse, as before. Line-ending detection now uses two native scans instead of a character loop.

On an 8 MB note (43,970 blocks), one edited paragraph:

	before	after
serializeDocument	130-203 ms	41-77 ms

Tests

• reparse-window.test.ts covers:

  • unclosed fence, math, comment and <script> at slack 0/1/2;
  • a closing fence that ends a fence which used to run to the end;
  • lazy continuation into the block before the window;
  • identity of untouched spans;
  • 600 generated edits per slack compared field by field with parseBlocks.

  Five of the seven tests fail on main.

• serialize-incremental.test.ts runs 500 generated saves each over LF, CRLF, BOM, no final newline and no frontmatter. Every document is compared with parseDocument(outputBytes) (envelope, text, leading, gaps, trailing, every block). It also covers the unclosed fence, list merge, first and last block deleted, final newline changed, and frontmatter inserted.

• A local stress run (6,000 × 5 saves, 8,000 × 2 edits) passes.

• pnpm verify passes: 132 tests.

• Noto's unit suite passes against this build (2,116 tests), including its own equivalence test for the save path.

Version 0.1.20; CHANGELOG, README, contract and roadmap are updated.

🤖 Generated with Claude Code

https://claude.ai/code/session_011Zsubk1jzejiCfkbLeWVQd

---

Generated by Claude Code