Fix Heading ID for Unicode text

[k-utsumi]

I think defining nonWordCharacters will solve it.

Reference: atom nonWordCharacters

[UziTech]

according to the spec:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element's tree and must contain at least one character. The value must not contain any ASCII whitespace.

so couldn't we change it to /\s+/g?

[UziTech]

I suppose we would want to remove " as well so /["\s]+/g

All other characters seem to work fine in ids on chrome.

[k-utsumi]

Maybe, need to consider the behavior of shared URL with fragment (section ID).

e.g. ## how to resolve #123 ? or ...

---

I'm sorry, I closed it by mistake in the mark down test.

[styfle]

This feature (header id) is being removed in PR #1354 so I don't think it's worth pursuing in this PR.

[k-utsumi]

Thanks😄

[k-utsumi]

I want to eliminate this problem quickly, so I reopened with a simple code adjustment.
If merged, I’ll make same PR for other services I use.

[UziTech]

@styfle do we want to add a seenIds array to prevent collisions on this pr?

[styfle]

@UziTech If we are not going to remove it, we could go all-out and implement like so:

functionSlugger(){this.seen={};}Slugger.prototype.slug=function(value){varslug=value.toLowerCase().trim().replace(/[\u2000-\u206F\u2E00-\u2E7F\\'!"#$%&()*+,./:;<=>?@[\]^`{|}~]/g,'').replace(/\s/g,'-');varcount=this.seen.hasOwnProperty(slug) ? this.seen[slug]+1 : 0;this.seen[slug]=count;if(count>0){slug=slug+'-'+count;}returnslug;};

I think we'll need some unit tests to see what will and will not match as far as unicode goes.

That was one of the reasons why I was trying to tear it out, so the implementation and tests could live in github-slugger package.

[UziTech]

I think not having dependencies is one of the big benefits of marked so if we want to have ids be part of gfm we will need to incorporate slugger into our code.

[styfle]

@k-utsumi Would you like to update this PR with the slugger or should I create a new PR?

[k-utsumi]

@styfle
Since I can't understand the change correctly,
Could you edit the code directory or create a new PR?

[styfle]

Yes, I will create a PR this weekend with the appropriate change.

[styfle]

Closing in favor of #1401