I believe there might be a bug in the Markdown preview script. It shows the following

foo**strong text**


foo*<i>strong text*</i>

But I've looked at several other Markdown parsers, including what could be considered the reference implementation at Daring Fireball and they render it as

foo<strong>strong text</strong>

which is what I would expect.

I'm not sure if the server-side implementation has this behaviour, so I'll put foo**strong text** below to see what happens:

foostrong text

If this is by design then I'm sorry. If it's unintentional I'll see if I can make a patch.

EDIT: The above at the time of posting renders as foo*<i>strong text*</i>. This is consistent with the behaviour of the previewer.

  • Interestingly, the behavior for single quotes is different. Like''this''. – Mark Storer Jan 31 '11 at 18:44

Notice the lack of any white space between foo and strong? Intra-word emphasis in markdown like that is intentionally disabled here. It's not strictly to spec, but it's needed here because often source code, variable names, language/product names, file paths, etc have * or _ in them. If you really want to show that emphasis, you can use html instead.

That said, you do have a bug here. It should ignore the markup completely. Instead, it renders just the italic portion of the markup (one asterisk instead of both). I suspsect a regex somewhere is treating the * character as whitespace/word boundary so it no longer looks like the middle of a word.

Personally, I'm okay with this bug because you're in a well-defined exception (intra-word emphasis) and the preview renders consistently with what's finally posted. Sure, it'd be better if it were fixed, but I suspect they have many things to spend their time on that I want more.

  • If the argument for ignoring * and ' without surrounding whitespace is "we need to do that for code", then I think the above question demonstrates just how flawed that argument is. Code should be indented with four spaces, at which point all that formatting stuff goes out the window. Moderators can catch ill-formatted code from inexperienced posters and fix it, and in doing so show the OP How Its Done. – Mark Storer Jan 31 '11 at 18:47
  • @Mark - not just code, but prose that discusses the code, including the odd names that pop up therein. – Joel Coehoorn Jan 31 '11 at 18:53
  • @Joel- In my (relatively limited) experience, code in prose is generally limited to class.function(). I have trouble believing people would put commented code in prose, and I would think math operators would be far less common. Admittedly my language experience on SO is limited to c-ish languages... Java, C++, JS, and a tad bit of C#. Prose in php/ruby/whatever might use those symbols more frequently. – Mark Storer Jan 31 '11 at 19:02
  • 1
    @Mark - how about class.function_with_underscore_name() – Joel Coehoorn Feb 1 '11 at 0:03
  • @Joel- I don't see how that matters. Whether someone is using_underscores orCamelCase, both can be detected. If some threshold ratio of 'not code' vs 'code' is reached, then suggest the detected paragraph[s] be reformatted (and offer to do it for them). – Mark Storer Feb 1 '11 at 0:10

The correct behavior here would be rendering it as

foo**strong text**

because we don't want intra-word emphasis. With this change, that's exactly what will happen from the next build on.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .