I found a regression in the footnote pass: it runs before/after Markdown parsing at document scope, so footnote-like text inside code can be removed or rewritten.

Could you add regression coverage for these cases before merge?

def test_footnote_definition_inside_fenced_code_stays_code():
    post = make_post()
    post.from_markdown("```\n[^1]: not a footnote\n```")
    content = body_content(post)
    assert len(content) == 1
    assert content[0]["type"] == "codeBlock"
    assert content[0]["content"][0]["text"] == "[^1]: not a footnote"


def test_footnote_reference_inside_fenced_code_stays_text():
    post = make_post()
    post.from_markdown("```\ncode [^1]\n```\n\n[^1]: note")
    content = body_content(post)
    assert content[0]["type"] == "codeBlock"
    assert content[0]["content"][0]["text"] == "code [^1]"


def test_footnote_reference_inside_inline_code_stays_text():
    post = make_post()
    post.from_markdown("`code [^1]`\n\n[^1]: note")
    content = body_content(post)
    assert content[0]["type"] == "paragraph"
    assert content[0]["content"][0]["text"] == "code [^1]"
    assert content[0]["content"][0]["marks"] == [{"type": "code"}]

The first test currently fails on this branch with content[0]["type"] == "footnote" instead of codeBlock. The fix should keep footnote extraction out of fenced code blocks and skip injecting anchors into inline code-marked text nodes.

Good catch, thanks. Fixed in 698e098:

• Footnote definition extraction now tracks fenced code blocks and skips them, so a [^1]: ... line inside ... stays in the code block.
• Anchor injection now skips codeBlock nodes entirely and any text node carrying an inline code mark, so [^1] references inside code are left as literal text.

All three regression tests you provided are included and pass (full post suite green: 66 passed).

Heads-up: as footnote handling has grown here (fenced/inline-code edge cases, multi-paragraph definitions), this is starting to feel a bit complex, like we're edging toward re-implementing a Markdown parser.

So I prototyped an alternative approach in #61 that uses markdown-it-py (a well-established CommonMark parser) plus its footnote plugin. It ends up significantly simpler: from_markdown() shrinks dramatically and footnote handling largely comes for free from the plugin. It does add two dependencies and makes a couple of (CommonMark-correct) behaviour changes, which I've described there.

Wasn't planned up front, so purely for your consideration, but it might be worth merging #61 instead of this one and getting the footnote handling for free.