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