<HTML><FONT FACE=arial,helvetica><HTML><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4">allan odgaard said:<BR>
&gt;&nbsp;&nbsp;  the specification seems fairly explicit:<BR>
<BR>
i must be badly misunderstanding something here,<BR>
because it appears, to me at least, that mr. odgaard<BR>
wants you to "standardize" on gruber's specification?<BR>
<BR>
that "specification" -- if you really want to call it that --<BR>
is so underpowered that such action would be laughable.<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  I think there are many who would like to <BR>
&gt;&nbsp;&nbsp;  see a formal/exhaustive specification<BR>
<BR>
if so, you'd have thought that there would be some<BR>
response to the various calls that have been made<BR>
to that effect on this listserve over the many years...<BR>
<BR>
but... nope...<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  and no-one can be happy about say, <BR>
&gt;&nbsp;&nbsp;  text editor syntax highlight doing it one way, <BR>
&gt;&nbsp;&nbsp;  the local preview showing it another, <BR>
&gt;&nbsp;&nbsp;  and when posting the document online, <BR>
&gt;&nbsp;&nbsp;  yet another interpretation is applied.<BR>
<BR>
and yet, absolutely nothing has been done about it.<BR>
<BR>
perplexing, isn't it?<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  The problem is partly that several want it to be <BR>
&gt;&nbsp;&nbsp;  about the user, so it doesn't matter there are <BR>
&gt;&nbsp;&nbsp;  30 lines of code to try and guess what the user meant, <BR>
&gt;&nbsp;&nbsp;  rather than have the user be more explicit (it is <BR>
&gt;&nbsp;&nbsp;  after all meant as sort of an anti-markup language).<BR>
<BR>
no, no, no, no, i don't think that's the problem at all.<BR>
<BR>
i think that everyone would agree that "30 lines of code"<BR>
would be a very small price to pay for user convenience.<BR>
<BR>
but "user convenience" is a lot different than "ambiguity".<BR>
<BR>
there's absolutely no reason in the world -- none! --<BR>
that you can't have _clarity_ and _user_convenience_...<BR>
<BR>
indeed, i see those two as working hand-in-hand...<BR>
<BR>
the easiest thing for the user to handle is a clear model.<BR>
<BR>
the hardest thing is to juggle two ambiguous models.<BR>
even juggling two _clear_ models is somewhat difficult.<BR>
<BR>
but one clear model, especially a simple one?&nbsp;  _easy_.<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  Another problem is that the majority of Markdown.pl <BR>
&gt;&nbsp;&nbsp;  derivatives are implemented as a long series of <BR>
&gt;&nbsp;&nbsp;  global substitutions running on the full document<BR>
<BR>
i have done things that way.&nbsp;  it works ok...&nbsp;  up to a point...<BR>
then it starts getting convoluted.&nbsp;  and eventually it breaks.<BR>
<BR>
it's not the best way to do it.&nbsp;  more to the point, once you<BR>
discover the best way, you realize it was a bad false-start.<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  this is far from a "real" parser so <BR>
&gt;&nbsp;&nbsp;  the maintainers will have to start from scratch<BR>
<BR>
when you're going down the wrong path, starting over<BR>
-- from scratch -- is the _best_ possible thing to do...<BR>
<BR>
i've started over from scratch 100 times...&nbsp;  or more...<BR>
<BR>
20% of those re-starts taught me something valuable.<BR>
and, after a while, all of those lessons start to add up.<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  this is far from a "real" parser so the maintainers will <BR>
&gt;&nbsp;&nbsp;  have to start from scratch and it's unlikely they can provide <BR>
&gt;&nbsp;&nbsp;  100% backwards compatibiity for their flavor of markdown<BR>
<BR>
i must be misunderstanding something again, because<BR>
it seems to me that mr. odgaard is saying that he wants<BR>
"100% backward compatibility" for each of the variants...<BR>
<BR>
or at least his own; but then each developer will say that,<BR>
which effectively means backward compatibility for _all_.<BR>
<BR>
but that's clearly impossible.&nbsp;  so he _can't_ be saying _that_.<BR>
<BR>
so i must be misunderstanding.&nbsp;  or maybe mr. odgaard is,<BR>
as it seems he can't even _spell_ "backwards compatibility".&nbsp;&nbsp;&nbsp;&nbsp;  ;+)<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  leading to close to no uptake.<BR>
<BR>
leave your old model in place if you want.&nbsp;  nobody here cares.<BR>
<BR>
but you won't get any "uptake" from _new_ users once everyone<BR>
comes to realize that your markdown variant lives on an island.<BR>
<BR>
heck, even your old users will start to abandon you then.<BR>
<BR>
so, if i were you, i'd put a conversion routine in place.&nbsp;  really.<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  If we want a formal specification, I think the best approach <BR>
&gt;&nbsp;&nbsp;  is a clean break from markdown.<BR>
<BR>
fine.&nbsp;  call it "multimarkdown" and be done with it.&nbsp;  that was easy.<BR>
<BR>
<BR>
&gt;&nbsp;&nbsp;  I've been contemplating this for a while, <BR>
&gt;&nbsp;&nbsp;  but with the current situation being fine <BR>
&gt;&nbsp;&nbsp;  most of the time for most of the people, <BR>
&gt;&nbsp;&nbsp;  it's one of those cases where it's hard to really justify <BR>
&gt;&nbsp;&nbsp;  the effort that goes into trying to change things.<BR>
<BR>
again, i can port my routines in a matter of a few hours, so<BR>
i don't understand why you pro coders find this so difficult...<BR>
<BR>
-bowerbird<BR>
</FONT><FONT COLOR="#000000" FACE="Lucida Grande" LANG="0" SIZE="4"></FONT></HTML>