Gentlefolk, I have been thinking on Markdown's lack of "proper" table support for a long while now. Here's where I have arrived... ## I Don't Like HTML Tables It is often argued that embedded HTML is the way to markdown rich tables. Unfortunately, this contradicts the higher markdown ideal that a raw markdown document (including tables!) should be good 1. Firstly for readers, 2. Secondly for authors, 3. Lastly for parsers which don't even rate a mention because markdown is for Humans. You have probably noticed already that HTML tables are *appalling* for readers and a nightmare for authors. They are hardly "good" for markdown parsers either, which (not being HTML parsers) treat HTML tables as impenetrable blobs to be output "as is". Where does that leave us when we want to go from markdown to PDF? ## I Do Like Monospaced Tables It is the _visual alignment_ of terms into rows and columns that enables a reader to recognise a table. Without any recognisable alignment, a reader sees a jumbled "cloud" of terms -- which is exactly how we see tables with a variable width font. Additionally, a raw markdown document should 1. Be sharable, and, 2. Convey the same information to every reader. A raw markdown document must therefore be rendered *equivalently* for every reader. This can only be assumed if every reader has the same text spacing, and a mono spaced is _a_ reasonable way of achieving this. With all that in mind, I offer up my "Teardown" table specification for your consideration (I realise it will be "torn down", but nothing ventured nothing gained). Teardown offers the following over and above MultiMarkDown's table support: * Multi-line cell content, * Additional "Arty" syntax for titles and footers (much nicer for authors and readers), * Colspan (without meta-chars in cell content), * Rowspan, * Cell alignment (without meta-characters in content) *Please note* that I have _not_ implemented this specification. This is all just hot air produced by an author trying contribute something toward better table support for markdown. (specification to follow...) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110510/54358cc6/attachment.htm>
## Teardown Table Specification
1. Teardown Tables
1. The Simplest Table
2. Basic Table Features
1. The Header
a. Basic Header
b. Multi-Line Header
2. The Title
3. Rows
a. Clean Rows
b. Multi-Line Rows
c. Ruled Rows
4. Columns
a. Clean Cols
b. Ruled Columns
5. Ruled Rows and Ruled Columns
6. The Footer
3. Advanced Table Features
1. Cell Spans
a. Rowspan
b. Colspan
2. Cell Alignment
a. Vertical Alignment
b. Horizontal Alignment
3. Advanced Headers
4. Empty Cells
5. Nested Tables
6. Multiple Bodies
7. Vertical Table Header
4. Putting it all Together
1. A Complex Markeddown Table
## 1. Teardown Tables
A table is an arrangement of terms into rows and columns.
### 1.1. The Simplest Table
Here is a very simple Teardown table with three rows and three columns
(examples are delimited by PHP Markdown Extra fence blocks throughout):
~~~~~
Elves Rivendell Sindarin
Dwarves Erebor Khuzdul
Hobbits The Shire Westron
~~~~~
It is the *visual alignment* of terms into rows and columns which makes the
whole recognisable as a table to the reader.
It is the two leading (and trailing) line breaks which signal the beginning
(and end) of a table to the parser, however.
Additionally, we can see that:
* A line-break indicates a row-break,
* Any 3 or more space symbols indicates a column-break.
That is the _very least_ you need to know in order to write Teardown tables.
## 2. Basic Table Features
The "very least" is not enough to satisfy all authoring needs. For
example,
empty table cells are not supported by Simplest Table (above).
Teardown specifies a number of additional features which, combined, aim to
address all but the most tricky cases.
### 2.1. The Header
It is very often desirable to label columns of terms with a row of headings.
If included, this row of column headings is called the "Header".
The Header is separated from the table Body by a line of equals symbols
called the "Line".
The table Header is always above the Line, and the table Body is always
below the Line.
#### 2.1.a. Basic Header
The Header is authored as per any other row in the table Body. It is a
series of terms at the top of a like series of aligned columns. 3 or more
space symbols denote a column-break, just as they do in the Body of the
table.
E.g.,
~~~~~
People Homeland Tongue
=================================== Elves Rivendell Sindarin
Dwarves Erebor Khuzdul
Hobbits The Shire Westron
~~~~~
#### 2.1.b. Multi-Line Header
Header text can occupy more than line in the Header. E.g.,
~~~~~
Name of Spoken
People Homeland Tongue
=================================== Elves Rivendell Sindarin
Dwarves Erebor Khuzdul
Hobbits The Shire Westron
~~~~~
Note the single line "Homeland" column header. Empty cells and cell
spans
are discussed in section 3 (Advanced Table Features, below). But even
disregarding section 3, a parser can count the number of characters to
determine which column the text "Spoken" belongs to.
### 2.2. The Title
It is often desirable to label a table with a title.
If included, a Title is any text between two unbroken lines of minus symbols
which precede the table itself. E.g.,
~~~~~
------------------------------------
THE PEOPLE OF MIDDLE-EARTH
------------------------------------
People Homeland Tongue
=================================== Elves Rivendell Sindarin
Dwarves Erebor Khuzdul
Hobbits The Shire Westron
~~~~~
### 2.3. Rows
Rows of columns make up the Body of a table.
#### 2.3.a. Clean Rows
Clean rows (so called because the markdown is uncluttered) are separated by
a line-break. E.g.,
~~~~~
People Homeland Tongue
=================================== Elves Rivendell Sindarin
Dwarves Erebor Khuzdul
Hobbits The Shire Westron
~~~~~
Note that the more compact form used in example 1.1 (above) is ambiguous as
to whether there are three lines of text in a single row, or a single line
of text in each of three rows. In this example, there is no such ambiguity.
#### 2.3.b. Multi-Line Rows
Multi-lined rows are also allowed;
~~~~~
People Homeland Tongue
=================================== Elves Rivendell, Quenya,
Mirkwood, Sindarin,
Lorien Nandorin
Dwarves Erebor Khuzdul
Hobbits The Shire, Westron
Breeland
~~~~~
It is clear now that the compact form used in example 1.1 (above) would
unambiguously be interpreted as three lines of text in a single row.
#### 2.3.c. Ruled Rows
Ruled rows are optional, unless colspans are needed (see below).
A Ruled-Row is *followed* by a line of minus symbols in which column-breaks
are explicitly demarked by single space symbols. E.g.,
~~~~~
People Homeland Tongue
=================================== Elves Rivendell, Quenya,
Mirkwood, Sindarin,
Lorien Nandorin
----------- ------------ -----------
Dwarves Erebor Khuzdul
----------- ------------ -----------
Hobbits The Shire, Westron
Breeland
----------- ------------ -----------
~~~~~
The first row-rule must appear *after* the first genuine row of table Body
data.
The last row-rule is optional (unless you want a footer, see below). If it
does appear it does so *after* the last genuine row of table Body data. It
describes the last row _and_ makes up the bottom table edge.
### 2.4. Columns
Table data is arranged in Columns.
#### 2.4.a. Clean Cols
Clean columns (so called because the markdown is uncluttered) are implicitly
delimited by 3+ space symbols between table content text.
This is demonstrated in most of the examples above.
#### 2.4.b. Ruled Columns
Ruled columns are optional, unless rowspans are needed (see below).
A Ruled-Column is *followed* by a column of consecutive pipe symbols, in
which row breaks are explicitly demarked by an empty line. E.g.,
~~~~~
People | Homeland | Tongue
=================================== Elves | Rivendell, | Quenya,
| Mirkwood, | Sindarin,
| Lorien | Nandorin
Dwarves | Erebor | Khuzdul
Hobbits | The Shire, | Westron
| Breeland |
~~~~~
Note that the column-rule extended into the table Header.
The leading (left-hand) and trailing (right-hand) column-rules are omitted
above. However:
A leading column-rule can optionally appear *before* the first genuine
column of table Body data. This rule, if it appears, is merely a decorative
left-hand table edge.
The last column-rule is also optional. If it appears it does so *after* the
last genuine column of table Body data. It describes the last column _and_
makes up the right-hand table edge.
### 2.5. Ruled Rows and Ruled Columns
Ruled Columns can be combined with Ruled Rows like this:
~~~~~
People | Homeland | Tongue
=================================== Elves | Rivendell, | Quenya,
| Mirkwood, | Sindarin,
| Lorien | Nandorin
----------- ------------ -----------
Dwarves | Erebor | Khuzdul
----------- ------------ -----------
Hobbits | The Shire, | Westron
| Breeland |
~~~~~
Or, if you prefer to include the leading and trailing rules:
~~~~~
--------------------------------------
THE PEOPLE OF MIDDLE-EARTH
--------------------------------------
| People | Homeland | Tongue |
=================================== | Elves | Rivendell, | Quenya,
|
| | Mirkwood, | Sindarin, |
| | Lorien | Nandorin |
----------- ------------ -----------
| Dwarves | Erebor | Khuzdul |
----------- ------------ -----------
| Hobbits | The Shire, | Westron |
| | Breeland | |
----------- ------------ -----------
~~~~~
### 2.6. The Footer
A table can optionally include a footer.
If a footer appears, it begins exactly one blank line after the trailing
row-rule (which is also the bottom edge of the table).
The footer itself can contain any markdown (other than a nested table).
The footer is ended as soon as two empty lines (the end of table marker) are
encountered. E.g.,
~~~~~
--------------------------------------
THE PEOPLE OF MIDDLE-EARTH
--------------------------------------
| People | Homeland | Tongue |
=================================== | Elves | Rivendell, | Quenya,
|
| | Mirkwood, | Sindarin, |
| | Lorien | Nandorin |
----------- ------------ -----------
| Dwarves | Erebor | Khuzdul |
----------- ------------ -----------
| Hobbits | The Shire, | Westron |
| | Breeland | |
----------- ------------ -----------
1. Elves have pointy ears.
2. Dwarves wear thick beards.
3. Hobbits have hairy feet.
~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110510/d8703fa7/attachment.html>
On Tue, May 10, 2011 at 8:31 AM, Simon Bull <waysoftheearth at yahoo.com.au> wrote:> Gentlefolk, > > I have been thinking on Markdown's lack of "proper" table support for a long > while now.? Here's where I have arrived... > > > ## I Don't Like HTML Tables > > It is often argued that embedded HTML is the way to markdown rich tables. > > Unfortunately, this contradicts the higher markdown ideal that a raw > markdown document (including tables!) should be good > > 1. Firstly for readers, > 2. Secondly for authors, > 3. Lastly for parsers which don't even rate a mention because markdown is > for Humans. >In response to this I will quote the paragraph from the syntax rules [1] which likely gave you this impression:> 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. HTML is a publishing format; Markdown is a writing format. > Thus, Markdown?s formatting syntax only addresses issues that can be conveyed > in plain text.Note that is says "easy to read, write, and edit prose" -- "prose" not tabular data. Taking this (along with the rest of that section of the document, it is clear (to me at least) that there is no place for a table syntax in markdown. Now, if you want to implement a third party add-on, fine. And if that third party add-on becomes popular, then maybe others will add it to there implementations as well. Maybe, eventually, if a single format becomes popular enough, the community at large will accept it. Until then, I'm not interested. If you want it, go build it! [1]: http://daringfireball.net/projects/markdown/syntax#html -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg
On May 10, 2011, at 5:31 AM, Simon Bull wrote:> Gentlefolk, > > I have been thinking on Markdown's lack of "proper" table support > for a long while now. Here's where I have arrived.... . .> *Please note* that I have _not_ implemented this specification. > This is all just hot air produced by an author trying contribute > something toward better table support for markdown.I think this is a case where you'd do better writing a table preprocessor that implements your table extension. Yours is a fairly complex implementation, and there's not a painless way for people to try it out. The existing table implementation (the php markdown extra one) is kind of klunky and horrible, but the code is there and authors can actually see a working implementation before going and implementing it themselves. Yours, at least as of right now, is just documentation and not very useful for getting ones fingers into the pie. -david parsons
simon- i'm not sure persistence will do you much good. nobody seems to have a desire to work together. which is likely why there are 39 implementations. an appeal on behalf of readers seems misguided, since very few people are reading markdown text. but a more potent case can be made for _re-use_. the more easily content can be remixed, the better. for my contender in the light-markup derby -- zen markup language (zml) -- to facilitate re-use, my goal is that users can "round-trip" the text... so if they copy the text out of the .pdf and use it to create _another_ .pdf, the two will be identical. likewise, if they copy the text from a web-browser, it will match the .zml file which created that .html. or copy the text out of one version (.html or .pdf) and use it to create the other version, just like that. i am coming very close in both cases. it'll certainly be the case that some global changes will always be required to restore the original .zml, but if i get it down to just a few, that will be an accomplishment. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110515/06d2d332/attachment.html>
i sent this a week ago. (exactly 168 hours ago.) but it never posted... let's see if it posts now... i was just gonna let it go, but i liked the phrase "gruber is godot", so i decided to send it again... gruber isn't going to take charge, folks. really. so if you want to move markdown forward, _you_ will have to act, collaboratively, which means you must come together and become a collaborative... but i sense you would all rather be the big fish in your own small bowl. which is fine with me... -bowerbird ====================================================================================================== waylan said:> there is no place for a table syntax in markdown.well, gee, i guess that settles it... :+)> I'm not interested. If you want it, go build it!i wasn't under the impression that simon bull was asking you to do the work. but maybe i'm wrong... *** david said:> I think this is a case where you'd do > better writing a table preprocessor > that implements your table extension. > Yours is a fairly complex implementationi don't see anything "complex" in simon's formulation... i'd guess i could probably program it in a couple hours. and most of that would be fighting obtuse .html specs... at the same time, however, i don't see anything in his formulation that hasn't already been suggested before. so i'm not sure why it hasn't been done. by everyone. why the foot-dragging? are you all still waiting for gruber? i've got news for you: gruber is godot. he ain't coming. you might as well move on. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110517/23b8f5b1/attachment.htm>
here's another one i thought twice about posting, but what the heck... *** ok, first of all, when i referred to 39 implementations, i wasn't being critical. how could i criticize any of you for being off writing your own version of markdown when i'm off writing my own version of light-markup? my work _does_ predate that of gruber and swartz, but i've still continued to do it, because i think my method is _superior_ for the task at which my method is aimed; thus i am not willing to concede the race to markdown. so far be it from me to stab any of you for continuing to pursue your own entry because you believe it to be superior to the other contenders. believe in yourself! at the same time, though, it's a bit disingenuous to say that the only differences are your choice of languages. very few of you agree on edge-cases, and none of you have explored the entire arena. that's the reality here. and that is not a dig, either. the edge-cases are hard, and if you try to chart the whole arena, you will likely lose the simplicity that is one of markdown's big assets. anyone tempted to move in that direction should look at asciidoc. it's very admirable in a way, but it's not simple. who needs to reinvent .html markup without the brackets? so, believe me, i understand the conundrum very well... but still remaining at the same time, let us ask simon if he thinks there is any desire to find a compromise here. when it comes to tables, you put people in a catch-22... it has to be something that can work with existing tools, and it has to be something that can work with fonts that are proportional and nonproportional. surely you are all smart enough to know that the clauses are contradictory. the only reason to put people in a double-bind is if you actively want to stall 'em out, in a passive way. that's it. edge-cases are not as clear of a catch-22, but even there, you all have historic content you prefer not to "break" by changing your implementation, so you are at an impasse. but hey, if it makes you feel better, i would be happy to add that all of this is "only in my own humble opinion", and that "maybe i'm just not smart enough to see your solution", and whatever other evasive language i would need to say so as to protect you from feeling challenged or threatened, because that's really _not_ my intention. i have my own fish to fry... -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110517/bd0c429f/attachment.html>
slept on this, but decided to send anyway, make it a trilogy... *** david said:> Well, then why don't you do it?i've got some other fish to fry right now, in my own project, but i will get around to tables soon enough with that myself, and i'll be very happy to show people the results when i do... and here are some of the "challenges" i'll want to try to handle:> http://www.pgdp.net/phpBB2/viewtopic.php?t=4311&start=0 > http://www.pgdp.net/wiki/Formatting_Examples/Gallery_of_Table_Layouts*** rob said:> with all due respect, it's more than a little arrogant for > anyone to insist that they got it perfect the first time (1.0.1).well, gruber is well-known for being arrogant, but i do believe that he has never insisted, or even claimed, he got it all "perfect". and besides, the current charge is _neglect_, and not _arrogance_. but all of that is a dodge as well. gruber isn't really the factor here. the _real_ problem is that there's several different implementations, and they differ between each other, and none of 'em is significantly better than the others, so none of them can overcome the stalemate. i repeat: it has nothing to do with gruber. nothing at all. really. the only thing gruber could do is bless a successor. and he won't.> The idea of Markdown, not the implementation, is what's special.nope. lots of other people had "the idea" long before gruber. indeed, "structured text" -- from which "restructured text" was derived -- dates back to the 1990s, and was a contender against the likes of .sgml. if tim berners-lee would have been smarter, he woulda chosen light-markup instead of going the other way. but he had the notion that he wanted to follow ted nelson, so he went for the "hypertext" model instead, and botched everything, including all of the brilliant things that nelson _actually_ meant... gruber gets the markdown attention because gruber gets attention. but if all of you implementers got yourselves _around_ a table and decided to develop "markaround" to go _around_ gruber, you could. if you all agreed, amongst yourselves, gruber doesn't have enough power -- or programming chops, or fame -- to thwart all of you... the question is whether you'd rather be big fish in your own ponds, in the backchannels of the lake of gruber, or go swim in the ocean. of course, pandoc might just sweep you all into the ocean anyway... and once again, none of this is a dig. i haven't shared my own z.m.l. with the world because i want to retain control over it, so that _my_ implementation is the _only_ one, so it is canonical, and therefore there is absolutely no confusion about what the whole thing means. with markdown, though, you do not have the luxury of such clarity... *** michel said:> What we really need is an effort in the style of HTML5's HTML > parsing algorithm which provides an unambiguous definition > of how things should be parsed.that's right.> Heck, I started one a while ago for Markdown Extra > ... > Then I stopped because I realized it'd be too long and that I had > many more interesting projects I could do in that free time.the other thing is that you were doing the task as the lead actor... this effort will only work if it's a collaboration amongst all of you. and each of you is probably going to have to give something up... (unless you can find a sharp way to tease out all the ambiguities. which, if you _can_ do that, will be the best solution for everyone.)> Still, thanks for your analysis. It's refreshing to have > an outsider's opinion one time in a while.hey, who you calling "an outsider"? i was researching light-markup years before gruber and swartz came along. this is my house, and you kids better stop playing on my lawn... outsider my ass! ;+) seriously, though, markdown has been great for light-markup, and i sincerely hope that you guys move markaround to the next level... *** drang said:> Fish, eh? I thought I smelled something?you funny! :+) but if you sincerely want to "call" it, you can. i have promised to release my app when i get 100 people signed-up on this web-page here:> http://jaguarps.blogspot.com/2011/04/blog-post_14.htmlonce i put it out in the world, you can criticize it to the depths and heights of your heart's desire. yes, i'm sittin' here, right on the edge of the dunk-tank, daring you to step up and fire a hardball at the target... *** albert said:> Extensions address the question of limited scope, and > if they are to grow useful, it seems reasonable to inform them > with a more abstract purpose; e.g., enriching plain text with > logical structure, rather than making macros for html.that's quite astute. *** thomas said:> You may also look at the syntax specification for kramdownyou've done a very good job, thomas, really a smashup job... my reservation is based on my reaction that "this isn't simple". that might be the way you've explained it. (like michel's work, your documentation seems to be aimed at the _format_wonks,_ who care about "block level versus span level" and such things.) or it might be that the underlying framework is just too difficult. (specifically, i wonder if all the hassles of "lazy syntax linewrap" outweigh the convenience... in my own work, i had to offer that -- as project gutenberg files have mid-paragraph linebreaks -- but i worked out a way that it doesn't have to be quite so hard.) so i just can't tell if it's the documentation or the framework, but either way, if you can't find a more simple way to explain all of it to ordinary people, i'm afraid you ain't gonna get a lot of uptake. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110518/d9ae5a96/attachment.html>
david said:> "The idea" is not ascii formatting, > it's the particular type of ascii formatting.there's nothing special about "the particular type" of ascii formatting represented by markdown, as it simply leveraged existing methods of ascii formatting found in e-mail and on usenet. nothing unique there. indeed, the important point was that it was pre-existing.> Markdown tries to take advantage of existing methods > of ascii formatting found in mail and usenet newsright. i'm glad we agree. i used them too, and threw in huge dollop of the practices already in use by project gutenberg for their e-texts, since my specific aim was the p.g. library, as an existing corpus of digitized books that would serve as content for my general target, which was electronic-books across the full spectrum. (that's still the focus of z.m.l. -- e-books, not web-pages.) of course, project gutenberg also derived their conventions from those used in e-mail, and usenet, and bulletin-boards. so everyone, including markdown, gets these conventions from the same place -- the humans who "invented" them using the keyboards under their hands. (and typewriters, let us not forget; underscores, representing _italics_, came from typewriters; so some of this stuff is really old-school.) and it's probably good to remember that project gutenberg was using this "intuitive" formatting way back in the 1990s. when aaron swartz was really young, aged in single digits... if markdown was the inspiration for you personally, i'm glad. but markdown is assuredly _not_ where "the idea" came from. it was already an old idea by the time markdown came about.> I had a vanity markup language once, too.i'll see if my users end up having a response to that charge... :+) *** ishe said:> I don't know how on earth I can > add my signature to be the 90th.don't worry, ishe. i will consider you signed up. it is informal.> But I find that promisingthanks. i hope you find that i deliver on the promises as well.> and just wonder whether it would work on Mac as well.mac first. p.c. two seconds later. linux if there's any demand. (but since cory doctorow signed up, and sent a flock of people to sign up as well, i guess i will have to resolve myself to that.)> I am also wondering whether there would be a way > to split a document into many pages.that will be a feature that i will provide sooner rather than later. (the .epub format essentially demands that chapters be treated as separate files, so a chapter-based split will be offered first.) -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110519/348e54c2/attachment.html>
david said:> If you're defining how a language works, > you need to aim it at the technically competent.if you want the masses to use it, you must aim there.> Different audiences want different information.true. but trite. to the point it might as well be wrong. there are infinite audiences "possible", but there are only 3 worth considering, and only 2 of those 3 matter. and thomas and michel were aiming at "the format wonks", who are the third group, the one that doesn't even matter. they don't matter because they fail to add any real value. that's why thomas and michel were just wasting their time, in my humble opinion. who cares what format wonks think? so let's concentrate on the other two groups instead, ok? users are crucial, because without them you are nothing. and programmers matter, since you need implementers. users need something simple, and hopefully unambiguous. programmers need unambiguity, and it's best if it's simple. if you make your thing simple _and_ unambiguous, bingo! *** albert said:> I imagine the emergence and vitality > of a standard syntax (among other things) would > benefit if everyone were familiar with this book:also astute. but unduly circuitous. usually i hate to give up my hard-fought trade secrets. and the more big, and obvious, and brilliant, they are, the more that i hate to give 'em up, precisely because it is exactly that first step where most people go bad, as evidenced right here by what albert said. but still, markdown and its implementers have suffered enough, so please consider this to be my open-source gift to you: the big secret is that all you must do is split the text on blank lines, and then just decide what each segment is, which will tell you how it needs to be tagged/formatted. that's it, folks. it ain't rocket science. it's simple as pie. reverse-engineer your syntax from that for unambiguity. simple, and unambiguous. that's all you need for bingo! but bravo for bringing up bringhurst, mr. skye. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110519/19dd3a3d/attachment.html>
david said:> Okay, so you're trolling.whoa. now _that's_ certainly an ironic twist. you demean me, repeatedly, and then have the audacity to go accuse _me_ of "trolling", all while you spin the conversation in circles... that definitely takes some chutzpah, yes it do. at any rate, david, if you think format wonks add value to the equation, you can tell us how. in the meantime, i'll stand by my assessment. if anyone wants to get back on-topic, i'm game. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110520/44aff6c9/attachment.htm>
i said:> if anyone wants to get back on-topic, i'm game.and now i add that if your posts are not on-topic (i'm looking at you, christian), i am _not_ game... so don't bother trying to play me. -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110520/977e8b40/attachment-0001.htm>
yuri said:> Wow. I wish I had realized this back in 2005 when > I started working on my Python implementation. > All of those hours wasted, while all I had to do was > split the text on blank lines.well, yes, it woulda saved you a few years of time, eh? luckily, by 2008, you'd sensed that this was the solution, judging by this passage you left on this listserve in march:> Let's first unambiguously specify how markdown text > ought to be parsed into paragraphs, quotes, lists, etc. > Michel, do you want to do a first draft and circulate it?michel did the first pass, on a draft which then... fell flat. and now, 3 years after _that_, michel is currently saying:> What we really need is an effort in the style of > HTML5's HTML parsing algorithm which provides an > unambiguous definition of how things should be parsedyou guys can run around in circles all you like, until you finally decide you're gonna work together to accomplish this objective, and then, when you do, you can revisit my advice, whereupon you'll find it is exactly what you need. i'm _not_ telling y'all that you have a problem. i have _no_ desire to do an intervention on you. do what you like, guys. it's jeff atwood who was telling you that you have a problem. i say if you want to remain islands, i'm perfectly fine with it. but if/when _you_ decide that you have a problem, well then you will probably also realize that i've given you the solution. because, after all, you'd seized upon the solution yourselves, years ago; you just didn't realize that you had found the key. (or, if you did realize it, you didn't use it to unlock the door.) *** and i _invite_ you to add all of this to "the collected sayings". except it hasn't been updated in a long time. you know why? because the guy who created it was in a long-running dispute with me about how p.g. should proceed. i said "light-markup" and he said "t.e.i." (as if volunteers at p.g. could handle t.e.i.) finally, about a year back, he realized he was wrong all along. he still won't _admit_ that, but he quietly shifted his efforts to -- guess what -- light-markup, in the form of restructured text. how does that saying go?> "first they laugh at you, > then they ignore you, > then they fight you, > then you win."and how does that other saying go?> he who laughs last > laughs best.-bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110520/d1e86f06/attachment.html>
thomas said:> yes, the syntax spec is not aimed at the plain user, > but the quick reference is. It's vastly simplifiedyes, the quick reference is much simpler, and thus better... and we could discuss why, but my sense is that nobody here really wants to talk about it any more, at least right now, so i'm happy to wait until next year, when it comes up again... -bowerbird -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://six.pairlist.net/pipermail/markdown-discuss/attachments/20110526/2a1b294f/attachment.html>