-
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
Hashtags in the beginning are rendered as headings #201
Comments
That's the expected behaviour, because the Work around by using Also note that a single |
@Mithgol according to Markdown documentation there needs to be a space character after the Edit: for the example I was using GFM's newline support so it renders to paragraphs |
So I think the correct regular expression should be
Here's an example render with GitHub's Markdown. Source:
Result: #header header1header1 |
Good argument. I am convinced. |
I'd like to see this merged, +1 |
$ echo '#foo' | markdown.pl
<h1>foo</h1> Not sure this qualifies as a fix. It violates markdown.pl behavior. |
Ah well if markdown.pl behaves that way I'd just leave it. You can always escape it anyway |
Being backwards compatible with However, it seems like the GFM mode could imitate GitHub flavoured Markdown better if it took the whitespace in consideration after the |
+1 for GFM Jori Lallo +1 (415) 728 5773 On Friday, August 2, 2013 at 12:05 PM, Mithgol wrote:
|
+1 for GFM |
@elennaro It's as easy as manually applying the patch jorilallo/marked@09c26a8. It replaces only one character in the source code ( |
Oh, thank you @Mithgol really simple and beautifull! |
+1 for GFM |
+1 GFM |
Fixed. |
I know it's been a while, but for the future reference I want to point out that this change should have never landed as a patch (0.3.2 -> 0.3.3), but at least as a minor (0.3.2 -> 0.4.0) because it's backward incompatible from customer's perspective, who don't care about whitespace because it's been allowed for a long time and now it breaks existing badly formatted markdowns. No complains whatsoever. Just suggestions 😉 |
Very unhappy at this change, it broke all our documentation by no longer rendering the headings correctly. Would love to see it reverted, as breaking existing docs just to be able to render hashtags without an escape character does not strike me as the right set of priorities. Thankfully most of our docs are parsed for conversion to HTML, and are still rendered correctly on our websites, but I have 100 or so pages that are not parsed this way and now need to be updated with the new heading style. |
How about Example: Text Text Text Text Text Text Text Text.
#tag1 #tag2 Now render as:
Expect:
|
That would be even more confusing than the current state of affairs. |
This commit enforces at least one whitespace after a hashtag to match a token as atx heading. see: markedjs/marked#201
* [Markdown] Fix ATX heading This commit enforces at least one whitespace after a hashtag to match a token as atx heading. see: markedjs/marked#201 * [Markdown] Fix atx header variable comment
This commit enforces at least one whitespace after a hashtag to match a token as atx heading. see: markedjs/marked#201
* [Markdown] Fix ATX heading This commit enforces at least one whitespace after a hashtag to match a token as atx heading. see: markedjs/marked#201 * [Markdown] Fix atx header variable comment
#hashtag# test |
I ran into a problem while testing hashtags:
renders as
while the expected output is
The text was updated successfully, but these errors were encountered: