IDs of headings with inline tokens (link, em, bold...)

[Feder1co5oave]

I was working recently about headings' ids and I encountered something like:

### Heading with a [link](http://github.com/)

### Heading with some _italic text_

### Or some **strong**
(which doesn't really make any difference, here)

### Or even `code`

### What about ~~strikethrough~~

Here on github, clean segment links are generated, which only include the "raw" visible part of the heading text, as you can see in this gist.

Now, marked with default options returns this:

<h3 id="heading-with-a-link-http-github.aaakk.us.kg-">Heading with a <a href="http://github.com/">link</a>!</h3>
<h3 id="heading-with-some-_italic-text_-">Heading with some <em>italic text</em>!</h3>
<h3 id="or-some-strong-">Or some <strong>strong</strong>...</h3>
<p>(which doesn&#39;t really make any difference, here)</p>
<h3 id="or-even-code-">Or even <code>code</code></h3>
<h3 id="what-about-strikethrough-">What about <del>strikethrough</del></h3>
<p>Hover the cursor on the titles to see the generated link.</p>

As you can see, the ids are quite "dirty", as they are generated from the raw markdown code of the heading (see code). Some markdown punctuation is crushed into dashes, but more complex tokens like links have additional text in them, which makes its way to the segment link.

I wonder if you would be interested in "fixing" this, as I believe it would require some many LOCs.
My idea was that we could create a function like inline.output, that only returns the textual part of the rendered markdown. The return value of this function would be passed as the raw argument of the heading renderer.
I am available to submit a PR in a week.

[xiaofengzang]

That is default behavior, you can overwrite heading with

function(text, level, raw) { return '<h' + level + '>' + text + '</h' + level + '>\n';};"

[Feder1co5oave]

I've already overridden the renderer, but the problem is the raw argument, which contains raw markdown code. I could lex that and get rid of the dirt, but I don't consider that a viable option.

[gregtandiono]

+1 @Feder1co5oave

[F1LT3R]

+1

[joshbruce]

See #981