Markdown vs LaTeX / TeX Markup - Articles, Books, Text Formatting, Lists, Tables, etc.
Hello, I've started yet another Markdown project, that is, Markdown vs LaTeX / TeX Markup [1] What's it about? The idea is to show the difference of text with markup and without (markdown). So far examples include: - Artcles - Books - Text Formatting (Bold, Italic, etc.) - Lists (Bullet, Numbered, etc.) - Tables It's on GitHub. Additions welcome. If you know similar projects let us know * Cheers. * Will try to start more versions e.g. for Microsoft Word and Wikipedia Wikitext. [1] https://github.com/writekit/markdown-vs-latex/blob/master/README.md ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net https://pairlist6.pair.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
I believe that Suraj is proposing that Markdown implement David Wheeler's proposed table formatting and provide the option to process them into tables made up of box characters. I agree, though, that this is best left for HTML — especially since character-based tables only render correctly with monospaced fonts. On Wed, Sep 9, 2009 at 11:39 AM, david parsons o...@pell.chi.il.us wrote: I'm sure that somebody has, but where are you going to find a keyboard that has all of those unicode glyphs on it ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
Thanks for considering my idea and replying accordingly, everyone. I agree that having Markdown users meticulously craft tables with Unicode box drawing characters[2] is impractical. However, I am still very fond of David Wheeler's proposal[1] for Markdown tables. Are there any existing implementations of [1] at present? If not, I will try to implement it as a preprocessor (as Waylan Limberg suggested) so that it can be used with any Markdown implementation: cat document.md | dw_md_tables | markdown document.html Thanks for your consideration. [1]: http://justatheory.com/computers/markup/markdown-table-rfc.html [2]: http://en.wikipedia.org/wiki/Box_drawing_characters ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
However, I am still very fond of David Wheeler's proposal[1] for Markdown tables. Are there any existing implementations of [1] at present? If not, I will try to implement it as a preprocessor (as Waylan Limberg suggested) so that it can be used with any Markdown implementation: If I understand the need, wouldn't an HTML-tables-box-drawing-characters transformer -- implemented as a post-processor in a Markdown stack -- be more straightforward, remove any Markdown dependency and address more use cases? I can imagine a wrapper element option, etc. (pre, for example). There may be abusable code in projects like ELinks. http://en.wikipedia.org/wiki/ELinks LQ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
* Suraj Kurapati sun...@gmail.com [2009-09-09 06:20]: What if Markdown used Unicode characters to express tables in this manner? Then I would still write my tables using HTML tags. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
In article cfbcd2f00909082118i558a6ef7qa968885d2460c...@mail.gmail.com, Suraj Kurapati markdown-discuss@six.pairlist.net wrote: However, I want to ask: has anyone considered taking these simple ASCII table drawings to the next level of realism with Unicode box drawing characters? I'm sure that somebody has, but where are you going to find a keyboard that has all of those unicode glyphs on it, or would you have to write a markdown preprocessor that takes a table made up of symbols found on a keyboard and convert it into the unicode characters? -david parsons ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: tables with Unicode box drawing characters?
On Wed, Sep 9, 2009 at 12:18 AM, Suraj Kurapatisun...@gmail.com wrote: Hello, I read David Wheeler's table proposal[1] for Markdown and very much agree with his conclusion and PostgreSQL-inspired proposed format. I also read the mailing list archives for 2009 but did not find any clear concesus on whether DW's format was officially accepted (I hope it is soon!). I didn't go back and check but I think there was in a previous discussion with a similar proposal. In other words, you need to go back further in the archive. Basically, these proposals for more complex tables are outside the scope of Markdown and should be left to raw html. At least I seem to recall actual implementers leaning that direction. Of course, if someone wanted to implement David's proposal (or some variant) and users flocked to it, then the rest of us may follow suite. Until then, I'm sticking to the simple solution we have now. Hint (and shameless plug): Python-Markdown makes adding on something of the sort easy with it's extension API. Check it out here: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions What if Markdown used Unicode characters to express tables in this manner? All we need are two essential subsets of the Unicode box drawing characters: * thin ones for normal cells: ┌ ┐ └ ┘ ─ │ * thick ones for heading cells: ╔ ╗ ╚ ╝ ═ ║ The last few times someone proposed a syntax that didn't use commonly found keys on the keyboard, the proposal met with a *lot* of resistance. I suspect most users wouldn't even know how to type these characters. Another barrier is that not all implementations support Unicode (I think - at least not fully). Therefore, some implementations may never adopt such a proposal. Third, it seems like it would be an awful lot of work to build such a table. A lot more than some of the existing proposals out there. -- \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 Jun 24, 2009, at 4:27 PM, Simon Bull wrote: Okay, thanks for your input, David. Tables with lots of narrow columns are not so rare they can be dismissed; they are useful for matrices of numbers, for example. Yeah, but merging a given row of them into one column is much less common. How about an (entirely optional) addition to the existing multimarkdown pipe syntax, specifically for cells which span many cols? A number followed immediately by a pipe would be taken as the colspan. Also not useful in the plain text. I'm all for affordances for the parser if their semantic value is apparent. Such is not the case here: the 7 is spurious and looks like a typo. It contains 1 ugly metadata character, true. It is a matter of personal taste as to whether you find 6 additional pipes or 1 digit more intrusive, so why not provide authors with the choice? The advantage of the digit meta-character, of course, is the additional space in the cell to write content. It's not about obtrusiveness as much as meaning. The real problem is that *neither* of these options is entirely natural to either the author or the reader. Right. Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell. The example above _could_ be rewritten like this; | This cell spans 7 cols, and looks much nicer ! | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | Yes, better, though I might make both the right and left columns different. Note the exclamation point as the last character on the first row. I acknowledge David's concern about the use of '!' for table structure, and use it here only as an example. Other punctuation marks could be substituted. Most, however, have the same issue -- that they are common in text content. This is not insurmountable. A cell-delimiter character could require a space either side, for example. That aside, the example above looks more like what authors would naturally write, and makes *much* cleaner reading than either meta-data option (to my eyes, at least). Agreed. But I'm not sure how many special cases we really want. They can be hard to remember when writing such a table. It seems to me that we should start with a design with *no* special cases and then see what cow paths develop. The introduction of a col-span indicating cell-delimiter means that *only* the second and subsequent colspanning cells of any row require any metadata to indicate span width. I think I'd rather write it in HTML. Two (or more) colspanning cells per row would, presumably, be reasonably rare. When necessary, the author could use the existing multimarkdown syntax for the narrower cells. If there is an existing syntax that works, why add the special case? 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 10:24 PM, Simon Bull wrote: Personally, I would prefer to use exactly one table syntax, so long as it _works_. Yeah, that would be my preference, as well, where _works_ eq is legible as plain text and parses properly. 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 | Yeah, point taken, although that'd be a pretty rare occurrence. 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. Well, ! is pretty common in text, and [ and ] are already used for links. 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 | That's not very intuitive to me. 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. 3 == 1, 4 == 2? Ick. 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. But it provides no meaning to the reader of the plain text. It just looks like a pasto or something. I'm opposed to adding characters with no semantic meaning. 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. Um, no. Same problem. This approach requires fewer metadata characters overall, but I prefer the first suggestion (underscores) because it looks nicer, and reads more easily. I don't like either one, because they're very poor communicators of semantic meaning to the reader of the plain text version. Your original example with nine merge columns is much nicer-looking to my eye. And it's what MultiMarkdown already does, IIRC. 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
Okay, thanks for your input, David. Tables with lots of narrow columns are not so rare they can be dismissed; they are useful for matrices of numbers, for example. How about an (entirely optional) addition to the existing multimarkdown pipe syntax, specifically for cells which span many cols? A number followed immediately by a pipe would be taken as the colspan. So this; | This cell spans 7 cols, and has less spa ||| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | would be exactly equivalent to this; | This cell spans 7 cols, and has more space 7| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | It contains 1 ugly metadata character, true. It is a matter of personal taste as to whether you find 6 additional pipes or 1 digit more intrusive, so why not provide authors with the choice? The advantage of the digit meta-character, of course, is the additional space in the cell to write content. The real problem is that *neither* of these options is entirely natural to either the author or the reader. Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell. The example above _could_ be rewritten like this; | This cell spans 7 cols, and looks much nicer ! | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | Note the exclamation point as the last character on the first row. I acknowledge David's concern about the use of '!' for table structure, and use it here only as an example. Other punctuation marks could be substituted. Most, however, have the same issue -- that they are common in text content. This is not insurmountable. A cell-delimiter character could require a space either side, for example. That aside, the example above looks more like what authors would naturally write, and makes *much* cleaner reading than either meta-data option (to my eyes, at least). The introduction of a col-span indicating cell-delimiter means that *only* the second and subsequent colspanning cells of any row require any metadata to indicate span width. Two (or more) colspanning cells per row would, presumably, be reasonably rare. When necessary, the author could use the existing multimarkdown syntax for the narrower cells. Simon On Thu, Jun 25, 2009 at 3:05 AM, David E. Wheeler da...@kineticode.comwrote: On Jun 23, 2009, at 10:24 PM, Simon Bull wrote: Personally, I would prefer to use exactly one table syntax, so long as it _works_. Yeah, that would be my preference, as well, where _works_ eq is legible as plain text and parses properly. 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 | Yeah, point taken, although that'd be a pretty rare occurrence. 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. Well, ! is pretty common in text, and [ and ] are already used for links. 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 | That's not very intuitive to me. 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. 3 == 1, 4 == 2? Ick. If I *must* use metadata characters, then I prefer underscores because they at least look like part of the table
Re: More continuing text for tables
I can't say that I find this proposal to be perfect, but to me this was one of the more compelling emails in this thread. I have been having my own internal conversation about how to rewrite the MMD table syntax. My personal goals were to find a way to minimize the markup, make it more readable/less distracting, and hopefully easier to generate. I started thinking seriously about how to rewrite the table syntax after reading about [elastic tabstops](http://nickgravgaard.com/elastictabstops/). To me, these seemed to be the best way to implement tabs within text documents. Then, it occurred to me that the only time I use tabs in MMD documents is at the beginning of a line, to indicate code blocks, or to indent lists. I never use tabs within a line. Yet tabs are inherently what I want to use to align columns of text in tables. So I started looking into using tabs to separate columns within a table (i.e. replacing the | in the current MMD syntax). If you used spaces before the tab, you could ensure that each row had the same column-widths (for sure with monospace font, and fairly tolerant for some variation with other fonts, but definitely not perfect). If your editor used elastic tabstops, the plain text table would look right, and it would be easily converted to an XHTML table. It doesn't solve the colspan or rowspan issue. My personal thoughts are: * I like the idea of one colspan per row - more than that, and maybe you should just use HTML. This would allow a simpler syntax. * I am increasingly unconvinced that I should worry about rowspans, and require HTML for that. * Every editor should support a standardized approach to elastic tabstops. Too bad I can't make this happen. Keeping in mind that my own goal for MMD is to provide an easy to write/ easy to read syntax for the 80-90% of tables that people write, at the expense of requiring HTML for the other group of complicate tables out there, I think there is hope for a table syntax built (almost?) entirely out of whitespace markers. Thoughts? F- Simon Bull wrote: Okay, thanks for your input, David. Tables with lots of narrow columns are not so rare they can be dismissed; they are useful for matrices of numbers, for example. How about an (entirely optional) addition to the existing multimarkdown pipe syntax, specifically for cells which span many cols? A number followed immediately by a pipe would be taken as the colspan. So this; | This cell spans 7 cols, and has less spa ||| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | would be exactly equivalent to this; | This cell spans 7 cols, and has more space 7| | ColA | ColB | ColC | ColD | ColE | ColF | ColG | ---+--+--+--+--+--+--+--+ 1 | A1 | B1 | C1 | D1 | E1 | F1 | G1 | It contains 1 ugly metadata character, true. It is a matter of personal taste as to whether you find 6 additional pipes or 1 digit more intrusive, so why not provide authors with the choice? The advantage of the digit meta-character, of course, is the additional space in the cell to write content. The real problem is that *neither* of these options is entirely natural to either the author or the reader. Thinking some more, I realise that neither metadata option is required at all to parse a table row correctly when there is only a single colspan cell in a row _if_ we have a distinct cell-delimiter which denotes a colspanning cell. -- Fletcher T. Penney fletc...@fletcherpenney.net Every so often, I like to go to the window, look up, and smile for a satellite picture. - Steven Wright smime.p7s Description: S/MIME Cryptographic Signature ___ 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 Fortinmichel.for...@michelf.com 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
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 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
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 da...@kineticode.comwrote: 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 Tue, Jun 23, 2009 at 9:45 PM, Waylan Limbergway...@gmail.com 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 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 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: No Markdown in divs or tables ?
On Thu, Apr 23, 2009 at 06:07, Sherwood Botsford sgbotsf...@gmail.com wrote: There is also a flag inside multimarkdown that can be set to work inside what it considers block level tags. I ended up setting this, and forgetting it. The reason I initially asked this was because I've seen MojoMojo-powered sites doing Markdown in divs just fine (e.g. http://formfu.org). It turns out that indeed MojoMojo uses Multimarkdown with the markdown_in_html_blocks flag set to true[^mm]. What surprises me is the rationale of disabling Markdown processing in divs. [^mm]: http://github.com/marcusramberg/mojomojo/blob/477908cf0de52a8a4dcf58887363a70f315731f9/lib/MojoMojo/Formatter/Markdown.pm Dan ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: No Markdown in divs or tables ?
On Thu, Apr 23, 2009 at 3:15 PM, Dan Dascalescu ddascalescu+markd...@gmail.com wrote: What surprises me is the rationale of disabling Markdown processing in divs. Go re-read the first three paragraphs of the docs on inline html [1]. Processing markdown within divs just doesn't fit in with the purpose of markdown as stated there (i.e.: writing format v. publishing format). The fact is, a div, although meaningless in itself, is for publishing purposes. Therefore, if you really want it, markdown allows it - but your on you own. In other words, you have to write all the html inside it as well. Makes sense to me. [1]: http://daringfireball.net/projects/markdown/syntax#html -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: No Markdown in divs or tables ?
Go re-read the first three paragraphs of the docs on inline html [1]. Processing markdown within divs just doesn't fit in with the purpose of markdown as stated there (i.e.: writing format v. publishing format). The fact is, a div, although meaningless in itself, is for publishing purposes. Indeed, just like CSS is for presentation and even progressive MultiMarkdown only allows a small subset of it: [image]: http://path.to/image Image title width=40px height=400px style=border 1px black solid; But I must ask: From a utilitarian standpoint, does it benefit anyone that Markdown doesn't parse markup inside divs? Dan ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: wrapped cell contents in tables
On Feb 26, 2009, at 5:37 AM, Benoit Perdu - TransMékong wrote: David's syntax could even be offered as an alternative within each scheme --though on second sight colons inside the text of a cell might make it very tricky to parse correctly. I don't think that this would be a problem, because there will always be white space in front of the colon, and that's pretty unusual anywhere else (the current definition list syntax notwithstanding). But it's worth keeping in mind, for sure. Best, David ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Tables
@John: Thank you for pointing me to those table syntax ideas. They are all sensible, but look like hard work for the user. Since there is no standard, I'd like to suggest a couple of possibilities and get people's comments. Design goals: - A table should look like a table in plain text - It must be easy to create - It must be flexible about how much text can go in a cell - It shouldn't force you to use a fixed-width font Suggestion 1: - A table begins with a header row where columns are separated by |s. It ends with a blank line. - It can optionally include lines of -s, which are ignored when generating html - Within a table, columns are separated by either a tab or 3 or more spaces. Actual alignment of text is up to the user. Alignment varies of course depending on font. In my examples below, I have aligned the columns _for my email editor_. - If you want more control over a particular cell or row, you can use an html cell or row - If you need more control than that, use an html table Example: | Wine | Tasting notes Black Stump Bordeauxpeppermint flavoured Burgundy Sydney Syrupranks among the world's best sugary wines Château Bluelingering afterburn Old Smokey 1968 compares favourably to a Welsh claret 1970 Coq du Rod Laver recommended by the Australian Wino Society Melbourne Old-and-Yellowa good fighting wine is, which is particularly heavy and best suited for hand-to-hand combat. td colspan='2' class='caption'Table: Lesser Australian wines/td Idea 2: Use a table tag to mark a table block. If the contents are not html, then convert them table class='my-table-css' WineTasting notes Château Chunder a fine wine which really opens up the sluices at both ends. Sydney Syrupranks among the world's best sugary wines Château Bluelingering afterburn Old Smokey 1968 compares favourably to a Welsh claret 1970 Coq du Rod Laver recommended by the Australian Wino Society Melbourne Old-and-Yellowa good fighting wine is, which is particularly heavy and best suited for hand-to-hand combat. /table Pros: can provide class information and border settings. Idea 3: Use a caption at the end of the table to mark a table block, with empty captions being allowed. Example: WineTasting notes Black Stump Bordeauxpeppermint flavoured Burgundy Sydney Syrupranks among the world's best sugary wines Château Bluelingering afterburn. Old Smokey 1968 compares favourably to a Welsh claret 1970 Coq du Rod Laver recommended by the Australian Wino Society Melbourne Old-and-Yellowa good fighting wine is, which is particularly heavy and best suited for hand-to-hand combat. Table: Lesser Australian wines What do you think? Regards, Daniel ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Tables
On Thu, Feb 19, 2009 at 4:16 AM, Daniel Winterstein daniel.winterst...@gmail.com wrote: @John: Thank you for pointing me to those table syntax ideas. They are all sensible, but look like hard work for the user. Since there is no standard, I'd like to suggest a couple of possibilities and get people's comments. Well, if I was to implement a table feature, I would just copy PHP's implementation. It's already well documented, in use, and has at least one copy (in MultiMarkdown) with embellishments. Why reinvent the wheel? Oh, and looking at your suggestions, they all look like a bunch of jumbled up randomly spaced text. Yes, I made sure my email client was set to fixed width, but still, my eyes couldn't follow the columns. As JG states, readability comes before writability, so we make the author add in the pipes (more work to write), so the reader can easily read it. -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Tables
- A table should look like a table in plain text - It must be easy to create - It must be flexible about how much text can go in a cell - It shouldn't force you to use a fixed-width font I agree with the comment that the first and last desiderata are in tension. Since one of the guiding goals of markdown is to be *readable*, I decided in pandoc to go for the first and forget about the last. So, here's what a simple table looks like in pandoc -- pretty much just how you'd naturally write it in a plain text email (assuming you use a fixed-width font): Right Left Center Default --- -- -- --- 12 121212 123 123 123 123 1 1 1 1 Table: Demonstration of simple table syntax. As you can see, these simple tables also allow the user to specify the alignment of columns, and allow the user to specify a caption, all without anything that looks like markup. (I suppose the English-centricism of the caption syntax is objectionable. It would also be nice to have more flexibility in indicating borders. So there's room for improvement on this model.) Another desideratum is that table cells should not be limited to one line. So pandoc also allows tables like this: - Centered Default Right Left HeaderAligned Aligned Aligned --- --- --- - Firstrow12.0 Example of a row that spans multiple lines. Secondrow 5.0 Here's another one. Note the blank line between rows. - Table: Here's the caption. It, too, may span multiple lines. In fact, an even more general table syntax is needed, and eventually pandoc will probably support reStructuredText-style box tables, which allow arbitrary block-level elements in cells. Your comment suggested that you think this is too much work for the writer. But John Gruber has emphasized that markdown is meant to be a format that is easy on the *reader* (as well as the writer); markdown documents should look good on their own, without any conversion to another format. None of the table syntaxes that don't force a fixed width font really satisfy that, in my view. So that's the rationale behind pandoc's table syntax -- though I certainly understand why others made different decisions. Best, John +++ Daniel Winterstein [Feb 19 09 09:16 ]: @John: Thank you for pointing me to those table syntax ideas. They are all sensible, but look like hard work for the user. Since there is no standard, I'd like to suggest a couple of possibilities and get people's comments. Design goals: - A table should look like a table in plain text - It must be easy to create - It must be flexible about how much text can go in a cell - It shouldn't force you to use a fixed-width font Suggestion 1: - A table begins with a header row where columns are separated by |s. It ends with a blank line. - It can optionally include lines of -s, which are ignored when generating html - Within a table, columns are separated by either a tab or 3 or more spaces. Actual alignment of text is up to the user. Alignment varies of course depending on font. In my examples below, I have aligned the columns _for my email editor_. - If you want more control over a particular cell or row, you can use an html cell or row - If you need more control than that, use an html table Example: | Wine | Tasting notes Black Stump Bordeaux peppermint flavoured Burgundy Sydney Syrup ranks among the world's best sugary wines Château Blue lingering afterburn Old Smokey 1968 compares favourably to a Welsh claret 1970 Coq du Rod Laver recommended by the Australian Wino Society Melbourne Old-and-Yellow a good fighting wine is, which is particularly heavy and best suited for hand-to-hand combat. td colspan='2' class='caption'Table: Lesser Australian wines/td Idea 2: Use a table tag to mark a table block. If the contents are not html, then convert them table class='my-table-css' Wine Tasting notes Château Chunder a fine wine which really opens up the sluices at both ends. Sydney Syrup ranks among the world's best sugary wines Château Blue lingering afterburn Old Smokey 1968 compares favourably to a Welsh claret 1970 Coq du Rod Laver recommended by the Australian Wino Society Melbourne Old-and-Yellow a good fighting wine is, which
Tables
Are there any standards emerging for how to represent tables in Markdown? Regards, - Daniel Dr Daniel Winterstein Winterwell Associates Ltd tel: 0772 5172 612 http://www.winterwell.com Registered in Scotland, company no. SC342991 ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
Re: Tables
+++ Daniel Winterstein [Feb 18 09 08:01 ]: Are there any standards emerging for how to represent tables in Markdown? The only standard way is to use HTML. Different extensions to markdown syntax have made different decisions about tables: http://johnmacfarlane.net/pandoc/README.html#tables http://michelf.com/projects/php-markdown/extra/#table http://fletcherpenney.net/multimarkdown/users_guide/multimarkdown_syntax_guide/ If you look in the archives of this list, you'll find some discussion of the pros and cons of various approaches. But there's no emerging standard, to my knowledge. John ___ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
