Re: More continuing text for tables
Personally, I would prefer to use exactly one table syntax, so long as it _works_. Using one pipe per col to span is okay for small number of columns to span, though it doesn't scale elegantly, as in the following example; | This cell spans 9 cols, and therefore has 9 pipes | | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI | ---+--+--+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 | An alternative (or additional) syntax option might be to use an alternative cell separator when colspan is required. '!' comes to mind, since it looks almost exactly like a '|' in most fonts. '[' or ']' are other possibilities. I don't mind whether we use the leading or trailing cell-delimiter for this, but in my examples below, I mostly use a leading cell delimiter. The disadvantage of using another type of cell delimiter is that it introduces additional table framework into our text. However, the advantage is that by default a '!' cell separator could indicate colspan=2, which would likely be the most common case. So, for colspan=2, no additional pollution of the text would be required. E.g., | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ColH | ColI | ---+--+--+--+--+--+--+--+--+--+ 1 | A1 | B1 ! C1 and D1 | E1 ! F1 and G1 | H1 | I1 | 2 | A2 | B2 | C1 ! D2 and E2 | F2 ! G2 and H2 | I1 | Where a colspan greater than 2 is required, metadata must unfortunately be introduced. For this I would like to suggest two alternatives; The first suggestion is similar to David's proposal except that it uses a number of underscores to indicate of the number of columns a cell should span, such that colspan = number of underscores +2. In the most common case, colspan=2, no underscores are required. Colspan=3 requires one underscore, colspan=4 requires two underscores, and so on. If I *must* use metadata characters, then I prefer underscores because they at least "look like" part of the table frame (imagine it as part of a line between two rows). For example; | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I ---+---+---+---+---+---+---+---+---+--- 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 2 !_colspan three ! colspan two !__colspan four 3 | A3 | B3 | C3 | D3 | E3 | F3 | G3 | H3 | I3 Overall, this approach requires one fewer metadata character in every colspanned cell. The second suggestion is to use '[' as a leading cell separator, or ']' as a trailing cell-separator, where colspan is required. This could be followed, or led, by a number x such that colspan = x. A number need not be supplied where x == 2. For example; | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I ---+---+---+---+---+---+---+---+---+--- 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 2 [3colspan three [ colspan two [4colspan four 3 | A3 | B3 | C3 | D3 | E3 | F3 | G3 | H3 | I3 would be exactly equivalent to | Col A | Col B | Col C | Col D | Col E | Col F | Col G | Col H | Col I | ---+---+---+---+---+---+---+---+---+---+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | H1 | I1 | 2 | colspan three3] colspan two ] colspan four 4] 3 | A3 | B3 | C3 | D3 | E3 | F3 | G3 | H3 | I3 | This approach requires fewer metadata characters overall, but I prefer the first suggestion (underscores) because it looks nicer, and reads more easily. Simon On Wed, Jun 24, 2009 at 12:23 PM, David E. Wheeler wrote: > On Jun 23, 2009, at 6:43 PM, Simon Bull wrote: > > Explicit row markers do _work_, but they are too verbose for my liking. >> They are more work to write, and don't read as cleanly. The colon syntax >> _works_ too, and it is cleaner, and I think having a source document which >> is natural to write, and easy to read is important. >> > > +1, although sometimes, with really busy tables, they make things clearer. > > All that aside, it is support for the continued text *feature* that I am >> most interested in. If I have to live with explicit line breaks, I guess >> I >> will. But it would seem a shame, given the alternative. >> > > I agree, but what I mean by "busy tables" is when you have a table with > multicolumn cells *and* multirow rows. My blog entry has a decent example of > this: > > | |Grouping|| > +---+-+ > | First Header | Second Header | Third Header | > +---+-+---+ > | Content | *Long Cell* || > : continued :
Re: More continuing text for tables
On Jun 23, 2009, at 6:45 PM, Waylan Limberg wrote: Actually, PHP Markdown Extra [1], Python-Markdown [2], and Pandoc [3] all support definition lists using the colon as well. And that's only the ones I'm familiar with. There may be others. The point is, I think this is an established enough syntax used by enough people who have written enough documents, that it would be a little to painful to change now. I actually submitted a patch to MultiMarkdown to allow ~ as an alternative, for backwards compatibility. However, I don't believe your proposal mitigates Simon's concern regarding overuse of the colon. In fact, it would seem reasonable to expect that the very implementations which correctly support definition lists (using colons) would be the first to implement any new alternate table syntax, whether it uses colons or not. If the tilde were to be formally adopted by core markdown, the colon would not be overused for this purpose. And I'm going on psql as prior art in suggesting the colon for continued lines. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Jun 23, 2009, at 6:43 PM, Simon Bull wrote: Explicit row markers do _work_, but they are too verbose for my liking. They are more work to write, and don't read as cleanly. The colon syntax _works_ too, and it is cleaner, and I think having a source document which is natural to write, and easy to read is important. +1, although sometimes, with really busy tables, they make things clearer. All that aside, it is support for the continued text *feature* that I am most interested in. If I have to live with explicit line breaks, I guess I will. But it would seem a shame, given the alternative. I agree, but what I mean by "busy tables" is when you have a table with multicolumn cells *and* multirow rows. My blog entry has a decent example of this: | |Grouping|| +---+-+ | First Header | Second Header | Third Header | +---+-+---+ | Content | *Long Cell* || : continued ::: : content ::: | Content |**Cell** | Cell | : continued : : : : content : : : | New section | More | Data | | And more | And more || [Prototype table] It starts to get a little confusing in this case, so I'd like, for more complicated tables, to alternatively be able to designate rows like so: | |Grouping|| +===+=+ | First Header | Second Header | Third Header | +===+=+ | Content | *Long Cell* || : continued ::: : content ::: +---+-+ | Content |**Cell** | Cell | : continued : : : : content : : : +---+-+ +---+-+ | New section | More | Data | +---+-+ | And more | And more || +---+-+ [Prototype table] You can distinguish the one style from the other by the use of =s in the header instead of -s. However, I strongly agree that the tilde could be used in for definition lists, thereby removing the ambiguity between colons used as cell delimiters and those used in definition lists. Thanks! They stand out better, too, in most fonts. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 9:45 PM, Waylan Limberg wrote: [snip] > colon. In fact, it would seem reasonable to expect that the very > implementations which correctly support definition lists (using > colons) would be the first to implement any new alternate table > syntax, whether it uses colons or not. > Sorry, that was supposed to say "...which *currently* support definition lists..." Apologies for any confusion my fat fingers may have caused. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 5:01 PM, David E. Wheeler wrote: > On Jun 22, 2009, at 9:01 PM, Simon Bull wrote: > >> * The colon is used more commonly in content than the pipe, and, >> * ':' is markdown syntax denoting a definition list. > > Actually, it's in used for a definition list in MultiMarkdown. Markdown does > not support definition lists. I have a [related proposal][] for definition > lists that's identical to what MM does, except that it uses ~ instead of :, > both because it's easier to see as a bullet in many fonts, and because it's > not all that common. Actually, PHP Markdown Extra [1], Python-Markdown [2], and Pandoc [3] all support definition lists using the colon as well. And that's only the ones I'm familiar with. There may be others. The point is, I think this is an established enough syntax used by enough people who have written enough documents, that it would be a little to painful to change now. Of course, if anyone wanted to introduce an alternate syntax using the tilde, they certainly can. However, I don't believe your proposal mitigates Simon's concern regarding overuse of the colon. In fact, it would seem reasonable to expect that the very implementations which correctly support definition lists (using colons) would be the first to implement any new alternate table syntax, whether it uses colons or not. [1]: http://www.michelf.com/projects/php-markdown/extra/#def-list [2]: http://www.freewisdom.org/projects/python-markdown/Definition_Lists [3]: http://johnmacfarlane.net/pandoc/README.html#definition-lists -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
My apologies, I didn't read David's post correctly. After looking at it more closely, I agree with the previous posts; a leading pipe followed vertically by trailing colons is much better than the other way around, so it should have looked like this: Col A| Col B | Col C -+--+- A1 |B1|C1 a2 contains | b2 | c2 some long & : b2 : c2 interesting :b2:c2 commentary : B2 : C2 A3 |B3|C3 Explicit row markers do _work_, but they are too verbose for my liking. They are more work to write, and don't read as cleanly. The colon syntax _works_ too, and it is cleaner, and I think having a source document which is natural to write, and easy to read is important. All that aside, it is support for the continued text *feature* that I am most interested in. If I have to live with explicit line breaks, I guess I will. But it would seem a shame, given the alternative. Regarding David's [related proposal][] for the use of tildes '~' for definition lists, I was also going to suggest adding tildes to support definition lists within tables, but I backed off from that in my original post so as not to cloud the central issue; continued text in tables. However, I strongly agree that the tilde could be used in for definition lists, thereby removing the ambiguity between colons used as cell delimiters and those used in definition lists. I will have to have a look at multimarkdown too :) Thanks to all who replied, Simon [related proposal]: http://justatheory.com/computers/markup/modest-markdown-proposal.html On Wed, Jun 24, 2009 at 7:04 AM, David E. Wheeler wrote: > On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote: > > And here's what I believe you meant: >> >> |Col A| Col B | Col C >> ==+=+==+= >> 1 | A1 |B1|C1 >> --+-+--+- >> | a2 contains | b2 | c2 >> | some long & | b2 | c2 >> | interesting |b2|c2 >> 2 | commentary | B2 | C2 >> --+-+--+- >> 3 | A3 |B3|C3 >> >> Which makes me believe my syntax above using explicit line separators may >> be better, even though it's much more verbose. >> > > Yes, Simon's was not quite right. It should be: > > |Col A| Col B | Col C > +-+--+- > | A1 |B1|C1 > | a2 contains | b2 | c2 > : some long & : b2 : c2 > : interesting :b2:c2 > : commentary : B2 : C2 > | A3 |B3|C3 > > See also pgsql. > > Best, > > David > > ___ > Markdown-Discuss mailing list > Markdown-Discuss@six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Jun 23, 2009, at 11:38 AM, Michel Fortin wrote: And here's what I believe you meant: |Col A| Col B | Col C ==+=+==+= 1 | A1 |B1|C1 --+-+--+- | a2 contains | b2 | c2 | some long & | b2 | c2 | interesting |b2|c2 2 | commentary | B2 | C2 --+-+--+- 3 | A3 |B3|C3 Which makes me believe my syntax above using explicit line separators may be better, even though it's much more verbose. Yes, Simon's was not quite right. It should be: |Col A| Col B | Col C +-+--+- | A1 |B1|C1 | a2 contains | b2 | c2 : some long & : b2 : c2 : interesting :b2:c2 : commentary : B2 : C2 | A3 |B3|C3 See also pgsql. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Jun 22, 2009, at 9:01 PM, Simon Bull wrote: * The colon is used more commonly in content than the pipe, and, * ':' is markdown syntax denoting a definition list. Actually, it's in used for a definition list in MultiMarkdown. Markdown does not support definition lists. I have a [related proposal] [] for definition lists that's identical to what MM does, except that it uses ~ instead of :, both because it's easier to see as a bullet in many fonts, and because it's not all that common. [related proposal]: http://justatheory.com/computers/markup/modest-markdown-proposal.html Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
On Tue, Jun 23, 2009 at 2:38 PM, Michel Fortin wrote: [snip] > Are you sure this syntax is so intuitive? I was certain (for about 5 > minutes) that you meant the colons to continue the cell from the previous > line, not start a new cell, despite the weird result. What David Wheeler > proposed seem to follow my interpretation. Basically, here's what I saw: > [snip] > > And here's what I believe you meant: > [snip] > > Which makes me believe my syntax above using explicit line separators may be > better, even though it's much more verbose. Wow, I made the exact same mistake, except that I never caught on to what was really indented. In any event, the more verbose syntax proposed by Michael seems like the only reasonable alternative to me as well. That said, I am leaning more toward the opinion that anything more complex that can already be done should be left to raw html. But I've already explained my position on that before. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: More continuing text for tables
Le 2009-06-23 à 0:01, Simon Bull a écrit : Thus, text may be continued over any number of lines in a table body, like this; |Col A| Col B | Col C ---+-+--+- 1 | A1 |B1|C1 : a2 contains : b2 : c2 : some long & : b2 : c2 : interesting :b2:c2 2 | commentary | B2 | C2 3 | A3 |B3|C3 Are you sure this syntax is so intuitive? I was certain (for about 5 minutes) that you meant the colons to continue the cell from the previous line, not start a new cell, despite the weird result. What David Wheeler proposed seem to follow my interpretation. Basically, here's what I saw: |Col A| Col B | Col C ==+=+==+= 1 | A1 |B1|C1 | a2 contains | b2 | c2 | some long & | b2 | c2 | interesting |b2|c2 --+-+--+- 2 | commentary | B2 | C2 --+-+--+- 3 | A3 |B3|C3 And here's what I believe you meant: |Col A| Col B | Col C ==+=+==+= 1 | A1 |B1|C1 --+-+--+- | a2 contains | b2 | c2 | some long & | b2 | c2 | interesting |b2|c2 2 | commentary | B2 | C2 --+-+--+- 3 | A3 |B3|C3 Which makes me believe my syntax above using explicit line separators may be better, even though it's much more verbose. -- Michel Fortin michel.for...@michelf.com http://michelf.com/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
