Moving Markdown towards a standard syntax

[Waylan Limberg]

-----Original Message-----
From: Markdown-Discuss [mailto:markdown-discuss-bounces at six.pairlist.net] On
Behalf Of John MacFarlane
Sent: Thursday, August 14, 2014 2:10 PM
To: Discussion related to Markdown.
Subject: Re: Moving Markdown towards a standard syntax

> Here's an attempt of my own, which I've been working on for some time:
http://jgm.github.io/stmd/


Interesting. You appear to mostly be tightening up the existing rules, with
only a few deviations. I have little of value to say about most of it, so
only a few observations follow.

" Tabs in lines are expanded to spaces, with a tab stop of 4 characters." We
strictly enforce this rule in Python-Markdown and I like it, but we have
received bug reports from time to time that certain languages require tabs
(spaces would be a syntax error). I think makefiles would be the most
well-known example. For example, how would you expect someone to be able to
copy from a code block in a blog post and paste into a makefile without
needing to go back and edit all the whitespace? If they are copy and
pasting, they are not likely to be an advanced user and significant
whitespace it already one of the most non-obvious gotchas. Just an
observation here. The answer isn't clear to me either.

I notice that you state that an HTML block ends with a blank line. I have
always wished that it worked that way for the very reasons you cited. As you
observe, things like  raw `<pre>` blocks can't have blank lines (might want
to add comments, processing instructions and CDATA to that list along with
workarounds??). Either way is a compromise and it is not clear to me which
is the better way to go.

" A blank line always separates block quotes" Brilliant!

I absolutely love what you did with how much indentation indicates nesting
within a list (for all block elements, not just nested lists). However, I
expect most people will have trouble getting it right in practice. And I
wouldn't want to write a parser for that. But I sure would enjoy writing
lists with it.

" Two blank lines will end a list." Really? What about a code block nested
within a list item that contains multiple blank lines? If it wasn't for that
corner case, I would love this two. Or it there an exception for that?
Example 198 seems to indicate so, but I don't see it explicitly stated
anywhere. Is it for fenced code blocks only (because you can look for the
closing fence -- if so, makes sense to me) or does it work with indented
code blocks also?

" Changing the bullet or ordered list delimiter starts a new list." As it
should. Also like the start number being set on ordered lists.

" A backslash at the end of the line is a hard line break." Brilliant! I see
you preserved the 'two spaces' rule. You changed some other things (like
list nesting) enough that backward compatibility with existing docs
shouldn't be a concern. Therefore, I'm not sure we need both.

Every implementation should follow your strong/emphasis spec. All
implementers go change your implementations now... oh wait, that means more
work for me...

If I understand you correctly, all autolinks must be surrounded by angle
brackets (the right call btw). Perhaps you should include a url **without**
angle brackets in your list of "not autolinks" to make that clear.

That must have been am incredible amount of work. I'm only concerned that
it's not really markdown anymore. I'd be tempted to  take it that extra step
and get rid of all the other things that could be slightly better and call
it something else. Of course, I don't see some new plain text markup
language taking off now that markdown it so widespread. But it is fun to
think about.

Waylan Limberg