@kabmo-labs/kabmo 0.7.0 → 0.9.0

package/src/shared/lib/code/highlighter-warmup.ts

@@ -0,0 +1,112 @@
+/**
+ * @license
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+/**
+ * Pay the tokenizer's start-up cost before the reader taps anything.
+ *
+ * `EAGER_LANGS` are loaded in the background at boot, but loading a grammar is
+ * not compiling it: the grammar's regexes are built and JIT-ed on the first
+ * tokenize, which is why the FIRST expand of a card in a given language measured
+ * 220–300 ms at 4× CPU while the same card re-expanded in 33 ms. That first
+ * expand is the one a reader actually experiences — a transcript opens with
+ * `read` and `bash` cards.
+ *
+ * So each eager grammar is tokenized once, on a tiny sample, while the main
+ * thread is idle. The sample's markup is discarded; the work being paid for is
+ * the compile behind it. One language per idle slice, so a slow grammar cannot
+ * become the long task this exists to prevent — and a grammar that has not
+ * landed yet is retried rather than skipped, because tokenizing before it
+ * arrives compiles nothing.
+ *
+ * Booted from `main.tsx` rather than from `highlighter.ts`: the warm-up needs
+ * the memo, which needs the highlighter, and an import in the other direction
+ * would close that cycle.
+ */
+
+import { isLanguageReady } from '@/shared/lib/code/highlighter-lazy';
+import { highlightBlock } from '@/shared/lib/code/highlight-memo';
+import { scheduleIdle } from '@/shared/lib/code/idle';
+import { EAGER_LANGS } from '@/shared/lib/code/shiki-langs';
+
+/**
+ * A few lines that make the grammar walk its own rule set: a keyword, a string,
+ * a comment, a call and a block. The exact text does not matter — the compile
+ * does — so these are deliberately tiny.
+ */
+const SAMPLES: Record<string, string> = {
+  typescript: '// warm\nconst value: number = 1;\nfunction read(input: string) {\n  return input;\n}\n',
+  tsx: '// warm\nexport const View = ({ title }: { title: string }) => (\n  <div className="row">{title}</div>\n);\n',
+  javascript: '// warm\nconst value = 1;\nfunction read(input) {\n  return input;\n}\n',
+  jsx: '// warm\nexport const View = ({ title }) => (\n  <div className="row">{title}</div>\n);\n',
+  json: '{\n  "name": "warm",\n  "items": [1, 2, 3],\n  "ok": true\n}\n',
+  bash: '#!/bin/sh\n# warm\nset -e\nfor file in *.ts; do\n  echo "$file"\ndone\n',
+  python: '# warm\ndef read(value: str) -> str:\n    return value.strip()\n',
+  markdown: '# warm\n\nA paragraph with **bold** text and a `code` span.\n\n- item\n',
+  yaml: 'name: warm\nitems:\n  - one\n  - two\nenabled: true\n',
+  diff: '--- a/file.ts\n+++ b/file.ts\n@@ -1,2 +1,2 @@\n-old line\n+new line\n context\n',
+};
+
+const DEFAULT_SAMPLE = '// warm\nconst value = 1;\nfunction read(input) {\n  return input;\n}\n';
+
+/** How many idle slices a not-yet-loaded grammar is retried for. */
+const MAX_WAIT_SLICES = 120;
+
+export interface WarmOptions {
+  /** Languages to warm; defaults to the eager set. */
+  languages?: readonly string[];
+  /** The tokenizer; injected so a test can observe the schedule. */
+  highlight?: (code: string, language: string) => void;
+  /** Grammar readiness; injected for the same reason. */
+  ready?: (language: string) => boolean;
+  /** The idle scheduler; injected so a test can drive it synchronously. */
+  schedule?: (run: () => void) => () => void;
+}
+
+let started = false;
+
+/**
+ * Warm every eager grammar once per page load, one per idle slice.
+ *
+ * Idempotent: a second call is a no-op, so a re-evaluated client entry cannot
+ * re-tokenize every language.
+ */
+export function warmSyntaxTokenizers(options: WarmOptions = {}): void {
+  if (started) return;
+  if (typeof window === 'undefined') return;
+  started = true;
+
+  const languages = options.languages ?? EAGER_LANGS;
+  const highlight = options.highlight ?? ((code: string, language: string) => { highlightBlock(code, language); });
+  const ready = options.ready ?? isLanguageReady;
+  const schedule = options.schedule ?? ((run: () => void) => scheduleIdle(run));
+
+  const queue = [...languages];
+  let waiting = 0;
+  const step = () => {
+    const language = queue.shift();
+    if (language === undefined) return;
+    if (!ready(language)) {
+      // The grammar is still being fetched. Warming it now would compile
+      // nothing and the sample would not even be cacheable.
+      if (++waiting <= MAX_WAIT_SLICES) queue.push(language);
+      schedule(step);
+      return;
+    }
+    waiting = 0;
+    try {
+      highlight(SAMPLES[language] ?? DEFAULT_SAMPLE, language);
+    } catch {
+      // A grammar that cannot warm is not an error: the first real highlight
+      // falls back to escaped text and retries when the grammar lands.
+    }
+    schedule(step);
+  };
+  schedule(step);
+}
+
+/** Test/restart seam: forget that the warm-up already ran. */
+export function resetTokenizerWarmup(): void {
+  started = false;
+}

package/src/shared/lib/code/highlighter.ts

@@ -69,7 +69,9 @@ async function boot(): Promise<HighlighterCore | null> {
     notify();
     // Grammars arrive on demand (`ensureLanguage`); the eager set is only a
     // head start for the languages a chat session hits immediately, and boot
-    // does not wait on it.
+    // does not wait on it. `main.tsx` pays the tokenizer's compile cost once
+    // the eager set has landed — loading a grammar is not compiling it, and the
+    // first card expand used to pay that compile inside the tap.
     void ensureLanguages(highlighter, EAGER_LANGS);
     return highlighter;
   } catch (error) {

package/src/shared/lib/code/idle.ts

@@ -0,0 +1,37 @@
+/**
+ * @license
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+/**
+ * Run work when the main thread is next free.
+ *
+ * Tokenizing a tool card's code is the expensive half of expanding it — measured
+ * at 730–1484 ms on a throttled phone for a `read`/`grep` card — and running it
+ * inside the render that a tap scheduled put all of that in the tap's own task:
+ * the card appeared only after the grammar had walked every line. Deferring it
+ * costs one plain-text frame and moves the work out of the interaction.
+ *
+ * `requestIdleCallback` is the browser's own "nothing else is waiting" signal;
+ * the timeout is a FLOOR on latency rather than a budget, so a busy page still
+ * paints the colour within a quarter second. Runtimes without it (happy-dom,
+ * older Safari) fall back to the next macrotask.
+ */
+
+const IDLE_TIMEOUT_MS = 250;
+
+type IdleHost = {
+  requestIdleCallback?: (callback: () => void, options?: { timeout: number }) => number;
+  cancelIdleCallback?: (handle: number) => void;
+};
+
+/** Schedule `run`; the returned function cancels it. */
+export function scheduleIdle(run: () => void, timeoutMs: number = IDLE_TIMEOUT_MS): () => void {
+  const host = globalThis as unknown as IdleHost;
+  if (typeof host.requestIdleCallback === 'function') {
+    const handle = host.requestIdleCallback(run, { timeout: timeoutMs });
+    return () => host.cancelIdleCallback?.(handle);
+  }
+  const handle = setTimeout(run, 0);
+  return () => clearTimeout(handle);
+}

package/src/shared/lib/code/outline/rows.test.ts

@@ -0,0 +1,96 @@
+/**
+ * @license
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+/**
+ * The outline's two bounds.
+ *
+ * Both exist because a large file's outline is not a long list, it is a DOM:
+ * measured on a 10 MB source with 63 618 declarations, the panel mounted
+ * 446 308 nodes and a keystroke cost 953 ms (against the editor's own 34 ms).
+ * These cases pin the arithmetic that keeps that from happening, and the
+ * sentences that stop a truncated list from reading as a complete one.
+ */
+
+import { describe, expect, test } from 'bun:test';
+import {
+  MAX_OUTLINE_ROWS,
+  MAX_OUTLINE_SCAN_CHARS,
+  outlineTooLargeNotice,
+  outlineTruncatedNotice,
+  outlineWindow,
+} from '@/shared/lib/code/outline/rows';
+import type { OutlineSymbol } from '@/shared/lib/code/outline/types';
+
+function symbols(count: number): OutlineSymbol[] {
+  return Array.from({ length: count }, (_, i) => ({
+    name: `fn${i}`,
+    kind: 'function' as const,
+    line: i + 1,
+    column: 0,
+    depth: 0,
+  }));
+}
+
+describe('outlineWindow', () => {
+  test('a list under the cap is returned whole, in source order', () => {
+    const all = symbols(5);
+    const window = outlineWindow(all);
+
+    expect(window.rows).toEqual(all);
+    expect(window.total).toBe(5);
+    expect(window.truncated).toBe(false);
+  });
+
+  test('exactly the cap is not truncated', () => {
+    const window = outlineWindow(symbols(MAX_OUTLINE_ROWS));
+
+    expect(window.rows).toHaveLength(MAX_OUTLINE_ROWS);
+    expect(window.truncated).toBe(false);
+  });
+
+  test('past the cap the list is the FIRST rows, and it says how many there are', () => {
+    const window = outlineWindow(symbols(MAX_OUTLINE_ROWS + 120));
+
+    expect(window.rows).toHaveLength(MAX_OUTLINE_ROWS);
+    expect(window.total).toBe(MAX_OUTLINE_ROWS + 120);
+    expect(window.truncated).toBe(true);
+    // Source order, not a sample: the outline is a map of the document, so the
+    // top of the file is what a window shows.
+    expect(window.rows[0].name).toBe('fn0');
+    expect(window.rows[MAX_OUTLINE_ROWS - 1].name).toBe(`fn${MAX_OUTLINE_ROWS - 1}`);
+  });
+
+  test('an empty list is not truncated', () => {
+    const window = outlineWindow([]);
+
+    expect(window.rows).toEqual([]);
+    expect(window.total).toBe(0);
+    expect(window.truncated).toBe(false);
+  });
+});
+
+describe('outlineTooLargeNotice', () => {
+  test('a buffer at the scan ceiling is still outlined', () => {
+    expect(outlineTooLargeNotice(MAX_OUTLINE_SCAN_CHARS)).toBeNull();
+    expect(outlineTooLargeNotice(1024)).toBeNull();
+  });
+
+  test('past it the sentence names the size, so the empty panel is explained', () => {
+    const notice = outlineTooLargeNotice(MAX_OUTLINE_SCAN_CHARS + 1);
+
+    expect(notice).not.toBeNull();
+    expect(notice).toContain('8.0 MB');
+    expect(notice).toContain('too large to outline');
+  });
+});
+
+describe('outlineTruncatedNotice', () => {
+  test('it names both the shown count and the total, thousands separated', () => {
+    const notice = outlineTruncatedNotice(63618);
+
+    expect(notice).toContain('500');
+    expect(notice).toContain('63,618');
+  });
+});

package/src/shared/lib/code/outline/rows.ts

@@ -0,0 +1,94 @@
+/**
+ * @license
+ * SPDX-License-Identifier: Apache-2.0
+ */
+
+/**
+ * How much of an outline a panel is allowed to draw, and when it is not drawn
+ * at all.
+ *
+ * Both bounds exist because a large file's outline is not a long list — it is a
+ * DOM. Measured in the browser on a 10 MB source file with 63 618 declarations:
+ * **446 308 DOM nodes, 415 MB of JS heap, and 953 ms per keystroke** while the
+ * panel was on screen (the editor's own cost is 34 ms). Expanding the section
+ * took 2.7 s. The scan is not the problem — it is 366 ms in Bun, once per pause
+ * — the ROWS are.
+ *
+ * Two answers, and they are different questions:
+ *
+ * - **`MAX_OUTLINE_ROWS` caps the list.** An outline is a map you scan by eye or
+ *   jump from; nobody reads 63 000 rows, and the panel says how many it is not
+ *   showing rather than silently truncating. Same shape as the search panel's
+ *   `MAX_SEARCH_RESULTS`.
+ * - **`MAX_OUTLINE_SCAN_CHARS` skips the scan above a size where it costs more
+ *   than the list is worth.** At 10 MB a scan is ~366 ms of blocked main thread
+ *   every time the buffer settles, which is a stutter per typing pause. The
+ *   sentence says so instead of leaving the panel empty, which would read as
+ *   "this file has no declarations".
+ *
+ * The size is counted in CODE UNITS (`content.length`), not bytes: measuring
+ * UTF-8 bytes would mean encoding the whole buffer to answer a guard, and for
+ * the ASCII that dominates source files the two numbers are the same. A file of
+ * multibyte characters therefore trips the guard slightly early — the safe
+ * direction.
+ */
+
+import type { OutlineSymbol } from '@/shared/lib/code/outline/types';
+
+/**
+ * Rows a panel renders. Past this the list is truncated with a count, not
+ * silently shortened.
+ */
+export const MAX_OUTLINE_ROWS = 500;
+
+/** Buffer size above which the outline is not scanned at all. */
+/**
+ * Buffer size above which the outline is not scanned at all.
+ *
+ * The scan is one blocked stretch of main thread after each typing pause, and it
+ * measured 38 ms at 1 MB, 160 ms at 5 MB, 262 ms at 10 MB and 519 ms at 20 MB —
+ * linear in the buffer. 8 MiB keeps that pause under ~210 ms, which is less than
+ * the debounce that schedules it and therefore reads as "the list settled"
+ * rather than as a stutter.
+ *
+ * Past it the panel says the file is too large to outline instead of scanning
+ * it: a declaration list for a 30 MB file is not worth a half-second freeze on
+ * every pause, and an empty list would read as "no declarations here".
+ */
+export const MAX_OUTLINE_SCAN_CHARS = 8 * 1024 * 1024;
+
+export interface OutlineWindow {
+  /** The rows to render — at most `MAX_OUTLINE_ROWS`. */
+  rows: OutlineSymbol[];
+  /** Symbols the scan actually found, including the ones not rendered. */
+  total: number;
+  /** True when `rows` is shorter than `total`. */
+  truncated: boolean;
+}
+
+/**
+ * The rows a panel should render, and whether it is showing all of them.
+ *
+ * Source order is preserved: an outline is a map of a document, so the first N
+ * declarations are the top of the file rather than an arbitrary sample.
+ */
+export function outlineWindow(symbols: readonly OutlineSymbol[]): OutlineWindow {
+  const total = symbols.length;
+  if (total <= MAX_OUTLINE_ROWS) return { rows: symbols as OutlineSymbol[], total, truncated: false };
+  return { rows: symbols.slice(0, MAX_OUTLINE_ROWS), total, truncated: true };
+}
+
+/** The sentence printed under a truncated list. */
+export function outlineTruncatedNotice(total: number): string {
+  return `Showing the first ${MAX_OUTLINE_ROWS.toLocaleString()} of ${total.toLocaleString()} symbols.`;
+}
+
+/**
+ * The sentence a panel prints instead of rows when the buffer is past the scan
+ * ceiling, or null when it is not.
+ */
+export function outlineTooLargeNotice(contentLength: number): string | null {
+  if (contentLength <= MAX_OUTLINE_SCAN_CHARS) return null;
+  const mb = contentLength / (1024 * 1024);
+  return `This file is ${mb.toFixed(1)} MB — too large to outline.`;
+}

package/src/shared/lib/code/syntax-highlight.test.ts

@@ -6,10 +6,9 @@
 import { beforeAll, describe, expect, test } from 'bun:test';
 
 import { bootSyntax, onLanguageReady, requestLanguage } from '@/shared/lib/code/highlighter';
-import { findMatches } from '@/shared/lib/code/editor/find';
+import { findMatches } from '@/shared/lib/code/editor/find-scan';
 import { getLanguageFromPath } from '@/shared/lib/code/language';
 import { highlightCode, highlightLines } from '@/shared/lib/code/syntax-highlight';
-import { highlightCodeWindow } from '@/shared/lib/code/windowed-highlight';
 
 /** Shiki emits `<span class="shiki">…` with dual-theme CSS variables per token. */
 const SHIKI_RE = /<span class="shiki">/;
@@ -115,54 +114,6 @@ describe('highlightCode', () => {
   });
 });
 
-describe('highlightCodeWindow', () => {
-  const source = Array.from({ length: 120 }, (_, index) =>
-    index === 0 ? 'export const first = 1;' : `export const value${index} = ${index}; // line ${index}`,
-  ).join('\n');
-
-  /** The wrapper the app's `.shiki span` colour rule depends on. */
-  const unwrap = (html: string) => html.replace(/^<span class="shiki">/, '').replace(/<\/span>$/, '');
-
-  test('wraps the window in the class the token colours are scoped to', () => {
-    const window = highlightCodeWindow(source, 'typescript', { start: 0, end: 3 });
-
-    // Without this class no `.shiki span` rule matches, so the tokens would
-    // render in the plain ink colour.
-    expect(window).toMatch(SHIKI_RE);
-    expect(window.endsWith('</span>')).toBe(true);
-  });
-
-  test('returns only the requested lines, joined as the editor renders them', () => {
-    const window = highlightCodeWindow(source, 'typescript', { start: 10, end: 13 });
-    const rows = highlightLines(source, 'typescript');
-
-    expect(unwrap(window).split('\n')).toEqual(rows.slice(10, 13));
-  });
-
-  test('keeps multi-line grammar state from the lines above the window', () => {
-    const commented = ['/*', ' * a block comment', ' * spanning several lines', ' */', 'const after = 1;'].join('\n');
-    const rows = highlightLines(commented, 'typescript');
-    // Line 2 sits inside the comment, whose opening line is outside the window.
-    const window = highlightCodeWindow(commented, 'typescript', { start: 2, end: 4 });
-
-    expect(unwrap(window).split('\n')).toEqual(rows.slice(2, 4));
-  });
-
-  test('renders an over-long line as plain text instead of tokenizing it', () => {
-    const minified = `const bundled = "${'x'.repeat(200)}";\nconst next = 1;`;
-    const window = highlightCodeWindow(minified, 'javascript', { start: 0, end: 2 }, { maxLineLength: 50 });
-
-    expect(window).toContain('const bundled');
-    expect(unwrap(window).split('\n')[0]).not.toContain('--shiki-light:');
-    expect(unwrap(window).split('\n')[1]).toContain('--shiki-light:');
-  });
-
-  test('returns nothing for a window outside the document', () => {
-    expect(highlightCodeWindow('const a = 1;', 'typescript', { start: 5, end: 9 })).toBe('');
-    expect(highlightCodeWindow('const a = 1;', 'typescript', { start: 0, end: 0 })).toBe('');
-  });
-});
-
 describe('find marks', () => {
   const code = 'const alpha = 1;\nconst beta = alpha + 2;\n';
   const PLAIN = { matchCase: false, wholeWord: false, isRegex: false };
@@ -206,35 +157,6 @@ describe('find marks', () => {
     expect(plain).not.toContain('<mark');
   });
 
-  test('keeps a windowed match on its own line, re-based to the slice', () => {
-    const marks = findMatches(code, 'alpha', PLAIN).matches;
-    // The window renders line 1 only. The match on line 0 must not reappear on
-    // line 1's text, and the current index (line 0's match) must not mark
-    // anything here.
-    const window = highlightCodeWindow(code, 'typescript', { start: 1, end: 2 }, { marks, currentMark: 0 });
-
-    expect(marked(window).join('')).toBe('alpha');
-    expect(window).not.toContain('data-find-current');
-  });
-
-  test('re-bases the current index onto the marks inside the window', () => {
-    const marks = findMatches(code, 'alpha', PLAIN).matches;
-    const window = highlightCodeWindow(code, 'typescript', { start: 1, end: 2 }, { marks, currentMark: 1 });
-
-    expect(window.match(/data-find-current/g)?.length).toBe(1);
-    expect(marked(window).join('')).toBe('alpha');
-  });
-
-  test('a mark reaching past the window is clipped to it', () => {
-    // The last line has no trailing newline, so a mark that runs to the end of
-    // the slice would be clamped by the rebase.
-    const window = highlightCodeWindow(code, 'typescript', { start: 1, end: 3 }, {
-      marks: [{ start: 30, end: 999 }],
-      currentMark: 0,
-    });
-
-    expect(marked(window).join('')).toBe('alpha + 2;');
-  });
 });
 
 describe('getLanguageFromPath', () => {

package/src/shared/lib/code/syntax-highlight.ts

@@ -168,12 +168,11 @@ export function highlightLines(
   const rawLines = code.split('\n');
   const marks = options.marks;
   const currentMark = options.currentMark ?? -1;
-  const occurrenceFrom = options.occurrenceFrom ?? -1;
   // A grammar that has not arrived yet, or a highlighter that failed to boot,
   // still gets the find marks: the widget's feedback must not depend on Shiki.
   const plain = (lineIndex: number): string => {
     if (!marks || marks.length === 0) return escapeCode(rawLines[lineIndex]);
-    return tokenMarkup(rawLines[lineIndex], lineStartOffset(code, lineIndex), marks, currentMark, occurrenceFrom);
+    return tokenMarkup(rawLines[lineIndex], lineStartOffset(code, lineIndex), marks, currentMark);
   };
   if (!code) return rawLines;
   const hl = getHighlighterSync();
@@ -191,7 +190,7 @@ export function highlightLines(
       let offset = lineStartOffset(code, lineIndex);
       return lineTokens
         .map((tok) => {
-          const content = tokenMarkup(tok.content, offset, marks, currentMark, occurrenceFrom);
+          const content = tokenMarkup(tok.content, offset, marks, currentMark);
           offset += tok.content.length;
           if (!tok.htmlStyle) return content;
           const style = Object.entries(tok.htmlStyle)

package/src/shared/lib/fs/file-kind-classify.test.ts

@@ -28,6 +28,7 @@ import {
   PDF_MAX_FILE_BYTES,
   unsupportedEditorMessage,
 } from '@/shared/lib/fs/file-kind';
+import { formatBytes } from '@/shared/lib/format/number';
 
 const bytes = (...values: number[]): Uint8Array => new Uint8Array(values);
 
@@ -96,8 +97,11 @@ describe('classifyEditorFile', () => {
 
   // The document ceiling does not reach plain text: a 6 MB source file is still
   // refused, because a textarea holds that buffer for the life of the tab.
-  test('plain text keeps the text ceiling', () => {
-    expect(classifyEditorFile({ path: 'big.ts', size: 6 * 1024 * 1024 })).toBe('too-large');
+  test('plain text keeps the text ceiling, which a real source file clears', () => {
+    // 6 MB was over the old 5 MiB ceiling and is a normal generated file, not a
+    // refusal. The ceiling moved; this case is what keeps it from moving back.
+    expect(classifyEditorFile({ path: 'big.ts', size: 6 * 1024 * 1024 })).toBe('text');
+    expect(classifyEditorFile({ path: 'big.log', size: EDITOR_MAX_FILE_BYTES })).toBe('text');
     expect(classifyEditorFile({ path: 'big.log', size: EDITOR_MAX_FILE_BYTES + 1 })).toBe('too-large');
   });
 
@@ -120,24 +124,34 @@ describe('unsupportedEditorMessage', () => {
   });
 
   test('a size refusal names both the actual size and the ceiling', () => {
-    const message = unsupportedEditorMessage('too-large', 9 * 1024 * 1024);
-    expect(message).toContain('9.00 MB');
-    expect(message).toContain('5.00 MB');
+    // Derived, never spelled out: the point of the sentence is that its number
+    // is the one the classifier applied, so a literal here would pass while the
+    // two disagreed.
+    const message = unsupportedEditorMessage('too-large', 40 * 1024 * 1024);
+    expect(message).toContain('40.00 MB');
+    expect(message).toContain(formatBytes(EDITOR_MAX_FILE_BYTES));
   });
 
   test('a size refusal without a measured size names only the ceiling', () => {
     const message = unsupportedEditorMessage('too-large');
-    expect(message).toContain('5.00 MB');
+    expect(message).toContain(formatBytes(EDITOR_MAX_FILE_BYTES));
     expect(message).not.toContain('undefined');
   });
 
+  test('the text ceiling leaves room for a real source file and stops short of the knee', () => {
+    // 32 MiB: measured, the last size before a tab's heap crosses a gigabyte and
+    // a 64 MB file stops opening at all (see the constant's own table).
+    expect(EDITOR_MAX_FILE_BYTES).toBe(32 * 1024 * 1024);
+    expect(EDITOR_MAX_FILE_BYTES).toBeGreaterThan(DOCUMENT_MAX_FILE_BYTES);
+  });
+
   // The sentence names the number the classifier actually applied: a PDF is
-  // refused against 30 MB, so telling the user "5.00 MB" would describe a limit
-  // the file was never measured against.
-  test('a PDF size refusal names the PDF ceiling', () => {
+  // refused against its own ceiling, so naming the text one would describe a
+  // limit the file was never measured against.
+  test('a PDF size refusal names the PDF ceiling, not the text one', () => {
     const message = unsupportedEditorMessage('too-large', 31 * 1024 * 1024, 'docs/report.pdf');
     expect(message).toContain('31.00 MB');
-    expect(message).toContain('30.00 MB');
-    expect(message).not.toContain('5.00 MB');
+    expect(message).toContain(formatBytes(PDF_MAX_FILE_BYTES));
+    expect(message).not.toContain(formatBytes(EDITOR_MAX_FILE_BYTES));
   });
 });

package/src/shared/lib/fs/file-kind.ts

@@ -143,16 +143,43 @@ export function getImageMimeFromBytes(bytes: Uint8Array): string | null {
 }
 
 /**
- * The largest file the editor will open when its bytes reach the page WHOLE.
+ * The largest text file the editor will open when its bytes reach the page
+ * WHOLE.
  *
- * Not a policy knob: the editor holds the whole file in one string and posts
- * the whole thing back on every save, so a ceiling has to exist. 5 MiB is above
- * any source file and well below the size at which a textarea stops responding.
+ * Not a policy knob: the editor holds the whole file in one string, CodeMirror
+ * holds a second representation of it, and the whole thing is posted back on
+ * every save — so a ceiling has to exist.
  *
- * A DOCX and an XLSX are parsed in the page too, but they get their own, higher
- * number — see `DOCUMENT_MAX_FILE_BYTES`.
+ * **32 MiB, measured.** The number used to be 5 MiB, and its justification died
+ * with the `<textarea>`: that limit existed because a textarea stops responding,
+ * and the surface is CodeMirror 6 now. Re-measured on the assembled app (a
+ * generated source file, Files panel open, Chromium):
+ *
+ * | File | Open | Keystroke | Save | JS heap |
+ * |---|---|---|---|---|
+ * | 5 MB | 99 ms | 17 ms | 289 ms | 73 MB |
+ * | 10 MB | 147 ms | 32 ms | 494 ms | 73 MB |
+ * | 20 MB | 212 ms | 34 ms | 969 ms | 73 MB |
+ * | 30 MB | 323 ms | 39 ms | 2 292 ms | — |
+ * | 40 MB | 283 ms | 45 ms | 1 793 ms | — |
+ * | 50 MB | 372 ms | 72 ms | 2 228 ms | **1 078 MB** |
+ * | 64 MB | never finished loading | — | — | — |
+ *
+ * The curve is flat through 40 MB and breaks at 50: the heap goes from a few
+ * hundred megabytes to over a gigabyte for ONE tab, and a 64 MB file does not
+ * open at all. 32 MiB is the last size with a comfortable margin below that
+ * knee — ten times any source file, and the point past which a tab is a risk to
+ * every other tab in the browser rather than a convenience.
+ *
+ * Two costs had to be removed before this number was reachable, and both were
+ * linear-in-file-size work paid per keystroke: the outline's scan-and-render of
+ * every declaration (`outline/rows.ts`), and a full `doc.toString()` on every
+ * render (`code-surface/index.tsx`).
+ *
+ * A DOCX and an XLSX are parsed in the page too, but they get their own number —
+ * see `DOCUMENT_MAX_FILE_BYTES`.
  */
-export const EDITOR_MAX_FILE_BYTES = 5 * 1024 * 1024;
+export const EDITOR_MAX_FILE_BYTES = 32 * 1024 * 1024;
 
 /**
  * The largest Word document or workbook the editor opens.
@@ -160,9 +187,10 @@ export const EDITOR_MAX_FILE_BYTES = 5 * 1024 * 1024;
  * `mammoth` and `read-excel-file` parse the fetched `ArrayBuffer` in the page,
  * so the file does sit in memory — but it is unzipped and converted once and
  * then released, where a text buffer is held for as long as the tab is open and
- * re-posted on every save. That is why these get four times the text ceiling
- * rather than the text ceiling itself: the reason the 5 MiB limit exists (a
- * textarea that stops responding) does not apply to a read-only conversion.
+ * re-posted on every save. That is why these get a ceiling of their own rather
+ * than the text one: the reason the text limit exists (a buffer that must stay
+ * editable, and a save that re-posts it) does not apply to a read-only
+ * conversion.
  *
  * Measured on a 15 MB workbook: the fetch, the unzip and the grid render all
  * complete, and the panel stays responsive.
@@ -170,8 +198,13 @@ export const EDITOR_MAX_FILE_BYTES = 5 * 1024 * 1024;
 export const DOCUMENT_MAX_FILE_BYTES = 20 * 1024 * 1024;
 
 /**
- * The largest PDF the editor opens — above both, because a PDF is the one
- * document the page never holds.
+ * The largest PDF the editor opens.
+ *
+ * Its own number rather than the text ceiling, because a PDF is the one document
+ * the page never holds — and the only one whose limit is not about a buffer at
+ * all (see below). It is no longer the largest of the three: the TEXT ceiling
+ * moved past it, which is fine because the two numbers answer different
+ * questions rather than ranking a shared budget.
  *
  * `PdfView` points an `<iframe>` at `/api/fs/raw`, so the bytes go straight to
  * Chrome's own viewer, which fetches them with range requests (verified: a
@@ -180,7 +213,8 @@ export const DOCUMENT_MAX_FILE_BYTES = 20 * 1024 * 1024;
  * Nothing in Kabmo buffers the file, so the text ceiling has no reason to
  * apply to it — and applying it was the bug: a 6 MB PDF dragged from Finder was
  * refused as "larger than the 5.00 MB the editor opens" before the document
- * branch was ever reached, because the size test runs first.
+ * branch was ever reached, because the size test runs first. The 30 MB here is
+ * Chrome's own plugin's comfort zone, not Kabmo's memory.
  */
 export const PDF_MAX_FILE_BYTES = 30 * 1024 * 1024;