GitHub Community
Problem with GitHub's Markdown Rendering Library #22685
-
|
I’ve stumbled upon a problem with GitHub’s markdown renderer for repositories’ previews. Since the GitHub preview library hosts multiple rendering packages for the various supported syntaxes I’m not quite sure where I should report this — i.e. which is the repository of the GFM rendering tool, or whether this is issue should instead be reported to GitHub Flavored specification project. Problem DescriptionYesterday, after pushing a commit on
The missing space did not only affect that specific reference link — which was rendered raw in the preview: Also, the local previewer of my editor rendered the document without problems, which further made it hard for me to spot the problem. Expected BehaviourAlthough the separating space in that context is good practice, and omitting it is bad syntax, I believe that GitHub’s markdown renderer shouldn’t break like it did — especially since that single label affected the rendering of all others. Most markdown previewers are able to parse and render that document without problems, and when you come to think about it the context isn’t ambiguous since the double quotes character can’t possibly be part of a URL, and the parser should be able to detect that a Help RequestI would like to submit an Issue for this, asking to make the markdown previewer library more fault-tolerant for this typo. Where should I submit an issue? In the GFM specification repo? or is there a specific rendering tool repository? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
|
The github/markup project is the place to start whenever you’re looking at how we render markup files in a repository. Given that you’re asking about Markdown, you can see that gjtorikian/commonmarker is used to perform the actual rendering, which is a wrapper for github/cmark-gfm and itself is a fork of commonmark/cmark. If I was in your shoes, I suspect the most helpful thing would be to determine if it is a bug in the GitHub-specific Markdown rendering (in other words, in github/cmark-gfm) or if it exists in the underlying commonmark/cmark library. Once I made that determination, I would file the appropriate issue with my findings, how I tested to make the determination, etc in either github/cmark-gfm or commonmark/cmark. I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
|
lee-dohm:
Indeed, it’s exactly the disentanglement of repository dependencies I was looking for. |
Beta Was this translation helpful? Give feedback.
The github/markup project is the place to start whenever you’re looking at how we render markup files in a repository. Given that you’re asking about Markdown, you can see that gjtorikian/commonmarker is used to perform the actual rendering, which is a wrapper for github/cmark-gfm and itself is a fork of commonmark/cmark. If I was in your shoes, I suspect the most helpful thing would be to determine if it is a bug in the GitHub-specific Markdown rendering (in other words, in github/cmark-gfm) or if it exists in the underlying commonmark/cmark library. Once I made that determination, I would file the appropriate issue with my findings, how I tested to make the determination, etc in either …