dialects: Markdown Dialect Plugins (markdown-it rules + mdformat renderers)

Each module here implements the mdformat parser-extension interface for one flavor of Markdown: it installs that dialect’s rules onto a MarkdownIt engine through update_mdit(), and exposes the RENDERERS/POSTPROCESSORS registries mdformat consults on the way back out. Built-in flavors self-register by name when their myform reader or writer is first used; they need not be published as distribution entry points. Obsidian use refuses a global name already owned by a different module, because foreign token semantics cannot safely share myform’s built-in writer contract.

A dialect is deliberately a token-layer artifact. It never imports myform.model, so the typed myform.model.Doc tree is bridged from the tokens a dialect produces rather than by it. A bare MarkdownIt engine can call its module directly; bare mdformat discovers only published entry points, and myform does not promise that separate CLI surface for self-registered flavors.

Markdown Dialect Plugins (markdown-it rules + mdformat renderers).

Each module here implements the mdformat parser-extension interface for one flavor of Markdown: it installs that dialect’s rules onto a MarkdownIt engine through update_mdit(), and exposes the RENDERERS/POSTPROCESSORS registries mdformat consults on the way back out. Built-in flavors self-register by name when their myform reader or writer is first used; they need not be published as distribution entry points. Obsidian use refuses a global name already owned by a different module, because foreign token semantics cannot safely share myform’s built-in writer contract.

A dialect is deliberately a token-layer artifact. It never imports myform.model, so the typed myform.model.Doc tree is bridged from the tokens a dialect produces rather than by it. A bare MarkdownIt engine can call its module directly; bare mdformat discovers only published entry points, and myform does not promise that separate CLI surface for self-registered flavors.