Skip to content
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

Headings are no longer working since 0.3.4 #642

Closed
ascholz81 opened this issue Aug 11, 2015 · 7 comments
Closed

Headings are no longer working since 0.3.4 #642

ascholz81 opened this issue Aug 11, 2015 · 7 comments

Comments

@ascholz81
Copy link

The headings function is creating headings correctly.

v0.3.3
"##My Heading"

v0.3.4 and up
"## My Heading"

@chjj
Copy link
Member

chjj commented Aug 12, 2015

I can't remember the exact issue, but someone made a PR requiring GFM to require a space after. I revised the code a bit (maybe it caused a mixup?). So, original markdown still allows no space after the hash, but GFM requires one.

I can't for the life of me remember the specifics, but if it's wrong, here's a temporary fix you can use:

marked.Lexer.rules.gfm.heading = marked.Lexer.rules.normal.heading;
marked.Lexer.rules.tables.heading = marked.Lexer.rules.normal.heading;
marked('##foo');

This is a simple 1-character fix in the heading rule if it's wrong:

##Testing Heading

Test paragraph.

@chjj
Copy link
Member

chjj commented Aug 12, 2015

Looks like GFM does not allow ##Heading.

@nilgradisnik
Copy link

@chjj Please be careful reviewing such PRs that break backwards compatibility.
If necessary, bump the minor or major version for npm package. This rule broke many headings for everyone doing npm install in the last week or so.

@bmneely
Copy link

bmneely commented Oct 1, 2015

@chjj please reconsider re-opening this issue. GFM does allow for ##Header (though strangly not in comments) in repo content: https://github.com/bmneely/spartacus/blob/master/README.md

@getaaron
Copy link

getaaron commented Oct 1, 2015

Would also like to see this reopened. Breaking functionality like this should be intentional, following the guidelines of semantic versioning.

Down the road it might be nice to transition to Commonmark, which has a better defined spec, but this change unexpectedly broke some functionality.

@FuDesign2008
Copy link

I think @bmneely is right and would also like to see this reopened.

@getaaron
Copy link

getaaron commented Nov 9, 2015

Thanks @FuDesign2008

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants