Repository navigation
✨ NEW: Support configurable front matter markers - #155
Gonghan-Princess wants to merge 14 commits into
Conversation
The `...` document-end marker was tested against the *previous* line,
because `start`/`maximum` are only moved onto the current line after the
test. Two things followed, both silent:
A block whose last line was `...` was dropped entirely, so the front
matter leaked into the document as visible text:
MarkdownIt().use(front_matter_plugin).render("---\ntitle: a\n...\n")
before '<hr />\n<p>title: a\n...</p>\n'
after ''
And where it did parse, the marker stayed in the token content, so
`content` was `'title: a\n...'` rather than `'title: a'`, unlike the
dashed form.
Move the test to after the per-line refresh and mark the line consumed.
`auto_closed` is only read at `state.line = nextLine + (1 if
auto_closed else 0)`, so setting it is what stops the marker being
re-parsed as content.
`test_all` could not catch either half: the front_matter token is
hidden, so only the rendered output is asserted, and a dropped block
renders as visible text rather than failing. The new tests assert the
token itself.
pytest tests -q 514 passed
… allowed YAML's document-end marker is column-0 only, so an indented `...` (for example inside a block scalar) no longer closes the front matter. Trailing spaces after it are accepted, as they already are after the `---` closer.
…-front-matter-markers Brings in master and the `...` closer fix from executablebooks#158. The one conflict is the `...` check: it now runs on the current line (from executablebooks#158), is column-0 with trailing spaces allowed, and keeps this branch's `marker_chr == "-"` gate, so `...` stays content for other markers.
Say that the plugin takes one marker per parser (a second `use` adds a second rule under the same name), and that the marker should not be a character that starts other block syntax, since a first line of three or more of it is taken as front matter.
…) into codex/feat-front-matter-markers
Two fixtures pin the tail check on the closer: `....` and `...x` are content, so the block runs on to the following `---`.
…x/feat-front-matter-markers
A first line of three or more of the marker is taken as front matter only when a later line closes it; an unclosed block parses as ordinary Markdown.
|
Thanks @Gonghan-Princess, this is a clean, well-tested addition, and thank you for your patience. I pushed a few commits on top (a merge of #158's The reason is the API shape rather than the code. With If you'd like to rework it along those lines, that would be very welcome. I'm leaving this PR open, and #134 with it. |
Front matter delimiters are currently fixed to
---, preventing applications from using+++for TOML-style metadata or;;;for JSON-style metadata. Add a keyword-onlymarkeroption tofront_matter_plugin, configured separately for each MarkdownIt parser.For example,
MarkdownIt().use(front_matter_plugin, marker="+")extracts content between+++fences. The plugin continues to return raw metadata text; it does not decode TOML or JSON or add dependencies. The default-marker and existing YAML fixtures retain their behavior. Custom markers use the existing minimum-three and matching-closing-length rules; YAML's...terminator is recognized only with the default marker.Reject empty, multi-character, whitespace, and NUL markers when configuring the plugin. Update the API documentation with an example and add an Unreleased changelog entry.
Fixes #134.
Validation on Windows / Python 3.12.10:
tox -e py312: 535 passed (24 added cases).tox -e mypy,tox -e pre-commit, andtox -e docs-update: passed, including strict Sphinx-nW --keep-going.AI assistance: OpenAI Codex prepared the implementation, tests, documentation, and PR text. A separate Codex agent reviewed the patch; its NUL-marker finding was addressed and tested. No human review is claimed.