From jakov at gmx.at  Wed Oct  1 13:54:44 2014
From: jakov at gmx.at (jakov at gmx.at)
Date: Wed, 01 Oct 2014 19:54:44 +0200
Subject: let us not discuss that here
In-Reply-To: <8D1AAFD649488BE-1E20-3C98@webmail-va024.sysops.aol.com>
References: <8D1AAFC91259F71-1E20-3BD8@webmail-va024.sysops.aol.com>
 <8D1AAFD649488BE-1E20-3C98@webmail-va024.sysops.aol.com>
Message-ID: <d5a7f466-6187-4584-b257-8f422b162c1c@email.android.com>

By using different symbols for different styles of tables I think you are messing with the principle not to mix content and formatting.

If I wanted to have a table with border in markdown-like syntax I would rather like to be able to use the {.class} property tags on tables, just like some flavors allow for headers.

# normal header
# underlined header {.importantheader}

| item | price |
|-------|-------|
| shaver | 80$ |
| printer | 100$ |
| LED-TV | 300$ {.sale} |
{#pricetable}

In my little example, the corresponding CSS file could make .importantheader be underlined, .sale blink in bright red color and bigger font and put stars in the border of the very special #pricetable. All these would apply to block level elements.

For inline elements a different syntax would be needed, but I doubt that it would be simple enough to be easier than just using a <span class="important"></span> HTML tag. (However, in my opinion <span.class></span> and <span#id></span> would be nice HTML shortcuts, but this should not primarily be a markdown problem.) 

Another option would be to have a generic text marking option similar to critic markup, which just like <span> doesn't do anything but offer a way to change the corresponding text:

Today we have a {::super special sale::}{.blink}.

On 30. September 2014 21:39:33 MESZ, bowerbird via Markdown-Discuss <markdown-discuss at six.pairlist.net> wrote:
>oh, crap, i forgot to mention that
>"beyond markdown -- part 4"
>is now available for your perusal.         ;+)
>
>>   https://medium.com/@bbirdiman/beyond-markdown-part-4-9b4dc6841d7e
>
>if you'd like to discuss anything,
>send me an e-mail.  thank you.
>
>-bowerbird
>
>p.s.  and if you know jeff atwood,
>feel free to share the link with him.
>
>_______________________________________________
>Markdown-Discuss mailing list
>Markdown-Discuss at six.pairlist.net
>https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141001/6f5e6c9a/attachment.html>

From bowerbird at aol.com  Fri Oct  3 17:53:21 2014
From: bowerbird at aol.com (bowerbird)
Date: Fri, 3 Oct 2014 17:53:21 -0400
Subject: let us not discuss that here
Message-ID: <8D1AD6B9571E108-834-15638@webmail-va143.sysops.aol.com>

i sent jakov a reply backchannel.
take it all backchannel please.

here's a post i made elsewhere,
but i think it's relevant here too,
in case anyone has any feedback.

-------------------------------------------------------------

call me crazy if you like, i don't mind, but...

there's no need to plan for "20 to 40 years".

by then, there will be no need for "markup",
"markdown", or "mark-all-around-the-town".

it's not that difficult even now to "figure out"
fairly unstructured text, so once we humans
make slightly smarter programs and accept
a responsibility to write in a structured way,
with no room for ambiguous interpretation
-- which really isn't as hard as you think --
we'll be able to leave explicit markup behind.

it will be "zen".

i say this because i was able to ascertain
the structure of project gutenberg e-texts
without too much difficulty in most cases.

likewise, you can scan a print-book and
do o.c.r.. on the scans, and get output
which also reveals the structure of the
underlying text in a straightforward way.

if you want to see that on a large scale,
examine google books, which offers stuff
which it ascertained, like header markup
and a respective linked table of contents.

that stuff certainly wasn't "marked up" in
the print-book, but it just isn't that hard to
"figure out" either, from the data available,
if you ponder it a while, and apply yourself.

in fact, i wouldn't be the least bit surprised
if google can already grok unstructured text,
because they have the firepower to solve it.

heck, i'm merely a garage hacker, and i have
achieved much of the solution all by myself.

this "light-markup" stage is just a little path,
meant to show us the way to a bright future.

-bowerbird

p.s.  but since i'm here now anyway,
i might as well tell you "part 5" is up:
>   beyond markdown -- part 5 -- shining a spotlight on sections and 
headers
>   https://medium.com/@bbirdiman/beyond-markdown-part-5-4902097723b0


From yap7800 at gmail.com  Fri Oct  3 19:12:57 2014
From: yap7800 at gmail.com (Max Yap)
Date: Sat, 4 Oct 2014 07:12:57 +0800
Subject: No subject
Message-ID: <CAGikihTyvM9J-D1Pb3Jr+7_3Z=rFVwg2Us4yn1OH83+JX7D03A@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141004/7f1cba47/attachment.html>

From mofosyne at gmail.com  Fri Oct  3 23:34:03 2014
From: mofosyne at gmail.com (mofo syne)
Date: Sat, 4 Oct 2014 13:34:03 +1000
Subject: Sub reddit for general discussion on lightweight markup languages
Message-ID: <CAPJM1pe-prYn_0Tw9Z3X=hWfucZ2DD9t1EqyObpjO9QuWKXTCQ@mail.gmail.com>

http://www.reddit.com/r/LightWeightMarkup/

If anybody is a reddit user, let me know, I might need a few moderators.

Might want to also update the sidebar with useful information.

From bowerbird at aol.com  Wed Oct  8 19:36:51 2014
From: bowerbird at aol.com (bowerbird)
Date: Wed, 8 Oct 2014 19:36:51 -0400
Subject: maybe we should discuss it
Message-ID: <8D1B167DED6B522-18A8-5329@webmail-vm134.sysops.aol.com>

in terms of my last post here:

>   
http://six.pairlist.net/pipermail/markdown-discuss/2014-October/003247.html

i was intrigued to see this today:

>   https://thegrid.io

this mirrors earlier flipboard tech:
>   
http://techcrunch.com/2014/03/23/layout-in-flipboard-for-web-and-windows/

-bowerbird

p.s.  by now, you might have figured out that
you can search twitter for "beyond markdown".


From mofosyne at gmail.com  Wed Oct  8 19:44:17 2014
From: mofosyne at gmail.com (mofo syne)
Date: Thu, 9 Oct 2014 10:44:17 +1100
Subject: maybe we should discuss it
In-Reply-To: <8D1B167DED6B522-18A8-5329@webmail-vm134.sysops.aol.com>
References: <8D1B167DED6B522-18A8-5329@webmail-vm134.sysops.aol.com>
Message-ID: <CAPJM1pdBg4djgkJzp=pniYgPrShp0zCy+s2Z=JNp_XSW3ibHgw@mail.gmail.com>

Looks really cool about automated layouts, btw maybe make a post in
http://www.reddit.com/r/lightweightmarkup about that, and perhaps let
others in the email chain for this, to know to discuss there.

On Thu, Oct 9, 2014 at 10:36 AM, bowerbird via Markdown-Discuss
<markdown-discuss at six.pairlist.net> wrote:
> in terms of my last post here:
>
>>
>
> http://six.pairlist.net/pipermail/markdown-discuss/2014-October/003247.html
>
> i was intrigued to see this today:
>
>>   https://thegrid.io
>
>
> this mirrors earlier flipboard tech:
>>
>>
>
> http://techcrunch.com/2014/03/23/layout-in-flipboard-for-web-and-windows/
>
> -bowerbird
>
> p.s.  by now, you might have figured out that
> you can search twitter for "beyond markdown".
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

From dev+ietf at seantek.com  Fri Oct 10 11:56:00 2014
From: dev+ietf at seantek.com (Sean Leonard)
Date: Fri, 10 Oct 2014 08:56:00 -0700
Subject: (text/markdown) link label vs. link identifier and last-one-wins
Message-ID: <54380190.6090609@seantek.com>

In working on the text/markdown spec, I am making a reference to the 
syntax of links, specifically the things [1] and [Google] used in this 
construct:

    Hello I am some [Markdown][1] and I use [Google][].

    [1]: http://daringfireball.net/projects/markdown/
    [Google]: http://www.google.com/ "This is Google"


What is the common Markdown way of identifying this syntax element?

stmd (CommonMark) consistently calls it the "link label". (To be clear, 
it also calls [Markdown] a link label, even though that element does not 
have the same behavior as [1].)

However, [Markdown Syntax][MDSYNTAX] refers to it once as a "link 
identifier" in the bullet point: "Square brackets containing the *link 
identifier* (optionally indented from the left margin using up to three 
spaces)". Elsewhere it refers to it as a label. For example: 
"Reference-style links use a second set of square brackets, inside which 
you place a label of your choosing to identify the link" and "Then, 
anywhere in the document, you define your link label like this, on a 
line by itself".

I reviewed Markdown.pl, which consistently uses the variable name 
$link_id (see also $g_urls, and comments such as # Link defs are in the 
form: ^[id]: url "optional title").

On this basis, I am going to call it "link identifier". Questions?

Also, Markdown.pl seems to define last-wins behavior: the last link 
definition is indexed as the definition in $g_urls. (See 
_StripLinkDefinitions.) Older ones get overwritten by newer ones. Is 
this common or normative behavior? How do other implementations do it?

It's important that I keep the original reference list short; I would 
rather not refer normatively to documents other than Gruber's own 
Markdown rules.

Sean

[MDSYNTAX]: http://daringfireball.net/projects/markdown/syntax
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141010/bae430cf/attachment.html>

From michel.fortin at michelf.ca  Fri Oct 10 12:11:16 2014
From: michel.fortin at michelf.ca (Michel Fortin)
Date: Fri, 10 Oct 2014 12:11:16 -0400
Subject: (text/markdown) link label vs. link identifier and last-one-wins
In-Reply-To: <54380190.6090609@seantek.com>
References: <54380190.6090609@seantek.com>
Message-ID: <9D0534E3-6E57-453B-BC69-83A67715C8DA@michelf.ca>

Le 10-oct.-2014 ? 11:56, Sean Leonard <dev+ietf at seantek.com> a ?crit :

> On this basis, I am going to call it "link identifier". Questions?

It is called both a "label", an "identifier", and a "name" under the [link][] section of the syntax description on Daring Fireball. Choose as you like.

 [link]: http://daringfireball.net/projects/markdown/syntax#link


> Also, Markdown.pl seems to define last-wins behavior: the last link definition is indexed as the definition in $g_urls. (See _StripLinkDefinitions.) Older ones get overwritten by newer ones. Is this common or normative behavior? How do other implementations do it?

Well, it is not specified in the official documentation. You can always check on Babelmark 2 to see how various implementations are doing it:
<http://johnmacfarlane.net/babelmark2/?normalize=1&text=%5Blink%5D%5B%5D%0A%0A%5Blink%5D%3A+1%0A%5Blink%5D%3A+2>


> It's important that I keep the original reference list short; I would rather not refer normatively to documents other than Gruber's own Markdown rules.

I don't understand what all this has to do with a spec for a MIME type.


-- 
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4154 bytes
Desc: not available
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141010/9cbdd430/attachment.bin>

From dev+ietf at seantek.com  Fri Oct 17 19:31:10 2014
From: dev+ietf at seantek.com (Sean Leonard)
Date: Fri, 17 Oct 2014 16:31:10 -0700
Subject: text/markdown draft-03 guide (and use-cases-00 guide)
Message-ID: <00EEF7E3-C058-4F83-B0E1-B7E5667B4193@seantek.com>

Hello Markdown World:

The following Internet-Drafts are about to be posted:

draft-ietf-appsawg-text-markdown-03
draft-seantek-text-markdown-use-cases-00

As discussed in apps-discuss at ietf.org: to make the drafts shorter yet more informative, I split them in two. The secondary document has seven additional syntax registrations, background information, and preservation strategies. The main registration document registers the media type. They are meant to be read together; however, the secondary document makes no normative statements (no RFC 2119 key words).

draft-ietf-appsawg-text-markdown-03
  1. Introduction
  2. Markdown Media Type Registration Application
  3.  Optional Parameters
    3.1. syntax
    3.2. output-type
  4. Fragment Identifiers
  5.  Example


draft-seantek-text-markdown-use-cases-00
1. (Introduction)
    1.1. On Formats
    1.2. Markdown Design Philosophy
    1.3. Uses of Markdown
    1.4. Uses of Labeling Markdown Content as text/markdown
  2.  Strategies for Preserving Media Type and Parameters
  3.  Registration Templates for Common Markdown Syntaxes
    3.1. MultiMarkdown
    3.2. GitHub Flavored Markdown
    3.3. Pandoc
    3.4. Fountain (Fountain.io)
    3.5. CommonMark
    3.6. kramdown-rfc2629 (Markdown for RFCs)
    3.7. rfc7328 (Pandoc2rfc)
  4.  Examples for Common Markdown Syntaxes


Thank you,

Sean

From dev+ietf at seantek.com  Fri Oct 17 19:33:37 2014
From: dev+ietf at seantek.com (Sean Leonard)
Date: Fri, 17 Oct 2014 16:33:37 -0700
Subject: New Version Notification for
 draft-seantek-text-markdown-use-cases-00.txt
References: <20141017232121.29395.95978.idtracker@ietfa.amsl.com>
Message-ID: <8F464A2F-5FD7-4998-9F56-8B05BAA38B24@seantek.com>

Here is one.

*******
From: internet-drafts at ietf.org
Subject: New Version Notification for draft-seantek-text-markdown-use-cases-00.txt
Date: October 17, 2014 at 4:21:21 PM PDT

A new version of I-D, draft-seantek-text-markdown-use-cases-00.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-seantek-text-markdown-use-cases
Revision:	00
Title:		text/markdown Use Cases
Document date:	2014-10-17
Group:		Individual Submission
Pages:		20
URL:            http://www.ietf.org/internet-drafts/draft-seantek-text-markdown-use-cases-00.txt
Status:         https://datatracker.ietf.org/doc/draft-seantek-text-markdown-use-cases/
Htmlized:       http://tools.ietf.org/html/draft-seantek-text-markdown-use-cases-00


Abstract:
 This document elaborates upon the text/markdown media type for use
 with Markdown, a family of plain text formatting syntaxes that
 optionally can be converted to formal markup languages such as HTML.
 Background information, local storage strategies, and additional
 syntax registrations are supplied.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

From dev+ietf at seantek.com  Fri Oct 17 19:35:07 2014
From: dev+ietf at seantek.com (Sean Leonard)
Date: Fri, 17 Oct 2014 16:35:07 -0700
Subject: New Version Notification for draft-ietf-appsawg-text-markdown-03.txt
References: <20141017233352.18234.4249.idtracker@ietfa.amsl.com>
Message-ID: <78D77F5C-A973-4495-875B-60D969241DA6@seantek.com>

And here is the other.

*******

From: internet-drafts at ietf.org
Subject: New Version Notification for draft-ietf-appsawg-text-markdown-03.txt
Date: October 17, 2014 at 4:33:52 PM PDT


A new version of I-D, draft-ietf-appsawg-text-markdown-03.txt
has been successfully submitted by Sean Leonard and posted to the
IETF repository.

Name:		draft-ietf-appsawg-text-markdown
Revision:	03
Title:		The text/markdown Media Type
Document date:	2014-10-17
Group:		appsawg
Pages:		22
URL:            http://www.ietf.org/internet-drafts/draft-ietf-appsawg-text-markdown-03.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/
Htmlized:       http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-03

Abstract:
  This document registers the text/markdown media type for use with
  Markdown, a family of plain text formatting syntaxes that optionally
  can be converted to formal markup languages such as HTML.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

From bowerbird at aol.com  Thu Oct 23 18:33:53 2014
From: bowerbird at aol.com (bowerbird)
Date: Thu, 23 Oct 2014 18:33:53 -0400
Subject: just announced
Message-ID: <8D1BD288F4B0BF2-F54-997D@webmail-vm160.sysops.aol.com>

this was just announced, from
the folks who do leanpub.com:

>   http://markua.com

in a related note, i have finished
my "beyond markdown" series...
>   https://medium.com/@bbirdiman/beyond-markdown-part-11-444393af1ed0

i put up a web-app as a playground.

-bowerbird


From mofosyne at gmail.com  Fri Oct 24 04:25:24 2014
From: mofosyne at gmail.com (mofo syne)
Date: Fri, 24 Oct 2014 19:25:24 +1100
Subject: markdown for speech synthesis?
Message-ID: <CAPJM1peNk4puph6KxbbyOBbiista+n8g6SmgOHoMLZFdjGq0Ow@mail.gmail.com>

Have anyone ever considered the possibility of using markdown to
perform speech synthesis markups?

Just a thought:

There is already a speech synthesis markup language call SSML:
http://www.w3.org/TR/speech-synthesis/

However I do wonder if there is a need to perhaps consider what a
markdownish speech synthesis markup language may look like. I don't
think you can exactly use markdown syntax to do speech synth. Take for
example sarcasm, you can't exactly do it in pure text markup.

So far what I can think of:

* `...` :-- indicates pause in speech
* `*` :-- can be used to ephasis words in speech
* `\<switch>` :-- at end of the line indicates how entire sentence
should be carried out
 * `You must reallly love to be a good guy /s`
* `"scare quotes"` :-- Or maybe sarcasm is better done as scare quotes
`"` around the sarcastic expression?
* `:D` :-- emotion icons can perhaps be used to indicate previous
statement should be carried out in a certain tone. e.g. ` This really
doesn't make me feel good D: `
* `--> #id <--` :-- Allows the speaker to 'point' to a particular
section in a page?

What is your thoughts on this? If this can be included alongside or
inline with a markdown page, it might have some useful applications,
like say a modifiable automatic lecturer.

----

Here's a link to the current discussion page:

http://www.reddit.com/r/LightWeightMarkup/comments/2k6hfk/speech_synthesis_markdown_language/

From dev+ietf at seantek.com  Fri Oct 24 15:46:36 2014
From: dev+ietf at seantek.com (Sean Leonard)
Date: Fri, 24 Oct 2014 12:46:36 -0700
Subject: Using fragment identifiers with Markdown docs
Message-ID: <544AAC9C.9070004@seantek.com>

Hi Markdown folks:

I wanted to see if people have feelings or opinions about using fragment 
identifiers with Markdown (and Markdown-derivative, such as pandoc, 
kramdown, etc.) content.

It is useful to say things like

readme.md#how-to-install

So that a Markdown editor could scroll to the right content.

To my mind, the prime candidates for this treatment are the [link 
reference identifiers][lref] and for some formats, the attributed text 
{#blahblah }. Link reference identifiers are part of the original 
Markdown syntax. On the other hand, they don't produce any identifiers 
in HTML/XHTML. Clearly attributed text is useful to identify both 
Markdown and output regions.

[lref]: http://daringfireball.net/projects/markdown/syntax#link

Thanks,

Sean

From fletcher at fletcherpenney.net  Fri Oct 24 17:07:47 2014
From: fletcher at fletcherpenney.net (Fletcher T. Penney)
Date: Fri, 24 Oct 2014 17:07:47 -0400
Subject: Using fragment identifiers with Markdown docs
In-Reply-To: <544AAC9C.9070004@seantek.com>
References: <544AAC9C.9070004@seantek.com>
Message-ID: <544ABFA3.5050702@fletcherpenney.net>

 > So that a Markdown editor could scroll to the right content.

Do any such editors exist?  It seems to me that the way to approach this 
is to build such an editor and offer the feature.  If people like it, 
other editors may be built to offer the feature as well.  If not, it 
probably wouldn't take off.

MultiMarkdown (and others) already offer automatic label generation (for 
HTML, LaTeX, others) that allow "linking" within the output document. 
I'm not aware of any editors that do this (directly) on the raw text 
side, but MultiMarkdown Composer (and others) offer the Table of 
Contents approach, and Composer allows you to accurately synchronize 
scrolling between the HTML and raw text, so internal links can be used 
to navigate the document already.

F-

On 10/24/14, 3:46 PM, Sean Leonard wrote:
> Hi Markdown folks:
>
> I wanted to see if people have feelings or opinions about using fragment
> identifiers with Markdown (and Markdown-derivative, such as pandoc,
> kramdown, etc.) content.
>
> It is useful to say things like
>
> readme.md#how-to-install
>
> So that a Markdown editor could scroll to the right content.
>
> To my mind, the prime candidates for this treatment are the [link
> reference identifiers][lref] and for some formats, the attributed text
> {#blahblah }. Link reference identifiers are part of the original
> Markdown syntax. On the other hand, they don't produce any identifiers
> in HTML/XHTML. Clearly attributed text is useful to identify both
> Markdown and output regions.
>
> [lref]: http://daringfireball.net/projects/markdown/syntax#link
>
> Thanks,
>
> Sean
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss

-- 
Fletcher T. Penney
fletcher at fletcherpenney.net

From bowerbird at aol.com  Fri Oct 24 18:51:59 2014
From: bowerbird at aol.com (bowerbird)
Date: Fri, 24 Oct 2014 18:51:59 -0400
Subject: Using fragment identifiers with Markdown docs
Message-ID: <8D1BDF440BF09EE-F54-E103@webmail-vm160.sysops.aol.com>

sean said:
>   It is useful to say things like
>   readme.md#how-to-install
>   So that a Markdown editor
>   could scroll to the right content.

yes. indeed, that's a useful feature
in many contexts, including ones
where no such id exists in the .html.

see:
>   
https://medium.com/@bbirdiman/lets-please-use-hashtag-terms-to-create-_arbitrary_-deep-links-f9185d5da2f0

a little bit of javascript can go a long way.

***

>   Do any such editors exist?

some of my tools have this type of sync functionality.

and even if none _do_ exist, they certainly _could_.

so i don't really see the usefulness of such a question.


>   MultiMarkdown (and others) already offer
>   automatic label generation (for HTML, LaTeX, others)
>   that allow "linking" within the output document.

unfortunately, however, there is some disagreement
on the format that is used for such automatic labels,
so neither users nor developers can depend on them.

does this sound like a familiar type of problem?

and is it any surprise the developers themselves
seem not to know about these inconsistencies?


>   I'm not aware of any editors that do this (directly)
>   on the raw text side, but MultiMarkdown Composer
>   (and others) offer the Table of Contents approach,
>   and Composer allows you to accurately synchronize
>   scrolling between the HTML and raw text, so internal
>   links can be used to navigate the document already.

more or less, kind of, yes. but not exactly that, not really.

but there's no reason such functionality can't be offered.

indeed, it's easy. john macfarlane asked, a while back,
how to do it, and i gave him the 4-point pseudo-code...

>   
https://pairlist6.pair.net/pipermail/markdown-discuss/2014-August/003110.html

-bowerbird


From bowerbird at aol.com  Mon Oct 27 19:13:28 2014
From: bowerbird at aol.com (bowerbird)
Date: Mon, 27 Oct 2014 19:13:28 -0400
Subject: the issue with markdown was that it was too simple
Message-ID: <8D1C052C02B17E0-F54-1ADEF@webmail-vm160.sysops.aol.com>

>   
https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272
>   scott chacon, github cofounder, author of "pro git", on release of 
the second edition

>   The issue with Markdown was that it was too simple.
>   It didn?t specify things like table formatting, cross references,
>   indexing, callouts, source code examples, etc.
>   All of which Asciidoc does in a format that is just as easy to 
write.

if you want to correct someone, correct scott chacon. he said it, not 
me.

-bowerbird


From cuyfalls at hotmail.com  Tue Oct 28 12:06:46 2014
From: cuyfalls at hotmail.com (Virgil Arrington)
Date: Tue, 28 Oct 2014 12:06:46 -0400
Subject: SmartyPants and dashes
Message-ID: <BLU436-SMTP229B9A494D1D06CAC24B464D49F0@phx.gbl>

Please bear with me as I am just a user and, by no means, a developer. 
However, I've noticed some inconsistent behavior among different 
implementations of SmartyPants when it comes to en-dashes and em-dashes.

**1. Calibre 2.7*

*When I recently uploaded a Markdown source file to Calibre and selected 
its "Smarten punctuation" feature, it converted a double-hyphen "--" 
into an em-dash, and a triple hyphen "---" into an en-dash. This 
behavior was the opposite that I have come to expect using both LaTeX 
and ReText, my default Markdown editor.

I reported the matter as a Calibre bug, but received a response saying 
that the Calibre behavior was based on the official SmartyPants source 
code, which states as follows:

"The string, with each instance of "--" translated to an em-dash HTML 
entity, and each "---" translated to an en-dash HTML entity. Two reasons 
why: First, unlike the en- and em-dash syntax supported by 
EducateDashesOldSchool(), it's compatible with existing entries written 
before SmartyPants 1.1, back when "--" was only used for em-dashes. 
Second, em-dashes are more common than en-dashes, and so it sort of 
makes sense that the shortcut should be shorter to type. (Thanks to 
Aaron Swartz for the idea.)*"

*Confused by this, I tested two other methods of using SmartyPants, and 
received inconsistent results.

*2**. Python Markdown v2.5.1*

I use ReText as my Markdown editor. It uses the Smartypants extension 
that is provided with Python Markdown v2.5.1. It translates "--" as an 
endash and "---" as an emdash, the *opposite* as Calibre. Below is the 
translation table found at 
https://pythonhosted.org/Markdown/extensions/smarty.html

ASCII symbol 	Replacements 	HTML Entities 	Substitution Keys
|'| 	' ' 	|&lsquo;| |&rsquo;| 	|'left-single-quote'|, 
|'right-single-quote'|
|"| 	" " 	|&ldquo;| |&rdquo;| 	|'left-double-quote'|, 
|'right-double-quote'|
|<< >>| 	? ? 	|&laquo;| |&raquo;| 	|'left-angle-quote'|, 
|'right-angle-quote'|
|...| 	... 	|&hellip;| 	|'ellipsis'|
|--| 	-- 	|&ndash;| 	|'ndash'|
|---| 	--- 	|&mdash;| 	|'mdash'|


At the bottom of the Python/SmartyPants extension page is the following:

"SmartyPants extension is based on the original SmartyPants 
implementation by John Gruber. Please read it's documentation 
<http://daringfireball.net/projects/smartypants/> for details."

Based on this, I went to Gruber's page and got yet more inconsistency.

*3. SmartyPants by John Gruber.*

At Gruber's SmartyPants page, 
(http://daringfireball.net/projects/smartypants/) the following is found:

"SmartyPants can perform the following transformations:

  * Straight quotes ( " and ' ) into "curly" quote HTML entities
  * Backticks-style quotes (|``like this''|) into "curly" quote HTML
    entities
  * *Dashes ("**|--|**" and "**|---|**") into en- and em-dash entities *
  * **Three consecutive dots ("|...|") into an ellipsis entity"

Based on the order of the dashes listed, it would appear as if Gruber is 
suggesting that "--" would turn into an en-dash, and "---" into an 
em-dash (consistent with ReText, but not with Calibre). But, if I use 
Gruber's online Dingus translator 
(http://daringfireball.net/projects/markdown/dingus), I get yet a third 
variation of the conversion. Gruber's online translator converts "--" 
into an em-dash (as does Calibre) /but/ it turns "---" into an em-dash 
plus a hyphen (no en-dash).

There appears to be either confusion or disagreement in the 
Markdown/SmartyPants world as to how to create typographic dashes. Is 
there any way that the developers can come together on this very small 
part of the Markdown world?

Virgil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141028/52f9791c/attachment.html>

From michel.fortin at michelf.ca  Tue Oct 28 12:54:00 2014
From: michel.fortin at michelf.ca (Michel Fortin)
Date: Tue, 28 Oct 2014 12:54:00 -0400
Subject: SmartyPants and dashes
In-Reply-To: <BLU436-SMTP229B9A494D1D06CAC24B464D49F0@phx.gbl>
References: <BLU436-SMTP229B9A494D1D06CAC24B464D49F0@phx.gbl>
Message-ID: <D3B8C71C-6358-484F-B43F-250D9DF586D3@michelf.ca>

Le 28-oct.-2014 ? 12:06, Virgil Arrington <cuyfalls at hotmail.com> a ?crit :

> There appears to be either confusion or disagreement in the Markdown/SmartyPants world as to how to create typographic dashes. Is there any way that the developers can come together on this very small part of the Markdown world

SmartyPants, the original by John Gruber, has a configuration string that lets you configure it the way you like. You are right that the default configuration does not do anything with `---` (hence why it sees it as an em dash followed by a hyphen).

The configuration string is only documented in the code, but it's quite simple:

	#
	# Parser attributes:
	# 0 : do nothing
	# 1 : set all
	# 2 : set all, using old school en- and em- dash shortcuts
	# 3 : set all, using inverted old school en and em- dash shortcuts
	# 
	# q : quotes
	# b : backtick quotes (``double'' only)
	# B : backtick quotes (``double'' and `single')
	# d : dashes
	# D : old school dashes
	# i : inverted old school dashes
	# e : ellipses
	# w : convert &quot; entities to " for Dreamweaver users
	#

Looks to me like other implementations are using a different configuration by default.


-- 
Michel Fortin
michel.fortin at michelf.ca
https://michelf.ca

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4154 bytes
Desc: not available
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141028/aa3a7b7a/attachment.bin>

From fletcher at fletcherpenney.net  Tue Oct 28 13:16:42 2014
From: fletcher at fletcherpenney.net (Fletcher T. Penney)
Date: Tue, 28 Oct 2014 13:16:42 -0400
Subject: SmartyPants and dashes
In-Reply-To: <D3B8C71C-6358-484F-B43F-250D9DF586D3@michelf.ca>
References: <BLU436-SMTP229B9A494D1D06CAC24B464D49F0@phx.gbl>
 <D3B8C71C-6358-484F-B43F-250D9DF586D3@michelf.ca>
Message-ID: <544FCF7A.5000709@fletcherpenney.net>

FWIW, MultiMarkdown has always used `--` as en-dash, and `---` as 
em-dash, and I have never (to my recollection) had anyone contact me 
about it.

As a user, I would be quite confused trying to remember that the shorter 
abbreviation represents the longer dash, and vice-versa.  That seems 
very "anti-Markdown".

F-

On 10/28/14, 12:54 PM, Michel Fortin wrote:
> Le 28-oct.-2014 ? 12:06, Virgil Arrington <cuyfalls at hotmail.com> a ?crit :
>
>> There appears to be either confusion or disagreement in the Markdown/SmartyPants world as to how to create typographic dashes. Is there any way that the developers can come together on this very small part of the Markdown world
>
> SmartyPants, the original by John Gruber, has a configuration string that lets you configure it the way you like. You are right that the default configuration does not do anything with `---` (hence why it sees it as an em dash followed by a hyphen).
>
> The configuration string is only documented in the code, but it's quite simple:
>
> 	#
> 	# Parser attributes:
> 	# 0 : do nothing
> 	# 1 : set all
> 	# 2 : set all, using old school en- and em- dash shortcuts
> 	# 3 : set all, using inverted old school en and em- dash shortcuts
> 	#
> 	# q : quotes
> 	# b : backtick quotes (``double'' only)
> 	# B : backtick quotes (``double'' and `single')
> 	# d : dashes
> 	# D : old school dashes
> 	# i : inverted old school dashes
> 	# e : ellipses
> 	# w : convert &quot; entities to " for Dreamweaver users
> 	#
>
> Looks to me like other implementations are using a different configuration by default.
>
>
>
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
>

-- 
Fletcher T. Penney
fletcher at fletcherpenney.net

From waylan.limberg at icloud.com  Tue Oct 28 19:45:44 2014
From: waylan.limberg at icloud.com (Waylan Limberg)
Date: Tue, 28 Oct 2014 19:45:44 -0400
Subject: SmartyPants and dashes
In-Reply-To: <BLU436-SMTP229B9A494D1D06CAC24B464D49F0@phx.gbl>
References: <BLU436-SMTP229B9A494D1D06CAC24B464D49F0@phx.gbl>
Message-ID: <005801cff309$4ae21720$e0a64560$@icloud.com>

While Calibre does in fact use Python-Markdown, they do not use our
SmartyPants extension, which is relatively new. Instead they use the
standalone SmartyPants Python library [1] (see source here [2]) which uses
the same default as the original Perl implementation and has been around for
a long time. The Python library's documentation restates [3] the comments in
the Perl implementation.

 

Interestingly, that behavior is labeled as "oldschool"  **and** it is the
default. Probably kept the old behavior for backward compatibility. Don't
want to break all the old existing documents. Of course, new users can
override the defaults and start fresh with new documents using the behavior
that actually makes sense ("--" and "---" to en- and em-dash entities
respectively). That said, Calibre has been around for a long time and has a
pretty big user base, so I suppose it makes sense for them to stick with the
old behavior.

 

I think your confusion comes from the fact that the documentation doesn't
exactly make it clear that the "oldschool" behavior is the default. In fact,
the docs for the original Perl implementation don't even mention the
"oldschool" behavior, but the implementation clearly has support for it as
evidenced by the Dingus. In fact, I just noticed that the version available
for download [4] is 1.5.1 but the version used by the Dingus [5] is 1.6.0b6
(which is presumably newer). Why? Only J.G. can answer that. The good news
is that the implementation you care about (the one used by Calibre - which
you are using) is fully documented. So I would suggest using that
documentation for SmartyPants.

 

As an aside, when we reimplemented SmartyPants as a Python-Markdown
extension, we only implemented the newer behavior. We don't even offer the
option to revert to the "oldschool" behavior - unless you want to override
the relevant "Substitution Keys" manually (although we offer that
customization for another purpose - to support other languages which have
different rules than English).

 

I hope that helps clear things up a little.

 

Waylan Limberg

 

[1]: http://pythonhosted.org/smartypants/index.html

[2]:
https://github.com/kovidgoyal/calibre/blob/master/src/calibre/ebooks/convers
ion/preprocess.py#L76

[3]:
http://pythonhosted.org/smartypants/reference.html#smartypants.convert_dashe
s_oldschool_inverted

[4]: http://daringfireball.net/projects/smartypants/

[5]: http://daringfireball.net/projects/markdown/dingus

 

 

From: Markdown-Discuss [mailto:markdown-discuss-bounces at six.pairlist.net] On
Behalf Of Virgil Arrington
Sent: Tuesday, October 28, 2014 12:07 PM
To: markdown-discuss at six.pairlist.net
Subject: SmartyPants and dashes

 

Please bear with me as I am just a user and, by no means, a developer.
However, I've noticed some inconsistent behavior among different
implementations of SmartyPants when it comes to en-dashes and em-dashes.

1. Calibre 2.7

When I recently uploaded a Markdown source file to Calibre and selected its
"Smarten punctuation" feature, it converted a double-hyphen "--" into an
em-dash, and a triple hyphen "---" into an en-dash. This behavior was the
opposite that I have come to expect using both LaTeX and ReText, my default
Markdown editor.

I reported the matter as a Calibre bug, but received a response saying that
the Calibre behavior was based on the official SmartyPants source code,
which states as follows:

"The string, with each instance of "--" translated to an em-dash HTML
entity, and each "---" translated to an en-dash HTML entity. Two reasons
why: First, unlike the en- and em-dash syntax supported by
EducateDashesOldSchool(), it's compatible with existing entries written
before SmartyPants 1.1, back when "--" was only used for em-dashes. Second,
em-dashes are more common than en-dashes, and so it sort of makes sense that
the shortcut should be shorter to type. (Thanks to Aaron Swartz for the
idea.)"

Confused by this, I tested two other methods of using SmartyPants, and
received inconsistent results.

2. Python Markdown v2.5.1

I use ReText as my Markdown editor. It uses the Smartypants extension that
is provided with Python Markdown v2.5.1. It translates "--" as an endash and
"---" as an emdash, the *opposite* as Calibre. Below is the translation
table found at https://pythonhosted.org/Markdown/extensions/smarty.html


ASCII symbol

Replacements

HTML Entities

Substitution Keys


'

' '

&lsquo; &rsquo;

'left-single-quote', 'right-single-quote'


"

" "

&ldquo; &rdquo;

'left-double-quote', 'right-double-quote'


<< >>

< >

&laquo; &raquo;

'left-angle-quote', 'right-angle-quote'


...

.

&hellip;

'ellipsis'


--

-

&ndash;

'ndash'


---

-

&mdash;

'mdash'


At the bottom of the Python/SmartyPants extension page is the following:

"SmartyPants extension is based on the original SmartyPants implementation
by John Gruber. Please read it's documentation
<http://daringfireball.net/projects/smartypants/>  for details."

Based on this, I went to Gruber's page and got yet more inconsistency.

3. SmartyPants by John Gruber.

At Gruber's SmartyPants page,
(http://daringfireball.net/projects/smartypants/) the following is found:

"SmartyPants can perform the following transformations: 

*	Straight quotes ( " and ' ) into "curly" quote HTML entities 
*	Backticks-style quotes (``like this'') into "curly" quote HTML
entities 
*	Dashes ("--" and "---") into en- and em-dash entities 
*	Three consecutive dots ("...") into an ellipsis entity"

Based on the order of the dashes listed, it would appear as if Gruber is
suggesting that "--" would turn into an en-dash, and "---" into an em-dash
(consistent with ReText, but not with Calibre). But, if I use Gruber's
online Dingus translator
(http://daringfireball.net/projects/markdown/dingus), I get yet a third
variation of the conversion. Gruber's online translator converts "--" into
an em-dash (as does Calibre) but it turns "---" into an em-dash plus a
hyphen (no en-dash). 

There appears to be either confusion or disagreement in the
Markdown/SmartyPants world as to how to create typographic dashes. Is there
any way that the developers can come together on this very small part of the
Markdown world?

Virgil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist6.pair.net/pipermail/markdown-discuss/attachments/20141028/c3cf856e/attachment-0001.html>

From bowerbird at aol.com  Fri Oct 31 19:58:25 2014
From: bowerbird at aol.com (bowerbird)
Date: Fri, 31 Oct 2014 19:58:25 -0400
Subject: 
Message-ID: <8D1C37DB188785B-12EC-32322@webmail-vm187.sysops.aol.com>

virgil said:
>   Is  there any way that the developers can come
>   together on this very small part of the Markdown world?

i'd have to say it looks like your answer is "no", virgil.

if it's any consolation, it's not you; it's always like this.

have a nice weekend.

have a nice november.

have a nice 2014...

-bowerbird


From cuyfalls at hotmail.com  Fri Oct 31 21:38:52 2014
From: cuyfalls at hotmail.com (Virgil Arrington)
Date: Fri, 31 Oct 2014 21:38:52 -0400
Subject: 
In-Reply-To: <8D1C37DB188785B-12EC-32322@webmail-vm187.sysops.aol.com>
References: <8D1C37DB188785B-12EC-32322@webmail-vm187.sysops.aol.com>
Message-ID: <BLU437-SMTP34F1A4B6C0AFDAE8D5ADEAD49B0@phx.gbl>


On 10/31/2014 7:58 PM, bowerbird via Markdown-Discuss wrote:
> virgil said:
>>    Is  there any way that the developers can come
>>    together on this very small part of the Markdown world?
> i'd have to say it looks like your answer is "no", virgil.
>
>

Yes, I've already realized it. It's a shame because it diminishes one of 
the attractions of Markdown -- its portability across editors and 
systems. Now, before I type anything in Markdown, I have to ask, will I 
parse this in ReText, with Python Markdown, or in Calibre (with "old 
school" SmartyPants). Then I have to type my "--"s and "---"s accordingly.

Happy Halloween all.

Virgil