on the philosophical aspects of a specification

[Seumas Mac Uilleachan]

Steve Hoelzer wrote:

> On Tue, Mar 4, 2008 at 10:08 PM, Michel Fortin

> <michel.fortin at michelf.com> wrote:

>   

>> Le 2008-03-04 à 13:15, david parsons a écrit :

>>

>>

>>  >   But what's the intent of ***hello*, sailor**   ?

>>  >

>>  >   Should it produce

>>  >    1. <strong><em>hello</em>, sailor</strong>

>>  >    2. <strong>*hello*, sailor</strong>

>>  >    3. *<strong>hello*, sailor</strong>

>>  >    4. ***hello<em>, sailor<strong>

>>  >    5. ***hello*, sailor**

>>  >    6. <em><strong>hello</strong></em><strong>, sailor</strong>

>>  >    7. <em><strong>hello</em>, sailor</strong> (which makes baby XML

>>  > cry) ?

>>

>>  I'd say 1:

>>     

>

> <snip>

>

>   

>>  A better question is what to do with this:

>>

>>      *hello **dear* boy**

>>     

>

> For cases like these, I'd say that Markdown shouldn't do anything.

> >From the official Markdown page:

>

>   

>> The overriding design goal for Markdown's formatting syntax is to make

>> it as readable as possible. The idea is that a Markdown-formatted

>> document should be publishable as-is, as plain text, without looking

>> like it's been marked up with tags or formatting instructions. While

>> Markdown's syntax has been influenced by several existing text-to-HTML

>> filters, the single biggest source of inspiration for Markdown's syntax

>> is the format of plain text email.

>>     

>

> So, the question is: Would you ever see **mismatched *asterisks***

> intentionally written in plain text email?

>

> I don't think so, because it doesn't make intuitive sense. And if I

> can't make sense of the plain text, why should Markdown define one

> interpretation as being correct?

>

> Steve

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

>

>   


Perhaps if strong and emphasis is desired in such a situation the spec 
should state to use * and __ or _ and ** to better distinguish between 
them. So *** would simply be *** unless balanced with a *** on the other 
side of the wrapped text. The sample could thus be *hello __dear* boy__