Showdown: link text with underscore is rendered as <em>

[tivie]

To prevent underscores to be parsed as <em> in the middle of words you need to activate the option literalMidWordUnderscores.

var showdown  = require('showdown'),
    converter = new showdown.Converter(),
    converter.setOption('literalMidWordUnderscores', true)
    text      = '[snook.ca/archives/html_and_css/specificity-graphs](http://snook.ca/archives/html_and_css/specificity-graphs)',
    html      = converter.makeHtml(text);

As a side note, npm and "browser" version of showdown are the same, so you can use the demo to test showdown.

[thisconnect]

It's not just about underscores, I would like to know if the same problem comes up with * or - with default config?
Or what kind of config it needs to fix this.

The showdown demo does not use the default config?

in http://showdownjs.github.io/demo/js/editor.js

        {name: 'omitExtraWLInCodeBlocks', value: true},
        {name: 'noHeaderId', value: false},
        {name: 'parseImgDimensions', value: true},
        {name: 'simplifiedAutoLink', value: true},
        {name: 'literalMidWordUnderscores', value: true},
        {name: 'strikethrough', value: true},
        {name: 'tables', value: true},
        {name: 'tablesHeaderId', value: false},
        {name: 'ghCodeBlocks', value: true},
        {name: 'tasklists', value: true},
        {name: 'smoothLivePreview', value: true},
        {name: 'prefixHeaderId', value: false}

Other markdown implementation appear to have the literalMidWordUnderscores behavior set by default.

[tivie]

Demo options and default configuration

The showdown demo does not use the default config?

If you click on menu (top left corner), you can see the configuration used by the demo. You can also enable and disable options and features and change the showdown version used.

Showdown's default behavior

Showdown follows the original markdown spec as closely as possible:

Emphasis can be used in the middle of a word:

un*frigging*believable
But if you surround an * or _ with spaces, it’ll be treated as a literal asterisk or underscore.

To produce a literal asterisk or underscore at a position where it would otherwise be used as an
emphasis delimiter, you can backslash escape it:

\*this text is surrounded by literal asterisks\*

literalMidWordUnderscores

It's not just about underscores, I would like to know if the same problem comes up with * or - with
default config?

* follows the spec above, regardless of literalMidWordUnderscores being activated or not.
This means some*asterisk*text will ALWAYS be converted to some<em>asterisk</em>text.

Regarding - I'm not sure what you're talking about. - always have their literal meaning unless they are the first character in a line, in which they will be converted to an unordered list. In the middle of a word or a setence, they will not be converted.

With literalMidWordUnderscores option enabled, both _ and __ will not be converted to <em> or <strong> when they appear in the middle of a string.

[thisconnect]

thanks for clarification

Regarding - I'm not sure what you're talking about. - always have their literal meaning unless they are the first character in a line, in which they will be converted to an unordered list. In the middle of a word or a setence, they will not be converted.

Sorry, you are right. I mistakenly thought dash (-) was used as strikethrough, but that is jira syntax.

My only concern is about unwanted formatting in "link text" and different output compared to other libs e.g. Github MD (marked?).

You are right, the link text in my example (containing the url with underscores), could just be escaped.