🐛 FIX: parse front matter closed by the YAML ... marker

[feiiiiii5]

Summary

Front matter closed by the YAML ... document-end marker was not parsed correctly. Two distinct silent failures, both reproduced against main at 519953d:

>>> MarkdownIt().use(front_matter_plugin).render("---\ntitle: a\n...\n")
'<hr />\n<p>title: a\n...</p>\n'
>>> MarkdownIt().use(front_matter_plugin).render("---\ntitle: a\n---\n")
''

The two forms should be equivalent. Instead, when ... closed the block:

• the block was dropped entirely — no front_matter token was produced at all, and the front matter leaked into the rendered document as visible text (an <hr /> plus a paragraph). This happens when ... is the last line.
• the marker stayed in the token content — where it did parse, token.content was 'title: a\n...' instead of 'title: a', unlike the dashed form which excludes its terminator.

Root cause

mdit_py_plugins/front_matter/index.py, in the search loop:

while True:
    nextLine += 1
    if nextLine >= endLine:
        return False

    if state.src[start:maximum] == "...":   # tests the PREVIOUS line
        break

    start = state.bMarks[nextLine] + state.tShift[nextLine]   # moves onto the current line
    maximum = state.eMarks[nextLine]

start/maximum are only moved onto nextLine after the ... test, so the test inspects line nextLine - 1. The content slice further down is computed as state.src[state.bMarks[startLine + 1] : state.eMarks[nextLine - 1]], i.e. as if the closer were on nextLine. The check is exactly one line out of phase with the slice, which is why the two symptoms differ: at end-of-document the loop runs off the end and return False discards the block, while with a body after it the marker survives into content.

Fix

Move the test to after the per-line refresh, and set auto_closed so the line is consumed rather than re-parsed as content. auto_closed is read only at state.line = nextLine + (1 if auto_closed else 0).

    start = state.bMarks[nextLine] + state.tShift[nextLine]
    maximum = state.eMarks[nextLine]

    if state.src[start:maximum] == "...":
        auto_closed = True
        break

token.map for the dotted form becomes [0, 3], matching the dashed form.

Tests

tests/test_front_matter.py gains two tests, both red before the fix:

• test_token_content_excludes_the_closer, parametrized over --- and ..., asserting the token content is a: 1 in both cases.
• test_dots_closer_on_the_last_line, asserting the ...-at-EOF render equals the --- render (both empty).

The existing test_all cannot see either half of this: the front_matter token is hidden=True, so only md.render() is asserted, and a dropped block renders as visible text rather than failing. The dotted case was otherwise only covered by the should parse until triple dots fixture, which asserts rendered output and so never inspected content.

pytest tests -q    514 passed   (511 before, +3 new)
ruff check / ruff format --check    clean
mypy mdit_py_plugins/front_matter/index.py    Success

Relation to #155

#155 also edits this line, adding marker_chr == "-" to the same condition, but it leaves the check in the same position — so that branch does not have this bug fixed. The two changes compose: applying this fix on top of #155 moves the gated test onto the correct line. I have not rebased onto #155 because the conflict is a single line and the ordering is a maintainer decision; happy to rebase if you would rather land it after #155.

Separate observation, not changed here

The comment two lines above says "unclosed block should be autoclosed by end of document" while the code does return False, discarding the block. That contradiction predates this PR and changing it would alter behaviour for genuinely unclosed input, so I have left it alone.

[feiiiiii5]

Hi — picking this back up. Head is 107d69c7, unchanged since I opened it.

Recap: front matter closed by the YAML ... document-end marker fails two different ways on main at 519953d — when ... is the last line the block is dropped entirely and the front matter leaks into the rendered document as <hr /> plus a paragraph; where it does parse, token.content keeps the marker ('title: a\n...') instead of excluding it the way the dashed form does.

The repo's own workflows on this PR look like they haven't run (third-party pre-commit.ci and readthedocs show success, but nothing from .github/workflows). Could you trigger them, or approve the run if it needs write access?

One thing worth settling early: this is a one-line judgement in front_matter/index.py's search loop — treat ... as a terminator. If you'd rather the plugin keep ignoring ... entirely and only the dashed form be supported, I'd rather know now and close this than push a semantics change you don't want.