Marked: [Headings]: Consolidate issues

Created on 25 Dec 2017  路  7Comments  路  Source: markedjs/marked

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

headings epic

Most helpful comment

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.

All 7 comments

Recap of all still relevant issues concerning headings:

  • [x] Headings require a space between the hash # and the text, per spec. Duplicates: #909 #729 #692 #687 #670
  • [ ] #526 this is ambiguous, I'd like to comply with commonmark here
  • [ ] complaints about duplicate auto-generated ids (see https://github.com/markedjs/marked/issues/919#issuecomment-355462033): #919 #879
  • [ ] #1050 HTML blocks/comments have greater priority than lheadings
  • [ ] generic complaints about auto-generated ids (see https://github.com/markedjs/marked/issues/432#issuecomment-49196231): #316 #432 #604 #806 #685 #857 #838 #801 #1042
  • [x] #456 is still relevant IMO, I need to produce some test cases. Fixes #450 #510
  • [x] #971 solved

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

priyesh-diukar picture priyesh-diukar  路  3Comments

chunhei2008 picture chunhei2008  路  3Comments

gclove picture gclove  路  4Comments

mjbvz picture mjbvz  路  4Comments

FireflyAndStars picture FireflyAndStars  路  3Comments