Relative links pointing to internal content don't have their extensions rewritten when they contain a fragment

[ichard26]

Describe the bug

Relative links pointing to internal content that contain a fragment don't have their file extension rewritten.

In other words, [some link](file_two.md#super-duper-important-heading) isn't rewritten (in MD equivalent) to [some link](file_two.html#super-duper-important-heading).

It works as expected without the fragment.

I also want to mention this is my first bug report for MyST-Parser. I'm also quite new to MyST-Parser so there's a non-trivial chance I'm missing something really obvious, which in that case, consider this an user support issue. You have my apologies in advance. I did see this issue: #243 but I couldn't find anything to fix my issue.

To Reproduce

Steps to reproduce the behavior:

1. Download this zip file: myst-bug-maybe.zip and unzip it

2. Setup a Python environment and run pip install -r requirements.txt

3. Build the docs (make html and if you're on Windows, I'm sorry, I deleted the make.bat file by accident before making the zip)

4. Take a look at the built docs and visit on the Main file page

Expected behavior

That all three links in file_one.md would work.

Environment

• Python Version: Python 3.8.5
• Package versions:

pip freeze output

alabaster==0.7.12
attrs==20.3.0
Babel==2.9.1
certifi==2020.12.5
chardet==4.0.0
docutils==0.16
idna==2.10
imagesize==1.2.0
Jinja2==2.11.3
markdown-it-py==0.6.2
MarkupSafe==1.1.1
mdit-py-plugins==0.2.6
myst-parser==0.13.7
packaging==20.9
Pygments==2.8.1
pyparsing==2.4.7
pytz==2021.1
PyYAML==5.4.1
requests==2.25.1
snowballstemmer==2.1.0
Sphinx==3.5.4
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4
urllib3==1.26.4

• Operating System: Ubuntu 20.04.01 LTS

Oh and one more thing:

Thank you so much for y'all's work on MyST-Parser! I've been working on rewriting psf/black's documentation and using MyST-Parser has been really nice (well other than the fact I can't use any optional syntax since mdformat doesn't support them yet)

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[chrisjsewell]

hey yeh no problem, I use black all the time so "giving back" would be great lol!

Have you seen/activated e.g. myst_heading_anchors = 2: https://myst-parser.readthedocs.io/en/latest/using/syntax-optional.html#auto-generated-header-anchors?

well other than the fact I can't use any optional syntax since mdformat doesn't support them yet

well I'm sure @hukkinj1 would be glad to aide you in this, if you haven't already mentioned it yet over in that repo, since he has recently created https://github.com/hukkinj1/mdformat-myst 😄

[ichard26]

FYI, I've been talking to @ hukkinj1 a lot already so they know of my complaints already lol. Also mdformat-myst doesn't support colon_fence for example, that's the kind of "lack of support" I was talking about

I did actually try myst_heading_anchors but it looks like I misconfigured it since it didn't work... whoops :p

It works perfectly now, except for one link, although I don't expect it to be fixed.

future_style.md

[Backslashes are bad and should be never be used](current_style.html#why-no-backslashes)

current_style.md

<p id="why-no-backslashes">
  <em>Black</em> prefers parentheses over backslashes, and will remove backslashes if found.
</p>

Now clearly that isn't a header and given that I'm using literal raw HTML, it makes sense that it "breaks". I say "breaks" because the link works just fine but MyST-Parser likes to emit a nice warning about it.

/black/docs/the_black_code_style/future_style.md:13: WARNING: 'myst' reference target not found: current_style.html#why-no-backslashes

Which is a slight issue since we try to enforce zero-warning builds for our documentation.

---

What's funny is that I like to rant about Black's users not reading the documentation but here am I not reading the documentation properly and opening an unnecessary issue 🙃 🤣 . Thanks anyway, I'll close this since there's nothing actionable for MyST-Parser.

[hukkin]

Regarding the (slightly off-topic 😄 ) mdformat-myst optional syntax support I've made an issue that @ichard26 might be interested having a look at.

EDIT: .... and here's the link that dumb me forgot to add 🤦

[ichard26]

Which is a slight issue since we try to enforce zero-warning builds for our documentation.

BTW don't worry about this, I fixed this by reading the documentation and using https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing

Honestly I've been used to the small basic world of recommonmark, GitHub flavored markdown, plus Sphinx (barely any reST, just toctree and that's like it) that all of these new but very nice additions are a bit overwhelming :D

[chrisjsewell]

all of these new but very nice additions are a bit overwhelming

well they are all optional, you can always just use myst_commonmark_only 😉
but no any feedback on improvements to the documentation for new users is always welcome 😄