Fix O(2^n) regex backtracking in consolidateBlockDiffs that freezes the extension host

[wolframarnold]

Fixes #74.

Problem

consolidateBlockDiffs() in src/markdown/structuralDiff.ts builds a regex with a
(BLOCK(?:\s*BLOCK)*) shape that backtracks exponentially (O(2ⁿ) in the number
of block elements) when an <ins>/<del> region wraps a long run of sibling
block-level elements. On a real document edit this pegs one CPU core at 100% and
never returns, freezing the single-threaded VS Code extension host — and with it
every extension in that window. Full analysis, repro, and measurements are in #74.

Root cause

const blockElementPattern =
  `(?:<(?:${blockTags})[^>]*>[\\s\\S]*?<\\/(?:${blockTags})>|<(?:${selfClosingTags})[^>]*\\/?>)`;
const fullWrapRegex = new RegExp(
  `(<(ins|del)[^>]*>)\\s*(${blockElementPattern}(?:\\s*${blockElementPattern})*)\\s*(<\\/\\2>)`,
  "gi",
);

blockElementPattern is ambiguous — a lazy [\s\S]*? that closes on any block
tag — so a run of n blocks has ~2ⁿ partitions. Repeating it with
(?:\s*BLOCK)* and then requiring a trailing </\2> that usually doesn't align
makes the engine try them all. A synthetic 343-byte input already takes ~4 s
(runtime doubles per added block); ~40 blocks is effectively forever.

Fix

Match the region with a lazy inner (linear), then validate that the content is a
block run with a linear left-to-right scan (isBlockLevelRun). This removes the
nested repetition and the exponential blow-up while preserving behavior.

Verification

• Isolated regex on the real captured 224 KB input: hang → 1 ms.
• Full computeDiff() on the reproducing 129 KB document: hang → ~290 ms, valid
  diff HTML produced.
• Spot checks: an <ins> wrapping a <table> + <h2> run is still marked
  diff-block; an <ins> around inline text is still left untouched.

Notes for review

• The lazy inner matches to the first </ins>/</del>. This runs after
  balanceDiffTags, and the original \2 backreference had the same first-close
  behavior, so pairing should be equivalent — worth a test if diff tags can nest.
• I could not run the repo's own suite in my environment (dev deps + the VS Code
  test harness weren't installed). Please run npm test; a regression fixture
  asserting consolidateBlockDiffs completes for, say, N=40 blocks would lock this
  in.
• Considered an atomic group / possessive quantifier ((?>…) / *+) instead —
  V8 rejects both even on Node 24 (throws at construction), so that path would break
  the extension. The lazy-plus-validate form is portable.

🤖 Generated with Claude Code

[phine-apps]

Hi @wolframarnold,

Thank you so much for another great PR and the thorough repro in #74! Eliminating the $O(2^n)$ backtracking is a huge win.

During review, I spotted one edge case with nested block elements (e.g. <blockquote><ul><li>...</li></ul></blockquote> or nested lists):
Because blockElementPattern uses a lazy close tag ([\s\S]*?<\/(?:blockTags)>), one.exec stops at the first inner close tag (e.g. </ul>), leaving the outer close tag unmatched and causing isBlockLevelRun to return false (missing diff-block).

Tracking tag depth (similar to findClosing in domUtils.ts) resolves this cleanly in $O(N)$ without backtracking.

How would you like to proceed?

• Option A: You update the PR with depth tracking.
• Option B: I push the follow-up commit & tests directly to your branch and merge.

Let me know your preference. Thanks again for tackling this!

[wolframarnold]

Thanks @phine-apps — good catch, that's exactly right. Went with Option A: isBlockLevelRun now consumes each paired block via findClosing (depth tracking) rather than the lazy-close pattern, so nested blocks like <blockquote><ul>...</ul></blockquote> are recognized as a single run and keep diff-block. Still O(N) — the old 2ⁿ shape (a long block run + non-block tail) stays linear. Added unit tests for the nested block/list cases, the inline-untouched case, and a linear-time guard. I couldn't run the full VS Code test harness locally, so a npm test on your side would be good to confirm nothing else regressed.