Task 3 of #5446. Stacked on #5450 (Task 2) — review that one first; this branch targets it, and I will rebase onto develop once it merges.

isGitlabCompatibilityEnabled was one third of an extension

The preference was named for a vendor and filed under Compatibility, but it did exactly one thing: promote a ```math fence to a math block. That is the display half of tex_math_gfm — GitHub's syntax as much as GitLab's — and the inline half was missing entirely.

Missing, and worse than missing: $`e=mc^2`$ was silently mis-rendered. The dollar rule claimed the span and handed the backticks to KaTeX as part of the formula:

src    = $`e=mc^2`$
tokens = [{ "type": "inline_math", "marker": "$", "content": "`e=mc^2`" }]
render = ‘e=mc2‘        ← stray backtick glyphs at both ends

katex-error was false — nothing reported a problem, it just came out wrong, in the editor and in the export alike. Any document copied from GitHub broke this way.

Now

One preference, texMathGfm, covering both forms, under Preferences → Markdown → Extensions with the other pandoc-named toggles. Default off, as in pandoc, where only tex_math_dollars ships enabled.

The old key is dropped rather than migrated. electron-store keys migrations to app versions, so a prerelease tester who has already run a 0.20.0 build could never receive one — their stored version is already at or past any key we could write. Before 1.0.0 the cheaper trade is to let the setting go: the preference loader already deletes keys that leave static/preference.json, so nothing errors, and anyone who had GitLab compatibility on turns the new toggle on once.

Notes on the implementation

Marker asymmetry. $`…`$ opens and closes with mirror images rather than one repeated marker. Both are two characters wide, so everything downstream that does arithmetic off marker.length — caret offsets, the Tab-past-the-closer hit test, the three render slices and the preview's data-start/data-end — still lands correctly. The one place that genuinely needed the closer is the clipboard renderer, which reassembled marker + text + marker and would have written $`e=mc^2$` ; it now carries an explicit close marker, and there is a test for exactly that round trip.

Rule precedence. Both math forms open on $, and the dollar rule would swallow the gfm span whole. In the editor the gfm rule goes ahead of it in the chunk list; on the marked side the extension is registered after the dollar one, because Marked.use unshifts, so the later registration is tried first. marked runs extensions ahead of its built-in codespan, so inline code never gets a chance to claim it either.

With the extension off, the span keeps its current reading. That is pandoc's behaviour — tex_math_dollars alone does treat $`…`$ as dollar math whose content happens to contain backticks — so Gap 2 in the issue is fixed by opting in, not by default. Deliberate, and pinned by a test so it cannot drift silently.

Only the single-backtick form is supported ($`…`$), which is what GitHub documents. Multi-backtick $…$ is not.

Behaviour changes worth calling out

That last row changes the default for a standalone @muyajs/core consumer. MarkText already defaulted it off, so this closes a standing disagreement between the two packages rather than opening one.

Commits

1. refactor(muya) — rename the option, flip the default.
2. refactor(muya) — mathStyle: 'gitlab' → 'gfm'.
3. feat(muya) — the inline form, in both tokenizers, plus texMathGfmInline.spec.ts.
4. feat(muya) — ```math rides texMathGfm alone.
5. feat(desktop) — the preference swap.
6. docs — the PREFERENCES.md row.

Verification

muya 252 files / 1880 tests, CommonMark 0.31 + GFM 0.29 conformance 1347, desktop unit 820 (locale parity included), lint, typecheck, check-circular, and the muya Playwright math suite (70 passed).

🤖 Generated with Claude Code