The editor shows what the file says

[tosinamuda]

Two rendering defects, found from one screenshot of a table cell.

The LaTeX was valid — the cell never looked

$440 = 2 \times \frac{22}{7} \times r$ typesets in body text and showed as source in a table cell.

Cells render by walking the Lezer tree. Four of the editor's constructs have no node in that tree — wikilink, ==highlight==, footnote reference and $math$ are not CommonMark, so the editor finds each by scanning text. The walk was blind to all four, and two came out worse than untouched, because the parser's own reading of their brackets is wrong:

source	body	cell (before)
$x^2$	x²	$x^2$
[[Some Note]]	Some Note	[Some Note] — inner brackets eaten, styled a link
==marked==	marked	==marked==
text[^1]	text¹	text^1 — styled a link

inlineScan.ts is the seam that was missing: a feature contributes its pattern and its markup, and the cell renderer consults the facet knowing nothing about the constructs — the same shape as nodeRulesFacet, which the tree-parsed constructs already use. The decoration plugins keep their own viewport path; the two share the pattern, not the machinery.

Math is the only rule that hydrates, and that is deliberate. KaTeX builds DOM, and its markup carries inline styles the cell's sanitiser allow-list drops on purpose — so the render pass emits the TeX as inert text, and KaTeX replaces it after sanitisation from the element's own textContent. The allow-list stays exactly as tight as it is for prose.

[…] was losing its brackets everywhere

Chasing the same screenshot's TikZ block turned up something wider. Lezer emits a Link node for every bracketed span; CommonMark makes [label] a link only when the document also carries a [label]: url definition, and the parser leaves that lookup to its consumer. The registry read "there is a Link node" as "this is a link":

the value arr[0] is wrong         →  the value arr0 is wrong
see footnote [3]                  →  see footnote 3
\begin{tikzpicture}[scale=0.42]   →  \begin{tikzpicture}scale=0.42
\draw (0,0) arc[radius=0.7];      →  \draw (0,0) arcradius=0.7;

The bytes were fine. Only the rendering lied — the worse failure, because nothing looks broken enough to report, and a reader copying what they see gets LaTeX that no longer compiles.

linkResolution.ts does the lookup the parser skipped. Unresolved, the brackets are content: visible, unstyled, and no longer atomic to the caret.

This is an export-parity fix, verified against the export's own parser rather than assumed:

comrak "the value arr[0] is wrong"   →  <p>the value arr[0] is wrong</p>
comrak "see [ref] now"               →  <p>see [ref] now</p>
comrak + a [ref]: definition         →  <p>see <a href="…">ref</a> now</p>

The editor was the only renderer in the app getting this wrong.

Verification

709 jsdom tests and 174 real-WebKit tests green.

The KaTeX assertion is browser-tier on purpose, and the first version of it was wrong in an instructive way: .katex is an inline span, so its own rect reads identically for a fraction and for a single letter. The cell's height is what moves — 26.8px with a fraction, 25.4px flat math, 20.2px prose. Unstyled KaTeX renders shorter than prose, so measuring the cell is what catches a stripped stylesheet; measuring .katex catches nothing.

Cost

Measured, on a 91k document with a bracket, math, a wikilink and a table on every line:

	p50 keystroke
main	9.87 ms
+ bracket fix	11.62 ms
+ cell rendering	12.19 ms

The definition index is 0.51 ms of that (1602 block nodes — it descends only into block containers, since a definition is a block construct). Forcing the whole-document parse costs 0.03 ms, because parseToEnd has already covered it.

Baseline was already over #70's 8ms budget on this document, which is adversarial by construction; the budget is advisory today.

Also fixed: two doc defects shipped in @latentic/live-markdown@0.0.1

styles.css still called the package ai-editor, and both it and the README promised math needs no CSS import. It does — KaTeX renders through its own stylesheet, which no CodeMirror theme can supply. Compose imports it in App.tsx; a reader following the README would not have, and would have got math that silently stops stacking.

Not fixed: TikZ

Still unsupported, and this PR does not change that — KaTeX has no TikZ, and nothing else in the pipeline draws one. What changes is that a pasted TikZ block now reads back exactly as written instead of quietly losing every […]. A fenced block was always safe and still is.

[tosinamuda]

Superseded by #183 — not abandoned. Both commits are released and reach Compose through the registry instead.

The editor left this repository for getlatentic/live-markdown while this was open, and these two commits touched nothing outside packages/rich-editor, so they came across with the git subtree split and shipped in @latentic/live-markdown@0.1.0. #183 points Compose at ^0.1.1 and deletes the directory.

Everything reviewed here still stands:

• a […] keeps its brackets until it resolves to a link — arr[0] no longer renders as arr0, and a pasted LaTeX block keeps every optional argument
• a table cell renders what the paragraph above it renders — math, wikilinks, highlights and footnote refs were all invisible to the cell renderer, and two of them actively mangled

Verified in #183 against the published tarball rather than a workspace symlink, which is a stronger check than this PR could make: under the old arrangement Compose resolved the package to its TypeScript source and never exercised what npm ships.

One correction worth recording. Merging this was going to be gated on a live pass in the packaged app, per the standing rule that headless green is a test bar and not a merge bar. That verification is still owed — it moves to #183, where the app is built against the real package.