Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Footnote appears in all following objects after the first appearance #186

Closed
anthonyhtyao opened this issue Dec 4, 2020 · 6 comments · Fixed by #195 or #199
Closed

Footnote appears in all following objects after the first appearance #186

anthonyhtyao opened this issue Dec 4, 2020 · 6 comments · Fixed by #195 or #199
Labels
bug Something isn't working templates Jinja templates

Comments

@anthonyhtyao
Copy link

Hi, I'm not sure this is related to pytkdocs or mkdocstrings.

Describe the bug
If a footnote is added to one of python objects, the footnote will appear in every object after that one in the same documentation page.

To Reproduce
Here is an example to reproduce

# example.py
def C():
    """This is C
    """
    pass

def B():
    """This is B[^1]

    [^1]: This is footnote
    """
    pass

def A():
    """This is A
    """
    pass
# mkdocs.yml
site_name: Footnote
theme:
  name: "material"
plugins:
  - search
  - mkdocstrings:
      default_handler: python
markdown_extensions:
  - footnotes

Expected behavior
The footnote is supposed to appear only under function B

Screenshots
However, footnote appears under function B and C


Screenshot from 2020-12-05 00-30-54

@anthonyhtyao anthonyhtyao added the unconfirmed This bug was not reproduced yet label Dec 4, 2020
@pawamoy
Copy link
Member

pawamoy commented Dec 8, 2020

Hi @anthonyhtyao, thank you for the bug report 🙂

I'll mark this as confirmed, your screenshot is enough evidence. As for the bug in itself, I guess it's because we re-use the same Markdown instance to convert multiple docstrings, and the foot notes must be stored somewhere in this instance. The solution would then be to clear the foot notes from the instance before converting other docstrings.

@pawamoy pawamoy added bug Something isn't working handler:python templates Jinja templates and removed unconfirmed This bug was not reproduced yet labels Dec 8, 2020
@oprypin
Copy link
Member

oprypin commented Dec 11, 2020

This issue is actually more complex than this, because, even if you reset the list of footnotes, their reference IDs will still be shared. If you happen to put two different functions that both have a footnote named [^1] (not related though), the page will be generated with both of them having the id #fn:1

oprypin added a commit to oprypin/mkdocstrings that referenced this issue Dec 12, 2020
oprypin added a commit to oprypin/mkdocstrings that referenced this issue Dec 12, 2020
oprypin added a commit to oprypin/mkdocstrings that referenced this issue Dec 12, 2020
oprypin added a commit to oprypin/mkdocstrings that referenced this issue Dec 12, 2020
pawamoy pushed a commit to oprypin/mkdocstrings that referenced this issue Dec 16, 2020
@pawamoy
Copy link
Member

pawamoy commented Dec 21, 2020

Hey @anthonyhtyao, so this has been partially fixed by @oprypin (thanks ❤️), partially because you'll still need to use different IDs for footnotes in docstrings that will be rendered in the same Markdown page. I'll link to the docs section once it's deployed.

@oprypin
Copy link
Member

oprypin commented Dec 22, 2020

I sent out a complete fix - "once and for all", as I say. #199

@pawamoy
Copy link
Member

pawamoy commented Dec 31, 2020

0.14.0b1 is out! Try it out and tell us if it works better 🙂

@anthonyhtyao
Copy link
Author

It works.
Thanks a lot for improving this

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working templates Jinja templates
Projects
None yet
3 participants