Not only is [Markdown] dead, it's starting to smell really bad. (Apologies to Pike.) It's author appears to have little interest in developing the tool and participating in the community which uses it. I'd like to see the community cooperate toward a specification which addresses the shortcomings and ambiguities of Markdown (even if it need be released under a new name).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1> I'd like to see the community cooperate toward a specification which > addresses the shortcomings and ambiguities of Markdown (even if it > need be released under a new name).I'll second that. Though it would be best if we could still use the Markdown name; a different one would just make one more confusing text-markup specification for people to ignore. If we could call it Markdown2 or something similar, it would be obvious that it expands on, and supersedes, the original Markdown. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRUZ8ACgkQp9x9jeZ9/wThdgCgvtogv2EWD8ooaXZAvWNUDrf0 kowAnjuoh9F9HmXJMGN3neAOauQG8AEP =72Eb -----END PGP SIGNATURE-----
In article <20100305103250714488.328757f2 at yahoo.co.uk>, Albert Skye <markdown-discuss at six.pairlist.net> wrote:>Not only is [Markdown] dead, it's starting to smell really bad. (Apologies to Pike.)There are some hilarious edge/pathological cases which Markdown.pl doesn't get right, but for the most part it works and if the places where it doesn't work are offensive, there are literally dozens of other implementations out there that have been tweaked more recently than Markdown.pl>It's author appears to have little interest in developing the tool and >participating in the community which uses it.He's got a Perl implementation that works for him, and there are many other implementations that are basically compatable with his code & test suites. There's not much he needs to do, so why should he run around and do busywork? -david parsons
> I'd like to see the community cooperate toward a specification which > addresses the shortcomings and ambiguities of Markdown (even if it > need be released under a new name).Not a spec for Markdown itself, but for a superset of Markdown: http://kramdown.rubyforge.org/syntax.html I tried to address most ambiguities, especially in list parsing. -- Thomas
> Is there a way Gruber could "anoint" someone ...Yikes, this sounds ... ;} I think the community can just cooperate and develop a common tool. It need not be called "Markdown" nor strictly supeset Markdown. It simply needs to be useful to the community. It needs no *one* to control it but without cooperation we may as well follow our own forks. A wiki (with Markdown syntax of course) might be useful for such development.
In article <20100316235613572049.1a73eb5b at yahoo.co.uk>, Albert Skye <markdown-discuss at six.pairlist.net> wrote:>> Is there a way Gruber could "anoint" someone ... > >Yikes, this sounds ... ;} > >I think the community can just cooperate and develop a common tool.There are markdown implementations in a dozen languages. I am unsure about how a common tool can be made here. -david parsons
2010/3/17 david parsons <orc at pell.chi.il.us>:> > ? There are markdown implementations in a dozen languages. ? I am > ? unsure about how a common tool can be made here. >What I would really like to see is a standard test suite, with a given input and the expected output, which we can test against the different implementations. Then, we would only have to agree on a "core" set of tests that every implementation has to pass to be considered "markdown compatible" and we could easily add tests for non-standard features. The difficult part is to decide if the most strange corner cases are implementation dependent, or how they must be handled (since I expect some differences between current implementations). Mdtest is probably the best starting point for such a task. -- - yy.
lou said:> Markdown's dead?? Absurd.? Markdown's huge, > and in the form of PHP Markdown Extra is basically done.? > Done != dead, done == problem solved._your_ problem not necessarily included. batteries sold separately. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100320/a47e11e4/attachment.html>
lou said:> And, again, it's always been part of the bargain that > you must wrap the transformer if you need special shitwhere some values of "special shit" are spectacularly ordinary... not available in stores. your mileage might vary. have a nice day. -bowerbird p.s. see what gruber does on his blog. capability-wise, it's bland. the most "special" he does is footnotes, and he hand-rolls those. p.p.s. but honestly, it's really not what markdown out-of-the-box _fails_ to do automatically. it's how much work it takes for you to do those things manually. at some point, for any "special shit", you will feel like you've done so much markup anyway that you might as well have just done it _all_ in .html from the beginning. that is, as "light" markup, markdown simply isn't "light" enough. i do not necessarily mean for this to sound like a criticism, but in my work, i've been aiming at something much, much lighter. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100323/498d57aa/attachment.htm>
albert said:> http://nickgravgaard.com/elastictabstops/for the win! (i'd been wondering when someone would mention that again; i looked and couldn't find the u.r.l.) any further dialogs about tables should be shortcircuited with this link. there's simply nothing to discuss any more. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100323/63500ac1/attachment.html>
sherwood said:> I don't understand.what's to understand? :+)> Are you saying that MD should recognize elastic tab stops > in a file and convert that to a html table?yes, that's what i'm saying, or at least part of it.> This is certainly a possible route, but given > the number of editors that don't recognize > elastic tab stops, this is daunting.at some point, you have to free yourself from the constraints that low-quality software imposes on your workflow, yes sir... but, you know, all it takes is for one brave leader to _lead_, and a number of non-cowardly followers to _follow_, and -- before you know it -- a new capability is taken for granted.> It also means that MD needs to recognize > at least two ways to do tables -- ets and markup.well, if you want to keep a horse around in addition to your new horseless carriage, by all means, feel free... ;+)> Are you saying that browsers should all be smart enough > to recognize elastic tab stops?yes. every text-editing environment should have the capability. because -- if you've programmed it, like i have -- you'll know that it's really not all that difficult to code. indeed, it's easy... and although i don't remember this in the work-up on them (because i conceived them long before that, independently), this functionality should include a feature that will convert multiple spaces to a tab character (the easy part) as well as convert a tab to the "correct" number of multiple spaces... (e.g., so the table displays correctly in a monospaced font). i'd think the default save-format would be multiple-spaces, just to accommodate the non-tab-aware software out there. there's nothing "magical" about this functionality. it's just a straightforward implementation of old-fashioned tabs, with the new wrinkle that the columns are self-adjusting to the size they need to be. which is something we could have reasonably expected our computers to do all along... (indeed, isn't this capability already in most spreadsheets?)> While an admirable goal, I won't hold my breath for the day > that 95% of browsing is done with ETS capable browsers.i'm not holding my breath for 95% of browsers being _capable_, in _any_ sense of the word, not as long as we have a microsoft... but in cost-benefit terms, cost being low, benefits being high, this particular feature is one that has a good cost-benefit ratio. all it will take is for somebody out front to "just do it"... this is _not_ a betamax/vhs situation. vhs was "good enough". nobody says our current table functionality is "good enough". -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100324/dbe3f2fe/attachment.html>
sherwood said:> The bowerbird is half right.? > Elastic tab stops are worthy of implementing. > But to keep the transition cost minimal > the older way has to be supported also.well, no, actually, i'm _completely_ right... since i never said to jettison the older way. :+) (which is why david's comment makes no sense.) we could certainly say that "markdown supports elastic tabs" and leave it to the various coders to decide for themselves whether _they_ support it. although even after everyone fully implements elastic tabs, we can still support "the older way". horses are fun to ride sometimes... *** seumas said:> You're not really talking tables here though, > you're talking self-aligning columns of text. > That is not the same thing as an html table, > even though that is what tables are often used for.we start with self-aligning columns of text, yes. but it's certainly possible to extend from there... of course you can probably sketch out some table that would be impossible for us to handle nicely, in which case we'd have to back off and use .html. but -- as far as i can see, do tell me if i'm wrong -- that's the suggestion for what we should always do, which i do not find to be a compelling alternative... ***> Elastic tab stops are not a new concept. > Some people tried to lead, nobody followed.yet we are still talking about how to do tables...> I have programmed them to, because > I loved the concept, but it was not so easy. > It complicates the code, very much. > It is not difficult, but it gives very ugly results.i can handle "not so easy" as long as it's "not difficult". ;+) as for giving ugly results, that's not true of _my_ code.> When I'm rendering text I don't want to have to > scan the whole file just to adjust tab stops, > as sometimes happen.i treat every table independently, so i only have to scan through to the end of the table to set the tabs.> In fact, I prefer not having to look ahead at all.well, gee, i read the whole file in advance anyway, because it's impossible to do all the things i want without knowing what the entire file looks like... my first page must know the last page, intimately.> The main reason I implemented ets > was to use variable width fonts, and > those ones do not play well with > the spaces-tab conversion.monospaced spaces and proportional fonts cannot work well, by definition, i'm afraid...> How do you represent tabs in the output > of a tool like sed, for example? > It is not such an easy problem, really.sed needs to be programmed to do that, is all...> Spreadsheets used fixed width columns > last time I checked.i do believe that spreadsheets can self-adjust. and i'm almost certain that ms-word-tables can. although i am loathe to ever start up ms-word, i'll do so if you tell me you need me to verify it.> Somebody could arguee that > the fact that everybody is still using > the classical tab stops make them good enough.i'd love to hear someone argue that. i'd chuckle. :+) -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20100325/0d176a93/attachment.html>