This issue reference other issues related to the processing of headings. See #956
Recap of all still relevant issues concerning headings:
# and the text, per spec. Duplicates: #909 #729 #692 #687 #670 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.
@GenaBitu you can parse with gfm: false
@Feder1co5oave Yes, but then you don't get the rest of GFM, right?
_Exactly_
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?
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.
Most helpful comment
You could create an extension as an npm package that could be shared
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.