[Headings]: Consolidate issues

[joshbruce]

This issue reference other issues related to the processing of headings. See #956

[Feder1co5oave]

Recap of all still relevant issues concerning headings:

• Headings require a space between the hash # and the text, per spec. Duplicates: [Bug] Heading works when using the "#" togeter the text #909 Bug in parsing of headers #729 H3 not rendered when space is missing #692 Header processes differently on client and server #687 Header not formating for "# [text]" but only "#[text]" #670
• Another bug in parsing of headers #526 this is ambiguous, I'd like to comply with commonmark here
• complaints about duplicate auto-generated ids (see V0.3.6,<h1>,<h2>,<h3>,<h4>,<h5>,<h6>sometimes id are same #919 (comment)): V0.3.6,<h1>,<h2>,<h3>,<h4>,<h5>,<h6>sometimes id are same #919 Duplicate header names aren't differentiated in IDs #879
• If HTML style comments contain headings they do not work #1050 HTML blocks/comments have greater priority than lheadings
• generic complaints about auto-generated ids (see Change the logic of generating the id of h tags #432 (comment)): Russian letters cuted out from id's #316 Change the logic of generating the id of h tags #432 Issue with cyrillic headers #604 Outputting IDs into html when they are not needed #806 Anchor generation and headers with HTML #685 Hash links with "&" are not converted the same way as github links #857 cannot generate ID for CJK characters in headings #838 Support HTML5 element id #801 Why is my h1 id is -，Chinese? #1042
• IDs of headings with inline tokens (link, em, bold...) #456 is still relevant IMO, I need to produce some test cases. Fixes IDs of headings with inline tokens (link, em, bold...) #450 Back ticks in titles (incorrectly?) converted to hypens #510
• Apostrophe character replacement not working in renderer #971 solved

[marekdedic]

About the requirement of a space after # for headings: I know the space is required by the spec, but why not add an option allowing the space to be omitted (defaulting to false, i. e. requiring the space). I am using this in an editor for relative noobs and would prefer to have the option, while others might stick to the spec.

Will try to post a PR for this.

[Feder1co5oave]

@GenaBitu you can parse with gfm: false

[marekdedic]

@Feder1co5oave Yes, but then you don't get the rest of GFM, right?

[Feder1co5oave]

Exactly

[marekdedic]

Well, what if you want all the bells and whistles of GFM and want non-spec-conformity on just this one thing?

Upon reading the CoC, I am thinking about the pros and cons of doing it as an extension - by the CoC, extension is the preferred choice (over adding an option), however, judging by the amount of issues around this, this is a pretty common request and an option would solve this for everybody, whereas an extension cannot be shared with others who might prefer such behaviour. Am I right?

[UziTech]

You could create an extension as an npm package that could be shared

const marked = require('marked-no-header-space')(require('marked'));

require('marked-no-header-space') could return a function that extends marked then returns the extended marked.

Problem solved for anyone who wants it and we don't have to work around another option that is not in the spec.