Repository navigation
✨ NEW: Support configurable front matter markers - #155
Open
Gonghan-Princess wants to merge 14 commits into
Open
Gonghan-Princess wants to merge 14 commits into
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.