Piero Wbmstr | 18 Nov 21:16 2014

Re: Announce: Markdown (extended) specifications

Hello Jakub,

I didn't know this project (I agree with you: there are already too many
MD projects ...).

I will look at CommonMark in details to see if I may help on this or
propose something like a "merge" of both CommonMark and MarkdownExtended
or anything else.

By the way, is there a place where all known MD projects are listed ?

Thank you for the info.


Le 18/11/2014 18:28, Jakub Jirutka a écrit :
> Hi Pierre,
> are you familiar with the [CommonMark project](http://commonmark.org)? It’s _de facto_
standardized Markdown with very precise [specification](http://spec.commonmark.org). If you wanna
extend Markdown syntax, then I highly recommend to start on top of this spec. No one needs yet another
incompatible and ambiguous Markdown dialect, there are too many of them already.
> Best regards,
>   Jakub Jirutka

(Continue reading)

Piero Wbmstr | 18 Nov 15:09 2014

Announce: Markdown (extended) specifications

Dear all,

I'm quite a newcomer to both the "markdown-discuss" mailing-list and the Markdown W3C Community Group. So first of all let me make a brief introduction: I am a french PHP developer and I work (from a long time now) on a Markdown parser that you can find at http://github.com/piwi/markdown-extended (this is not the subject of this email).

**I want here to announce that I'm working on writing specifications for a version of the syntax that I called "Markdown Extended" (to differentiate it from the "classic" one).**

I know some of you are against the idea of such specifications for various reasons ... I won't here try to convince you all about their usefulness, but I would appreciate to have your feedback and comments about this work before publishing it "officially". Those who are fundamentally against such specifications may notice that I tried to clearly separate the "Extended" syntax of the original. Let's consider that the Markdown Extended syntax has its specifications where classic Markdown doesn't.

**You can read the draft of this work at http://aboutmde.org/ which is actually in ´alpha´ version.**
**Please feel free to make some returns via this email or the bug tickets of the original repository (it is hosted on GitHub at http://github.com/markdown-extended/manifest).**

I want to thank in advance all those of you who might take a little time to read this work and give me a comeback.
Moreover, any contribution is welcome.

Kind regards,
-- Pierre Cassat
Markdown-Discuss mailing list
Markdown-Discuss <at> six.pairlist.net
Sean Leonard | 12 Nov 00:47 2014

Opinions on in-band variation signaling

Regarding the text/markdown registration:

At least one commentator (Larry Masinter) specifically requested that the variant identifier be
included in-band in the Markdown content, rather than as part of the metadata. I disagree with in-band
signaling (as has been registered earlier on this list). Nevertheless, I wanted to take a straw poll and
see if anyone has tried to implement in-band Markdown variation identifiers, with any success. Do any
implementers have experience with picking the type of Markdown based on some info at the top of the
Markdown content? Does it work—or will it never work? Or is it “bad” for particular reasons?

By in-band, I mean a Markdown file with content like this:

% This is a Title
% Sean Leonard
% November 2014

Blah blah *blah*.
<<< (fortin’s suggestion)

[!pandoc]: # "This is a pandoc document."
% This is a Title
% Sean Leonard
% November 2014

Blah blah *blah*.
<<< (seantek’s suggestion)

Sean Leonard | 12 Nov 00:44 2014

Progress on text/markdown at IETF 91

Hello Markdown Community:

There was discussion and progress on text/markdown at IETF 91. Here are slides:

and here are the interim minutes:

The view is that the syntax parameter of draft-03 should be simplified to a parameter currently called
“variant”, which is a simple US-ASCII case-insensitive identifier. Other considerations are
discussed on the apps-discuss IETF mailing list. The proposal was posted last week, and is below.

I will work on draft-04 over the next couple of weeks.



Optional Parameters:
variant: An optional identifier that serves as a “hint” to the recipient of the specific Markdown
variant that the author intended. When omitted, there is no hint; the interpretation is entirely up to the
receiver and context. This identifier is plain US-ASCII and case-insensitive. People who want interop
can optionally register them using a simple webform (IANA registry), which just asks for the Identifier,
a Description, and Contact Information. If a receiver does not recognize the variant identifier, the
receiver MAY present the identifier to a user to inform him or her of it.
Other parameters MAY be included with the media type. The semantics of such parameters MAY be defined by the
variant; they are not defined here. As an alternative, the variant MAY be registered under another media
type; this text/markdown registration does not preclude other registrations.

With the text above in the registration template, pretty much all of Section 3 (draft-03) would be
eliminated. Additionally, Section 6 (IANA Considerations) would be cut down to about 1/3 of its current size.

"Variant" means a lightweight markup language that differs in some respect from other Markdown-derived
languages. The purpose of a variant is to distinguish a given variation from other Markdown variations,
as well as from Gruber's original syntax specification and implementation, where two parties wish to
interoperate by implementing the common variation.

The IANA Registry shall be called "Markdown Variants". The intent of this name is to broaden the uses of
variant identifiers, so protocols that do not rely on Internet media types can still tag Markdown content
with a variant name. For example, a file can be named "file.pandoc.markdown", which could have the
equivalent meaning as "Content-Type: text/markdown; variant=pandoc". (Credit goes to Michel Fortin
for suggesting that the classification of variants have broader value than just the media type
registration; for example, in content management systems that do not use media types to classify formats.)
Jeff McNeill | 11 Nov 07:38 2014

Re: Markdown-Discuss Digest, Vol 139, Issue 3

> As a mere user, I've noticed the same thing. One of the purported 
> benefits of markdown is its portability, i.e., the ability of the user 
> to write in any editor, knowing that he can then load it into any number 
> of parsers and get consistent results.
> But, with all the different flavors out there, one now has to think, 
> "which parser will I use to convert this file?" and insert markdown 
> accordingly. I recently discovered at least four different ways in which 
> parsers deal with typographic quotes and dashes, from the original 
> SmartyPants to the Python Markdown implementation of SmartyPants to the 
> Calibre implementation of it to RMarkdown's implementation (not to 
> mention ReStructuredText and Textile, both of which do it differently, 
> yet). So, I have to commit to a given dialect and converter before I 
> begin to type. To me, that's defeating one of the fundamental purposes 
> of markdown.
> Virgil

I believe that is why a neutral, “Bland” Markdown recommendation is needed. Not as yet another parser
or syntax but as something to tell writers and editors to use, so that their content can be properly processed.

This is actually not too difficult. http://jeffmcneill.com/bland-markdown

Jeff McNeill 
Markdown-Discuss mailing list
Markdown-Discuss <at> six.pairlist.net

mou makes its funding goal for a 1.0 release

mou, as you may know, is a markdown editor.

with its second $5,000 company sponsorship,
mou has reached it's $20,000 indigogo goal...

albeit, the effort engendered some resistance:

the big thorn is that, because mou's developer
has lost interest in the project, trying to sell it,
a mou user stepped up to code an equivalent.

that led the mou developer to resume his effort,
issuing proclamations about "the crappy clones"
in his campaign to raise $20,000 to release 1.0.
(in all the time it's been out, mou's been "beta";
the goal to open-source the code is $100,000.)

i take no side in this dog-fight.

i have no argument with developers getting paid.

and i am not religious on the open-source sauce.

i even think open-source/proprietary tension can
-- in some cases -- create benefits for both sides.

i also believe in supporting developers who have
built a tool that i use constantly, like my text-editor.

i've paid the mere $15 asked by the tex-edit guy
several times, because i appreciate it that much.
i just paid it again, because i appreciate the app.
>   http://www.tex-edit.com

i'm curious, however, if anyone cares to voice any
opinion about how such tension should shake out.

because it's certainly possible to release code that
lets people have a light-markup editing environment.
i'm about to do that, on the way to doing other stuff,
just because it is nearly an inevitable consequence.

i'm sure you've all realized that there are a ton of
free web-based markdown editors out there today.

it's gonna be harder and harder, it seems to me, for
any app developers to "add value" to what's coming,
in a sufficient way so many users will end up paying.

but maybe i'm wrong?



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...

Virgil Arrington | 28 Oct 17:06 2014

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 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?

Markdown-Discuss mailing list
Markdown-Discuss <at> six.pairlist.net

the issue with markdown was that it was too simple

https://medium.com/ <at> 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 

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


Markdown-Discuss mailing list
Markdown-Discuss <at> six.pairlist.net
Sean Leonard | 24 Oct 21:46 2014

Using fragment identifiers with Markdown docs

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


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


mofo syne | 24 Oct 10:25 2014

markdown for speech synthesis?

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:

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: