6

Have a look at this answer

One of the bolds works, and the other one just turns up as ** in the actual post.

This is the string that isn't working: **x**ml n**ib**

Which renders as: xml nib

Improve this question
4
  • for clarity, could you put the original string, escaped in backquotes, then show us how it is rendered? I.e.: change the last line of this post to: The string "**x**ml n**ib**" gets rendered like this: xml nib Commented Jul 2, 2009 at 2:21
  • We've been collecting markdown bugs in another thread, so I added this one meta.stackexchange.com/questions/1227/… Commented Jul 2, 2009 at 2:27
  • 1
    @Kyle I'm a bit confused as to the status of this... it's marked as "completed" but it's still broken in the same way as before, and the thread you linked is also marked as "completed". Was this actually a "wontfix"? Commented Mar 11, 2011 at 5:24
  • @romkyns: It's referring to the part of the preview not matching the actual output, as identified by the middle two sentences of this question (pre-revision). Commented Jul 11, 2013 at 3:58

7 Answers 7

Reset to default
9

This is not a bug; this is by design.

It becomes very difficult to talk about code when your_variable_names_are_suddenly_underlined. Intra-word emphasis is a bad idea and we have EXPLICITLY disabled it.

See: https://blog.stackoverflow.com/2008/06/three-markdown-gotcha/.

1) Markdown’s single biggest flaw is its intra-word emphasis.

I don’t think anybody writes:

un*fricking*believable

often enough to justify making it nearly impossible to talk about tokens with underscores in them:

some_file_name

is interpreted as:

some<em>file</em>name

It even works across word boundaries:

file_one and file_two

becomes:

file<em>one and file</em> two

Whenever you’re writing tokens with underscores you have to make absolutely sure you’re in a backtick-delimited code span. The same problem will also nail you on equations like abc, but that seems to pop up less frequently.

Showdown follows the reference implementation on all this, but in WMD I do a little preprocessing to hack the idiocy away: basically I just backslash-escape any underscores or asterisks that might trigger it. It’s a flagrant violation of the standard, but since it’s a pre-pass that should produce identical output with any Markdown processor, I feel justified. Unfortunately my hack did screw up one edge case (which I don’t have in front of me) and there isn’t any way to disable it. Both those things will change in the next release.

Improve this answer
7
  • 2
    i guess this is for users who don't know to put backquotes around inline code? Commented Jul 2, 2009 at 2:26
  • 9
    Jeff: the problem that many of us have here isn't that the ** characters don't bold the text. It's that the behavior shown by the preview is different from the behavior shown after you post. That is what needs fixed. Commented Jul 2, 2009 at 3:11
  • So why does it work in the javascript preview then? Commented Jul 2, 2009 at 14:29
  • If I click the bold button in the editor, then I expect it to bold my text. If markdown can't do it, and html bold tags can, then the editor should be inserting bold tags. Commented Jul 2, 2009 at 23:10
  • @Tom, if you feel strongly about it, you can submit patches to the repository: meta.stackexchange.com/questions/1227/… Commented Jul 3, 2009 at 8:25
  • 1
    Jeff, you seem to have taken the Microsoft-patented "let's hold the poor little idiots' hands" approach to software design. That's rather disappointing. Intraword emphasis is legitimately useful (made-up example: the word is emphasis, not emfasis), whereas underscore-joined names without backticks are not useful. When a user mistakenly types PLAIN_TEXT and sees PLAIN<i>TEXT</i> instead, it's easy to correct (it's a wiki. Just fix it), but when they type intraword emphasis and don't get it, it's not as easy to fix (<b> doesn't immediately come to mind). Commented Dec 9, 2009 at 23:45
  • 3
    This "answer" maybe justifies disallowing intra-word underscore-emphasis. Maybe. (And only on the techie SE sites.) It in no way, shape, or form justifies disallowing intra-word emphasis via an asterisk. (Does any programming language even allow using asterisks in variable names?) Commented May 18, 2011 at 0:20
6

As a workaround, you could use "**x**ml n<b>ib</b>": xml nib

Improve this answer
3

This used to be intentional for a long time, but now it works. See Markdown change: Intra-word emphasis now works.

Improve this answer
1

xml n ib
xml nib
xml nib

Looks like it doesn't work when bolding partial words, which at times could be useful if you ever need to use ** inside another word sentence.

Unclear which would be better in this case, stats on how often ** is used? :p

abc abc abc

Improve this answer
2
  • 1
    Gosh I wish I were better at pointers now. Commented Dec 23, 2009 at 17:35
  • you can use <b></b> Commented Jul 11, 2013 at 10:02
1

A failing in the markdown parser. It starts a bold if the bold tag starts on a word boundary, but not inside a word.

Xml nIB

But it works in the preview box correctly, so the javascript parser is correct, the server side one is not.

Improve this answer
0

It works good; just put some spaces.

x ml n ib
**x** ml n **ib**

If you want to use it without spaces you could use <b></b>.

xml nib
<b>x</b>ml n<b>ib</b>  

You can also put <o> before the initial ** and after the final **.

aaaa = xml nib
a<o>**aa**<o>a = **x**<o>ml n<o>**ib**

Improve this answer
0

Is a double asterisk a left bracket, or a right bracket, or a single asterisk that's been escaped? It gets worse. A single asterisk can be a left bracket or a right bracket as well. If I remember right, single asterisk indicates italics. No matter how you write the parser, there are going to be complaints.

This text was bracketed by single asterisks.

To see the problem more clearly, consider quoted text inside of CSV. A quote mark can be a left bracket or a right bracket. A double quote is typically an escaped single quote. Quotes cannot be nested.

Improve this answer

You must log in to answer this question.