-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
GitHub Wiki Not Parsing Correctly GFM Inline Code #1115
Comments
Your input is totally fine — there's a bug in our Wiki rendering code specifically triggering this. Thanks for the report; I'm looking into it, and will let you know when the fix will be available. |
Ohhh, this is a mess; it's being interpreted as a wiki-style link, per https://help.github.com/articles/adding-links-to-wikis/#using-a-wiki-markup-syntax-to-make-links. |
Thanks again for this report! I've put a fix together and it's pending review. Will update when it's live. |
I forgot that Wiki pages support also WikiMedia styled links (I don't use often, even if they are very cool because they show in red broken links, it's just that my markdown editor doesn't have handy shortcuts for them). Thanks for your support — and good luck with it (I guess that handling RegExs to catch nested brackets edge-cases is going to be a living nightmare). |
Honestly, I had no idea they were until researching your bug report! This codebase is huge. I was definitely thinking of the nightmare route of trying to make the regex not catch this somehow, but thankfully there's a better solution—processing these wiki-style links in Markdown only after the Markdown processing itself is done, and doing it text node by text node. This should cover all the edge cases nice and cleanly; just waiting on a review. :) |
Fix for this is now live — thank you very much for your report! ❤️ |
Thanks to you for all the kind support and the great tools you develop and share with the community! |
I hope this is the right place to submit this issue.
In a Wiki page I wrote for a repo, I stumbled on a buggy behaviour of GitHub's markdown parser:
Two opening square brackets withing backticks (partial text context: "
(ie: `[[`)
") produced an inline code that carries on beyond the closing backtick. As can be seen here (previous commit):https://github.com/tajmone/highlight/wiki/Lua-Basics/6761bce2ac7d2978a58c32f739abcb0203b7a1b7#which-type-of-string-should-i-use
I couldn't find a fix (even doubling the backticks didn't work), so I had to add the closing brackets as well — I noticed that a previous inline-code which contained also two closing brackets didn't produce the parsing bug. Also, you'll notice that the problem doesn't show up when the two square brackets are separated by the equal sign; and that the buggy inline code carries on until it finds a pair of closing brackets within backticks!
Somehow the parser is not handling properly the sequence of two opening square brackets. It's as if these two opening brackets are being matched with the two closing brackets, instead of being treated as raw strings contents.
The text was updated successfully, but these errors were encountered: