evolving the spec (was: forking Markdown.pl?)

[Yuri Takhteyev]

>  Personally, some of the "holes" in the current syntax rules are

>  actually the "features" that makes this statement true. As

>  implementors, we want a strict spec because it's easier to implement,

>  but that does not always result in easier to read and/or write.


I don't see how ambiguity of the spec and the ease of reading and
writing are inherently linked.

The spec can say that the list must start with a "*" right after the
new line, or it can say that the * may be preceeded by up to 3 spaces,
or it can say that the * can be preceded by what any number of spaces.
 Let's pick the option that we find most readable and writable.  But
let's decide and make it clear.  Otherwise, whenever you move from one
implementation to another you'll have to learn which of those features
are supported and which are not.


>  item. While J.G. agreed (IIRC) that that probably is a bug that should

>  be fixed, we learned through the course of that conversation that a

>  number of people actually are relying on that "bug" as a "feature",


Well, let's have more of those conversations.  At this point many of
us have used markdown for several years and have opinions about what
works and what doesn't.  E.g., I am quite convinced (as I think Michel
is too) that italicizing_parts_of_words was a really bad idea.  I can
agree that historically the ambiguity of the spec have allowed for
some experimentation that was good.  But at this point I think we
might be better off settling on a spec.


>  > Markdown is not a replacement for HTML, or even close to it. Its syntax is

>  > very small, corresponding only to a very small subset of HTML tags. The

>  > idea is not to create a syntax that makes it easier to insert HTML tags.

>  > In my opinion, HTML tags are already easy to insert. The idea for

>  > Markdown is to make it easy to read, write, and edit prose.


Well, except that people use it for blogs and wikis and they need some
of those extra features, and if we don't agree on some of them (like
definition lists and tables) then we end up with a hundred different
ways of doing the same thing.  E.g., as was discussed a few weeks ago,
markdown's handling of code block is nice if you are editing your text
in an editor that supports block indentation, but is quite
disfunctional if you are doing it in a web form, especially if most of
your content is snippets of code.  We talked about this, and what now?
 Some people might go and implement an extension for {{{...}}} for
their favourite implementation.  Others will go and implement
something else.

- yuri

-- 
http://sputnik.freewisdom.org/