Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Waylan L. <wa...@gm...>]

Thanks for the feedback Ron. I've responded you your concerns below to
keep things in context.

On Mon, Mar 23, 2009 at 3:19 PM, Ron Garret <ron...@gm...> wrote:
> My pleasure.  Thanks for the code :-)
>
> Couple of comments.  These are really design issues, not bugs, but FWIW:
>
> 1.  The wikilink behavior has changed in a non-backwards-compatible way.
>  Before, [[WikiLink]] and [[wiki link]] were equivalent.  Now they are not.
>  Personally, I preferred the old way.

What was the old way? I don't remember changing that. Could you
provide an example of the current output and the expected output?

> 2.  I don't like PHP table syntax because it makes it impossible to create a
> table without headers.  I know this has been discussed before (though have
> not been able to find that discussion -- can someone send me a pointer?) so
> maybe there's a sound reason for choosing this syntax over some of the
> alternatives, but at the moment I can't think what it might be.

Well, the reason is that this (PHP) is an already existing and highly
distributed implementation. The idea is that one should be able to
pass the same source documents through any implementation and get back
the same result. So, I went with an already existing implementation.

I was originally going to add in the option to allow tables without
headers, but that presented the problem of how to define column
alignment and I didn't want to introduce new syntax. On further
reflection, I realized that the purpose of a table (in Markdown even
more so than HTML) should only be for tabular data, and when does
tabular data not have column headers? I suppose it's possible, but
very unlikely. I suspect that is why the PHP implementation is so
restrictive in that regard.

Oh, you asked for a pointer to a previous discussion. Um, check the
markdown list [1]. There was a recent discussion regarding table
syntax with all sorts of alternatives discussed, but in the end, most
of it was more complex that what fits with the Markdown philosophy. So
I ignored those suggestions and went with what I believe to be the
mostly widely used existing implementation.

[1]: http://six.pairlist.net/pipermail/markdown-discuss/

> One good thing about the new code is that it's really easy for me to change
> these things myself.  :-)

And it is for that very reason that I left the syntax as-is. Anyone
can build upon the existing base - or even start over from scratch.

> I mention them only in case there's a desire to
> prevent people from branching too much.

Anyone is encouraged to branch and create their own extensions. That
is part of the point of our extension API. In fact, the extension API
is what we pride ourselves in most with the project - even before
performance. But, yeah, the default implementation isn't going to
branch to far from the existing standard for the reasons mentioned
above.

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg