-
Notifications
You must be signed in to change notification settings - Fork 15
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
underscore is kept in links #9
Comments
Thanks for the report! Well, i'm pretty sure, there is something wrong with the ones below. Since markdown treats asterisks (*) and underscores (_) as indicators of emphasis. Text wrapped with one * or _ will be wrapped with an HTML . Github markdown spec is based on CommonMark spec, as markdown engine, In their specification page (which is written in markdown). This is the link for fragments: https://github.github.com/gfm/#example-509, they also use hyphens instead of underscore. |
From reading your answer I think there is a misunderstanding in my first report. Generally GitHub uses the Interestingly both cmark and cmark-gfm (both installed from the Arch User Repository) dont generate id tags for the headings. md4c also does not generate id tags. discount does when provided with This is both the case with But you are right, using _ in Markdown is probably ending up in strange behaviour anyway. |
Hey again! Does using underscore's instead of hyphens has any visual differences in the end HTML ? If there is, I can add a flag for using underscores instead of hyphens. |
I think the main question ends at the question which markdown to html implementation are you targeting? As these different implementations have different h-tag id implementations they differ quite a lot. I have not found the exactly same implementation which github uses for the readmes and everything seems to differ at something. As generating a toc is directly depending on that… thats quite annoying. |
Used this and found a small bug only relevant to headings containing
_
.This is the current output:
These are the ones github uses for its links:
Or is there another standard which GitHub does not comply to?
The text was updated successfully, but these errors were encountered: