@miliastry/quasar 1.0.6 → 1.1.0

package/dist/types/Edits/Rules/unwrapInvisibleColor.d.ts

@@ -0,0 +1,47 @@
+/**
+ * Quasar — `unwrap-invisible-color`
+ *
+ * Removes a `[color]` whose entire content is whitespace.
+ *
+ *   [color=#6A4C93]BARCA[/color][color=#6F518D] [/color][color=#755687]·[/color]
+ *                               ╰── 24 bytes to colour a space ──╯
+ *
+ * A space has no glyph, and `[color]` sets `color` and nothing else — no
+ * background, no decoration — so painting one is a guaranteed no-op. Deleting
+ * the two delimiters turns 24 bytes into 1 and cannot change a pixel.
+ *
+ * This is the dominant waste in expanded gradients, and it is easy to see why:
+ * the tool that expands `[gradient]` into per-character `[color]` spans walks
+ * characters without asking which of them draw ink, so every space in the ramp
+ * gets its own fully-spelled tag.
+ *
+ * ## Only colour
+ *
+ * The same shape is *not* removable for other tags, and the difference is not
+ * subtle:
+ *
+ * - `[u]` / `[s]` draw a line through the gap — visible on a space.
+ * - `[mark]` paints a background — visible on a space.
+ * - `[size]` and `[font]` change the advance width of the space itself.
+ *
+ * Only `color` is invisible on whitespace, so only `color` is unwrapped.
+ */
+import type { GreenNode } from '../../Syntax/GreenNode';
+import type { PlannedEdit } from '../EditPlan';
+import { type OptimizationRule, type RuleContext } from './Rule';
+export declare const UNWRAP_INVISIBLE_COLOR_PRIORITY = 85;
+/**
+ * Whether a node contributes nothing but whitespace.
+ *
+ * Recursive through nested colours, so `[color=A][color=B] [/color][/color]`
+ * counts. `spacing` is whitespace too — a newline inside a colour tag is as
+ * invisible as a space.
+ */
+export declare function isInvisibleWhitespace(node: GreenNode): boolean;
+export declare class UnwrapInvisibleColorRule implements OptimizationRule {
+    readonly id = "unwrap-invisible-color";
+    readonly priority = 85;
+    readonly label = "Unwrap colour tags around whitespace";
+    run(context: RuleContext): PlannedEdit[];
+    private scan;
+}

package/dist/types/Edits/applyEdits.d.ts

@@ -0,0 +1,36 @@
+/**
+ * Quasar — applying a resolved edit set to source text
+ *
+ * The string-rewriting half of the two appliers. Monaco is the other: it takes
+ * the very same `SurgicalEdit[]` and resolves the offsets against its model
+ * itself, which is why neither side ever re-serializes the document and the
+ * two cannot drift.
+ */
+import type { SurgicalEdit } from '../Reconciler/SurgicalReconciler';
+/**
+ * Apply edits carrying ORIGINAL offsets, in one pass.
+ *
+ * The obvious implementation splices the string once per edit:
+ *
+ *     for (const edit of backToFront) out = out.slice(0, s) + text + out.slice(e)
+ *
+ * which is correct and quadratic — every splice copies the whole document, so
+ * a 250.000-character page with ~3.800 edits copies roughly a billion
+ * characters and takes about half a second. Measured, not guessed. Collecting
+ * the untouched spans and joining them once is linear and turns that into a
+ * few milliseconds, which is the difference between a minify command that
+ * feels instant and one that visibly stalls the editor.
+ *
+ * Going forwards rather than backwards is what makes the single pass possible,
+ * and it costs nothing: each edit is measured against the original string
+ * either way.
+ *
+ * ## Contract
+ *
+ * The edits must be pairwise conflict-free — run them through
+ * `resolveEditConflicts` first. An edit that reaches back into a span already
+ * written is a contract violation with no meaningful answer, so it is skipped
+ * rather than allowed to interleave into nonsense; the result stays a valid
+ * document that is merely missing one change.
+ */
+export declare function applyEditsToSource(source: string, edits: readonly SurgicalEdit[]): string;

package/dist/types/Edits/index.d.ts

@@ -0,0 +1,6 @@
+export { classifyOverlap, editsConflict, compareEditPriority, resolveEditConflicts, } from './EditPlan';
+export type { PlannedEdit, RejectedEdit, ResolvedEditPlan, EditRejectionReason, OverlapRelation, } from './EditPlan';
+export { applyEditsToSource } from './applyEdits';
+export { optimizeBBCode, optimizeTree, defaultRules, allRules, } from './Optimizer';
+export type { OptimizationResult, OptimizeOptions, RuleStat } from './Optimizer';
+export * from './Rules';

package/dist/types/Events/EventBus.d.ts

@@ -0,0 +1,103 @@
+/**
+ * DocumentEngine — EventBus
+ *
+ * Publish/subscribe event system for document changes.
+ * Each DocumentModel has its own EventBus instance.
+ *
+ * Events include:
+ * - document_changed (rebuild, edit, undo/redo)
+ * - node_changed (insert, delete, update, move)
+ * - diagnostic_updated
+ * - transaction_applied
+ * - cursor_moved
+ * - selection_changed
+ */
+import type { DocumentChangeKind, NodeId } from '../Types/core';
+import type { Operation } from '../Types/operations';
+import type { NodeMatch } from '../Syntax/NodeMatcher';
+import type { TextChange } from '../Incremental/ChangeTracker';
+export type DocumentEventType = 'document_changed' | 'node_inserted' | 'node_deleted' | 'node_updated' | 'diagnostics_updated' | 'transaction_applied' | 'undo_performed' | 'redo_performed' | 'cursor_moved' | 'selection_changed';
+export interface DocumentEvent {
+    type: DocumentEventType;
+    kind?: DocumentChangeKind;
+    version?: number;
+    source?: string;
+    nodeId?: NodeId;
+    nodeMatch?: NodeMatch | null;
+    change?: TextChange;
+    operations?: Operation[];
+    /**
+     * Where the change came from: `'local'` for user editing, anything else for
+     * programmatic/synced sources. Lets a collaboration layer ignore the echo
+     * of changes it applied itself. Absent on events with no single cause.
+     */
+    origin?: string;
+    /**
+     * On `diagnostics_updated`: how the analysis that produced them was
+     * obtained — `'full'` (every node revalidated) or `'window'` (only the
+     * nodes the edit could have changed; every other node kept its verdict).
+     *
+     * The `diagnostics` on the event are the WHOLE document's either way, so a
+     * subscriber renders them the same in both cases. This is here for the
+     * cases where the difference is the point: a performance overlay, a test
+     * that must notice the incremental path going away, a log line explaining a
+     * slow frame. See `AnalyzeScope`.
+     */
+    analysisScope?: 'full' | 'window';
+    /**
+     * On `diagnostics_updated` with `analysisScope === 'window'`: the span of
+     * the current source that was re-validated, in current coordinates.
+     * `null`/absent when the whole document was.
+     */
+    analysisWindow?: {
+        start: number;
+        end: number;
+    } | null;
+    timestamp: number;
+    [key: string]: unknown;
+}
+export type DocumentEventHandler = (event: DocumentEvent) => void;
+export declare class DocumentEventBus {
+    private listeners;
+    private history;
+    private maxHistory;
+    /**
+     * Record emitted events so `getHistory()` returns them. Off by default:
+     * nothing reads the history today, and a retained event pins its `source`
+     * string — and, through the lazy `nodeMatch` accessor, the entire previous
+     * red/green tree — so an always-on history held megabytes per document
+     * for nobody. Turn it on for debugging or replay tooling.
+     */
+    recordHistory: boolean;
+    /**
+     * Subscribe to an event type.
+     */
+    on(type: DocumentEventType, handler: DocumentEventHandler): () => void;
+    /**
+     * Whether any handler is subscribed to `type` (or to anything, if omitted).
+     *
+     * Emitters use this to skip building event payloads nobody will see — the
+     * common case, since a headless model has no subscribers at all.
+     */
+    hasListeners(type?: DocumentEventType): boolean;
+    /**
+     * Subscribe to all events.
+     */
+    onAny(handler: DocumentEventHandler): () => void;
+    /**
+     * Emit an event.
+     */
+    emit(event: DocumentEvent): void;
+    /**
+     * Remove a specific handler.
+     */
+    off(type: DocumentEventType, handler: DocumentEventHandler): void;
+    /**
+     * Get event history.
+     */
+    getHistory(): DocumentEvent[];
+    /**
+     * Clear all listeners and history.
+     */
+    clear(): void;
+}

package/dist/types/Events/index.d.ts

@@ -0,0 +1,2 @@
+export { DocumentEventBus } from './EventBus';
+export type { DocumentEvent, DocumentEventType, DocumentEventHandler } from './EventBus';

package/dist/types/Formatter/Formatter.d.ts

@@ -0,0 +1,32 @@
+/**
+ * DocumentEngine — Formatter
+ *
+ * Formats the document tree into "pretty" BBCode.
+ * Normalizes indentation, spacing, and whitespace.
+ *
+ * Uses the TagRegistry and Visitor pattern.
+ * Plugins can register custom formatters for custom tags.
+ */
+import { RedNode } from '../Syntax/RedNode';
+export interface FormatOptions {
+    /** Whether to add newlines between block elements */
+    blockNewlines?: boolean;
+    /** Whether to normalize whitespace inside inline elements */
+    normalizeInlineWhitespace?: boolean;
+    /** Maximum line width (0 = no limit) */
+    maxLineWidth?: number;
+    /** Whether to collapse consecutive empty lines */
+    collapseEmptyLines?: boolean;
+    /** Indentation string */
+    indent?: string;
+}
+export declare class Formatter {
+    /**
+     * Format a RedNode tree (extracts text while preserving exact layout/spacing).
+     */
+    format(root: RedNode): string;
+    /**
+     * Format a single node at a given depth.
+     */
+    private formatNode;
+}

package/dist/types/Formatter/index.d.ts

@@ -0,0 +1,2 @@
+export { Formatter } from './Formatter';
+export type { FormatOptions } from './Formatter';

package/dist/types/HTML/HTMLDocumentModel.d.ts

@@ -0,0 +1,13 @@
+import { DocumentModel, type DocumentModelOptions } from '../Model/DocumentModel';
+import { GreenNode } from '../Syntax/GreenNode';
+import { RedNode } from '../Syntax/RedNode';
+export interface HTMLDocumentModelOptions extends DocumentModelOptions {
+    source?: string;
+    language?: string;
+}
+export declare class HTMLDocumentModel extends DocumentModel {
+    constructor(options?: HTMLDocumentModelOptions);
+    static fromHTML(source: string): HTMLDocumentModel;
+    protected parseToGreen(source: string): GreenNode;
+    protected buildRedFromGreen(green: GreenNode): RedNode;
+}

package/dist/types/HTML/HTMLToGreenNode.d.ts

@@ -0,0 +1,4 @@
+import { GreenNode } from '../Syntax/GreenNode';
+import { RedNode } from '../Syntax/RedNode';
+export declare function htmlStringToGreenTree(html: string): GreenNode;
+export declare function greenToRedNode(green: GreenNode, parent?: RedNode | null): RedNode;

package/dist/types/Incremental/BracketIndex.d.ts

@@ -0,0 +1,101 @@
+/**
+ * DocumentEngine — BracketDepthIndex
+ *
+ * Answers the incremental parser's one question about the text OUTSIDE its
+ * window — "does every `[` before this offset find its `]` before it too?" —
+ * without reading the text before the offset.
+ *
+ * ─── Why the scan had to go ─────────────────────────────────────────────────
+ *
+ * `bracketsCloseBefore` walked the whole prefix on every keystroke: with the
+ * caret at the end of the 547 KB fixture that is 547.000 `charCodeAt` calls
+ * per key, measured at 2.2 ms — more than the parse, the splice and the red
+ * build of that same keystroke put together. Caching was declined once on the
+ * grounds that the reasoning is subtle: an edit can expose a `]` that a
+ * deleted `[` used to claim, so any cache keyed on "the prefix has not
+ * changed" is wrong the moment it is asked about a prefix that has.
+ *
+ * ─── Why this is not that cache ─────────────────────────────────────────────
+ *
+ * The scan computes a CLAMPED running depth — `d ← max(0, d + a)` where `a`
+ * is +1 for `[`, −1 for `]`, 0 otherwise — and a clamped running sum has an
+ * exact, composable summary. Over any stretch of text with prefix sums
+ * P₁…Pₙ, the depth after the stretch is a function of the depth before it:
+ *
+ *     d' = Pₙ + max(d, −min(0, P₁, …, Pₙ))
+ *
+ * so a stretch is fully described by two integers, its net sum and its lowest
+ * dip. The index keeps the source as a sequence of PIECES (a few KB each),
+ * each carrying that pair. An edit re-summarises only the piece(s) it touched,
+ * from the NEW text, and every other piece keeps a summary that is still
+ * exactly true of its (unchanged, merely displaced) characters. A query walks
+ * the piece summaries up to the offset and scans only the tail of the piece
+ * the offset falls in. Nothing here is a guess about what the edit exposed:
+ * the touched piece is re-read verbatim, and composition is arithmetic.
+ *
+ * Cost per keystroke: one summary of ≤ 8 KB plus one walk over ~140 piece
+ * summaries at 547 KB — a few microseconds, and independent of where the
+ * caret is. Verified against the plain scan by `BracketIndex.test.ts`: 2.000
+ * random edits over documents full of stray brackets, every offset agreeing.
+ *
+ * The index does not know which document it describes; the parser keys it on
+ * the green root it was last synchronised with and rebuilds it (one scan) when
+ * the root it is handed is not that one. See `IncrementalParser.reparse`.
+ */
+export declare class BracketDepthIndex {
+    /** Length of each piece, in characters. Pieces partition `[0, length)`. */
+    private lengths;
+    /** Net bracket sum of each piece: `[` counts +1, `]` counts −1. */
+    private sums;
+    /** Lowest prefix sum inside each piece, capped at 0 (see the header). */
+    private dips;
+    private _length;
+    /**
+     * Characters read by the last `depthAt` — the tail of one piece, never the
+     * prefix. Exposed so a regression back to an O(prefix) scan is something a
+     * test can assert on, rather than something a profile has to notice.
+     */
+    lastScanned: number;
+    /** The length of the text this index currently describes. */
+    get length(): number;
+    /** Number of pieces — for tests; it should stay ~`length / TARGET_PIECE`. */
+    get pieceCount(): number;
+    /** Describe `source` from scratch. O(n) — one scan, the same the query used to be. */
+    rebuild(source: string): void;
+    /**
+     * Bring the index from the text before an edit to `newSource`, the text
+     * after it. `start`/`endOld` bound the replaced region in OLD coordinates;
+     * `insertedLength` is the length of the text that replaced it.
+     *
+     * Only the pieces overlapping the replaced region are re-read. They are
+     * re-summarised as one piece over the same span in NEW coordinates, and
+     * that piece is split if it has grown past `MAX_PIECE` — so a long paste
+     * ends up as several normal pieces, not one giant one that every later
+     * query near it would have to scan.
+     */
+    applyChange(newSource: string, start: number, endOld: number, insertedLength: number): void;
+    /**
+     * The clamped bracket depth just before `end` — what the plain scan of
+     * `[0, end)` would return. `end === 0` is depth 0; `end > length` is
+     * clamped to the text.
+     */
+    depthAt(source: string, end: number): number;
+    /** Summarise `[from, to)` of `source` and append it as a piece. */
+    private pushPiece;
+    /**
+     * Replace `count` pieces at `index` with the summaries of `[from, to)` of
+     * `source`, cut into pieces of at most `MAX_PIECE`.
+     */
+    private spliceSummaries;
+    /**
+     * Merge the piece at `index` (and the one after it) into a neighbour when
+     * it has shrunk below `MIN_PIECE` and the pair stays under `MAX_PIECE`.
+     *
+     * Merging two summaries is the composition from the header applied to the
+     * pair: the sum adds, and the dip of the second is measured from the end of
+     * the first. No text is read.
+     */
+    private mergeSmallAround;
+    /** Fold piece `i + 1` into piece `i`. */
+    private mergePair;
+}

package/dist/types/Incremental/ChangeTracker.d.ts

@@ -0,0 +1,69 @@
+/**
+ * DocumentEngine — ChangeTracker
+ *
+ * Tracks text changes made to the document source.
+ * Used by IncrementalParser to determine what needs to be re-parsed.
+ */
+export interface TextChange {
+    start: number;
+    end: number;
+    text: string;
+}
+/**
+ * Source range of a text edit, in BOTH coordinate systems.
+ *
+ * An edit sits between two documents: `start`/`end` describe the changed
+ * region in NEW-source coordinates (the current document), while `endOld` is
+ * the end of the replaced region in OLD-source coordinates. The incremental
+ * preview (`BlockPatcher`) uses `start`/`endOld` to locate the affected blocks
+ * in the PREVIOUS tree (whose offsets are pre-edit) and `start`/`end` in the
+ * new one — insertions or deletions between the two make the naive single-`end`
+ * wrong, which is exactly why both ends are kept.
+ */
+export interface TextChangeRange {
+    /** Start of the edited region (identical in both coordinate systems). */
+    start: number;
+    /** End of the edited region, in new-source coordinates. */
+    end: number;
+    /** End of the replaced region, in old-source coordinates. */
+    endOld: number;
+}
+export interface TextChangeStats {
+    totalChanges: number;
+    totalInserted: number;
+    totalDeleted: number;
+    lastChange: TextChange | null;
+}
+export declare class ChangeTracker {
+    private changes;
+    private maxHistory;
+    constructor(maxHistory?: number);
+    /**
+     * Track a text change.
+     */
+    track(change: TextChange): void;
+    /**
+     * Get all tracked changes.
+     */
+    getAll(): TextChange[];
+    /**
+     * Get the most recent change.
+     */
+    getLast(): TextChange | null;
+    /**
+     * Get the affected range for the last N changes.
+     * Returns null if no changes have been tracked.
+     */
+    getAffectedRange(count?: number): {
+        start: number;
+        end: number;
+    } | null;
+    /**
+     * Clear change history.
+     */
+    clear(): void;
+    /**
+     * Get statistics about tracked changes.
+     */
+    getStats(): TextChangeStats;
+}

package/dist/types/Incremental/IncrementalParser.d.ts

@@ -0,0 +1,246 @@
+/**
+ * DocumentEngine — IncrementalParser
+ *
+ * Re-parses the smallest region a text change can have affected, instead of
+ * the whole document.
+ *
+ * ─── Why this was rewritten (roadmap S5 / point 9) ──────────────────────────
+ *
+ * The previous implementation spliced RED nodes in place and never touched
+ * ranges. Three consequences, all measured:
+ *
+ *  - The re-parsed subtree came from `newSource.slice(start, end)`, so its
+ *    ranges were based at 0 and were grafted in without rebasing. Every offset
+ *    inside the edited region was wrong by `start`.
+ *  - Siblings after the splice and every ancestor kept their old ranges, so
+ *    the tree silently disagreed with the text it claimed to describe.
+ *  - It returned `newRootRed.green` — the OLD green root — so the model's
+ *    `_greenRoot` and `_redRoot` desynchronised permanently after the first
+ *    incremental edit.
+ *
+ * Rendering the result and comparing it against a full rebuild of the same
+ * final text: 3 of 6 realistic editing scenarios produced DIFFERENT HTML, and
+ * one grew 14 phantom nodes (1752 vs 1738).
+ *
+ * ─── How it works now ───────────────────────────────────────────────────────
+ *
+ * Everything happens on the GREEN tree, and the red tree is derived from it.
+ * That is not a stylistic choice: green nodes carry widths and no position, so
+ * a position is something only a red node has — and therefore only a red node
+ * can be wrong about.
+ *
+ *   1. Descend to the deepest node whose inner span (the part between its
+ *      delimiters) contains the change, refusing to enter the kinds whose
+ *      children depend on context outside them (see `OPAQUE_KINDS`).
+ *   2. Take the run of that node's children the change touches, widened by one
+ *      on each side, and re-parse just those.
+ *   3. Splice the result back over that run and rebuild the ancestor spine,
+ *      sharing every untouched subtree by reference.
+ *
+ * The unit is a RUN OF SIBLINGS, not a whole node. Re-parsing a container's
+ * entire contents because one character changed inside it meant typing into a
+ * 13 KB `[notice]` re-lexed 66% of the document per keystroke — and an edit at
+ * document level had no enclosing container at all, so it fell back to a full
+ * rebuild, which is exactly where the caret sits while you write the end of a
+ * post.
+ *
+ * Step 1 relies on the partition invariant from point 14: without it, "the
+ * part between the delimiters" is not a well-defined range, which is exactly
+ * why this repair was blocked on that work.
+ *
+ * When any precondition fails the parser returns a full rebuild rather than a
+ * plausible-looking wrong tree. `path` says which happened, `reason` says why.
+ */
+import { RedNode } from '../Syntax/RedNode';
+import { GreenNode } from '../Syntax/GreenNode';
+import type { TextChange } from './ChangeTracker';
+/**
+ * A span of the source, `[start, end)`, in the coordinates of the text the
+ * result describes.
+ */
+export interface SourceSpan {
+    start: number;
+    end: number;
+}
+export interface EditOperation {
+    kind: 'insert' | 'delete' | 'replace';
+    start: number;
+    end: number;
+    text: string;
+    /** The minimal range that needs re-parsing */
+    affectedStart: number;
+    affectedEnd: number;
+}
+/** Options a caller's parse callback must understand. */
+export interface ReparseParseOptions {
+    /**
+     * Whether the text being parsed is document-level content. Inner spans of
+     * containers are not, and must not be grouped into paragraphs.
+     */
+    normalizeParagraphs: boolean;
+}
+export interface ReparseResult {
+    green: GreenNode;
+    red: RedNode;
+    /** Nodes that were affected by the change */
+    affectedNodes: RedNode[];
+    /** Time taken in ms (total) */
+    duration: number;
+    /** Per-phase timing breakdown in ms */
+    timings: {
+        findAffected: number;
+        safeBoundary: number;
+        parse: number;
+        buildRed: number;
+        mutate: number;
+        other: number;
+    };
+    /** Which path was used */
+    path: 'incremental' | 'full_rebuild';
+    /** When `full_rebuild`, why the incremental path was declined. */
+    reason?: FallbackReason;
+    /**
+     * The span of `newSource` that went through the parser, in NEW coordinates,
+     * or `null` after a full rebuild (where the answer is "all of it").
+     *
+     * This is the contract the incremental semantic analysis is built on. The
+     * red tree that comes back is derived from a green tree that shares every
+     * subtree outside this span by reference with the previous one, so — with
+     * red-subtree reuse — every red node outside the span is the SAME object it
+     * was before the edit, and everything anyone computed about it (its
+     * diagnostics, above all) is still true of it, up to a shift in position.
+     * The nodes inside the span, plus the ancestors on the path down to it
+     * (rebuilt because their child lists changed), are the only ones that are
+     * new. `SemanticAnalyzer.analyzeWindow` re-validates exactly those.
+     *
+     * The span is closed on the widened window, not on the edit: the parser
+     * re-parses the sibling on each side of the change too (see
+     * `findReparseWindow`), and those siblings are new nodes as well.
+     */
+    window: SourceSpan | null;
+}
+export type FallbackReason = 
+/** No sibling window could be formed around the change. */
+'no-window'
+/** The change touches a container's own delimiter. */
+ | 'touches-delimiter'
+/** The region cannot be lexed in isolation — see `regionIsSelfContained`. */
+ | 'region-not-isolated'
+/** An unclosed `[` before the region could claim a `]` the edit creates. */
+ | 'open-bracket-before'
+/**
+ * The window changed what the parser's `autoClosed` set holds when the text
+ * after it is read — see `pendingAutoClosePreserved`.
+ */
+ | 'pending-auto-close'
+/** The container covers so much of the document that a rebuild is cheaper. */
+ | 'region-too-large'
+/** The document is small enough that rebuilding it outright costs less. */
+ | 'document-too-small'
+/** The tree's ranges disagree with the source it is supposed to describe. */
+ | 'stale-ranges';
+export interface IncrementalParserOptions {
+    /** Override `MIN_SOURCE_LENGTH`. Set to 0 to always attempt a splice. */
+    minSourceLength?: number;
+    /** Override `MAX_REGION_FRACTION`. */
+    maxRegionFraction?: number;
+}
+export declare class IncrementalParser {
+    private readonly minSourceLength;
+    private readonly maxRegionFraction;
+    /**
+     * Bracket-depth summary of the source, for the boundary check below.
+     *
+     * Keyed on the green root it was last synchronised with: a reparse whose
+     * `oldGreen` is that root brings the index across the edit by re-reading a
+     * few KB around it; any other root (a `rebuild`, a model handed a foreign
+     * tree) rebuilds it with one scan — the same scan every keystroke used to
+     * pay. See `BracketDepthIndex` for why the summary is exact.
+     */
+    private readonly brackets;
+    private bracketsRoot;
+    /**
+     * Whether, within the current `reparse` call, the index has been brought to
+     * describe `newSource`. Explicit rather than inferred: a length comparison
+     * would confuse an unsynchronised index over an older text of the same
+     * length (insert one character, delete one) with a synchronised one.
+     */
+    private bracketsSynced;
+    /**
+     * Where the document carries a pending `autoClosed` name, memoised on the
+     * green root it was measured over — see {@link PendingSpans}.
+     *
+     * It survives an incremental splice by construction: the window guard that
+     * consults it only lets through edits that leave the crossings on both
+     * sides of the window as they were, so the spans need only be moved. Any
+     * other outcome drops the key and the next edit pays one walk.
+     */
+    private pendingRoot;
+    private pendingSpans;
+    /**
+     * The thresholds are constructor options because they are performance
+     * tuning, not semantics: the tree that comes out is the same either way, so
+     * a caller with a different document profile — or a test that wants to
+     * exercise the splice on a two-line document — can move them without
+     * changing what the parser means.
+     */
+    constructor(options?: IncrementalParserOptions);
+    /**
+     * Characters the last boundary check actually read — the tail of one index
+     * piece, never the prefix. Exposed so a test can pin the bound.
+     */
+    get lastBoundaryScan(): number;
+    /**
+     * Does every `[` before `end` find its `]` before `end` too?
+     *
+     * If one does not, the lexer's bracket matching for it scans onward into
+     * the region we are about to re-parse — and an edit that adds a `]` there
+     * (or deletes a `[` that was keeping the nesting depth up) changes what that
+     * OUTSIDE bracket means. The region would be re-parsed correctly and the
+     * text before it would silently become something else.
+     *
+     * A clamped depth count is exact for this question: the lexer pairs
+     * brackets with a stack, so a `[` is unmatched precisely when the depth
+     * never returns to its level. The count used to be a scan of the whole
+     * prefix on every keystroke — 22% of a keystroke with the caret at the end
+     * of a post, 1.4 ms on the 547 KB fixture. The index answers it from piece
+     * summaries, reading at most one piece of text.
+     *
+     * The index is brought across the edit here, not earlier: the paths that
+     * return before this point never needed it, and on the next call the
+     * root-key mismatch simply rebuilds it. The caller re-keys it on whatever
+     * green root it returns.
+     */
+    private bracketsCloseBefore;
+    /**
+     * Reparse a tree after a text change.
+     *
+     * Always returns a result — either an incremental splice or a full rebuild.
+     * It never returns a tree whose ranges do not describe `newSource`.
+     */
+    reparse(oldRed: RedNode, oldGreen: GreenNode, change: TextChange, newSource: string, parseCallback: (text: string, options?: ReparseParseOptions) => GreenNode, buildRedCallback: (green: GreenNode) => RedNode): ReparseResult;
+    /**
+     * Find the run of sibling children a change can have affected.
+     *
+     * Two steps. First descend to the deepest node whose INNER span contains the
+     * change — inner rather than full, so a container's own delimiters never go
+     * back through the parser: an edit that touches `[colo|r=red]` changes what
+     * that element IS, and is handled by re-parsing it as part of its parent's
+     * window instead.
+     *
+     * Then pick the children that the change touches, widened by one on each
+     * side. The widening is what lets a deletion MERGE two nodes: removing the
+     * blank line between two paragraphs changes only the node in between, and
+     * without a neighbour on each side the re-parse could not see that the two
+     * survivors have to become one.
+     */
+    private findReparseWindow;
+    /**
+     * Nodes on the path from the root down to the change.
+     *
+     * Kept because it is part of the public surface and is genuinely useful for
+     * callers that want to know what an edit touched; the reparse itself no
+     * longer needs it.
+     */
+    findAffectedNodes(root: RedNode, change: TextChange): RedNode[];
+}

package/dist/types/Incremental/__tests__/BracketIndex.test.d.ts

@@ -0,0 +1 @@
+export {};