From gerald at vanbeta.com Thu Feb 5 02:27:07 2009 From: gerald at vanbeta.com (Gerald Bauer) Date: Thu, 5 Feb 2009 08:27:07 +0100 Subject: [ANN] Slide Show (S9) Gem V0.7 - Better Support for More Markdown (Ruby) Libs and More Message-ID: <1f058eab0902042327r6130edc9l2eed3ea5ae2cf335@mail.gmail.com> Hello, == What's new in 0.7? I removed the dependency on Maruku (and Oniguruma) and now allow and check for optional installed Markdown libraries/gems. For now the search order for markdown libraries is first come, first serve, that is: rdiscount > rpeg-markdown > maruku > bluecloth (fallback, always present because it's required in gem spec). If you want to use rdiscount as your markdown library install it using RubyGems e.g. gem install rdiscount Same goes for rpeg-markdown or maruku and so on. That's it. Questions and comments welcome. Send them along here or to the S5, S6, S9 and friends web slide show forum/mailing list @ http://groups.google.com/group/webslideshow Cheers. - Gerald PS: What's Slide Show (S9)? A Ruby gem that lets you create slide shows and author slides in plain text using a wiki-style markup language that's easy-to-write and easy-to-read (hint: Markdown!). The Slide Show (S9) project also collects and welcomes themes and ships "out-of-the-gem" with built-in support for "loss free" gradient vector graphics themes and more. Find out more @ http://slideshow.rubyforge.org And find an all-in-one-web-page live demo (w/ three CSS stylesheets - projection, outline, print) and quick start tutorial online @ http://slideshow.rubyforge.org/tutorial.html S9/S6 tip: Use the T key to toggle between outline and projection/presentation mode. From joehall at gmail.com Mon Feb 9 15:40:55 2009 From: joehall at gmail.com (Joseph Lorenzo Hall) Date: Mon, 9 Feb 2009 15:40:55 -0500 Subject: b2evolution Markdown Plugin v0.3 Message-ID: <928946aa0902091240j6266217cm7a653fbf7993d4d7@mail.gmail.com> I've updated my Markdown plugin for the multiblog software b2evolution: http://josephhall.org/nqb2/index.php/2009/02/09/b2evomd It now uses a version of Michel Fortin's PHP-Markdown 1.0.1m with implicit link support (by uncommenting the relevant lines in the `doAnchors` function). best, Joe -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ From daniel.winterstein at gmail.com Wed Feb 18 03:01:05 2009 From: daniel.winterstein at gmail.com (Daniel Winterstein) Date: Wed, 18 Feb 2009 08:01:05 +0000 Subject: Tables Message-ID: 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 From david at kineticode.com Wed Feb 18 12:33:47 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 09:33:47 -0800 Subject: Disambiguate List Item Followed by Code Block Message-ID: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> Howdy, Quick question: Since list items with multiple paragraphs need to be indented four spaces, and code blocks are also indented four spaces, is there any way to disambiguate a list followed by a code block? Example: * This is a list item. * And so is this. Is this a second paragraph in the second list item, or a code block? It looks like Markdown.pl and discount agree that it should be a second paragraph. If that is indeed the standard, what should I do if I actually want to follow a list with a code block? Many thanks, David From jgm at berkeley.edu Wed Feb 18 12:50:09 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Wed, 18 Feb 2009 09:50:09 -0800 Subject: Disambiguate List Item Followed by Code Block In-Reply-To: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> References: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> Message-ID: <20090218175008.GA18319@berkeley.edu> +++ David E. Wheeler [Feb 18 09 09:33 ]: > Howdy, > > Quick question: Since list items with multiple paragraphs need to be > indented four spaces, and code blocks are also indented four spaces, is > there any way to disambiguate a list followed by a code block? Example: > > * This is a list > item. > * And so is this. > > Is this a second paragraph in the second list item, > or a code block? > > It looks like Markdown.pl and discount agree that it should be a second > paragraph. If that is indeed the standard, what should I do if I actually > want to follow a list with a code block? You can insert an HTML comment between them. It's a kludge, but that's the only way I know of. * This is a list item. * And so is this. Definitely a code block. From jgm at berkeley.edu Wed Feb 18 12:54:51 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Wed, 18 Feb 2009 09:54:51 -0800 Subject: Tables In-Reply-To: References: Message-ID: <20090218175450.GB18319@berkeley.edu> +++ 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 From david at kineticode.com Wed Feb 18 13:02:29 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 10:02:29 -0800 Subject: Disambiguate List Item Followed by Code Block In-Reply-To: <20090218175008.GA18319@berkeley.edu> References: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> <20090218175008.GA18319@berkeley.edu> Message-ID: <9E4E0036-619C-4EDB-B353-28440110DE20@kineticode.com> On Feb 18, 2009, at 9:50 AM, John MacFarlane wrote: > You can insert an HTML comment between them. It's a kludge, but > that's the only way I know of. > > * This is a list > item. > * And so is this. > > > > Definitely a code block. Ow. Yeah, I'd never do that in an email, of course, so?yuck. Well, I just hope that I never have to put a code block immediately after a list. I can't think of a circumstance in which I would, I'm glad to say, so I think that the choice made by Markdown.pl and discount is the correct one. Thanks for your reply! Best, David From waylan at gmail.com Wed Feb 18 13:19:18 2009 From: waylan at gmail.com (Waylan Limberg) Date: Wed, 18 Feb 2009 13:19:18 -0500 Subject: Disambiguate List Item Followed by Code Block In-Reply-To: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> References: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> Message-ID: On Wed, Feb 18, 2009 at 12:33 PM, David E. Wheeler wrote: > Howdy, > > Quick question: Since list items with multiple paragraphs need to be > indented four spaces, and code blocks are also indented four spaces, is > there any way to disambiguate a list followed by a code block? This was a hotly discussed issue a while back with all sorts of suggestions. Search the archives. I believe the final consensus was to create an alternate markup for codeblocks, which address both this use case and well as consecutive, but separate, codeblocks. However, I believe that only PHP Extra and Python implementations have implemented fenced code blocks. http://michelf.com/projects/php-markdown/extra/#fenced-code-blocks -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg From david at kineticode.com Wed Feb 18 13:37:27 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 10:37:27 -0800 Subject: Disambiguate List Item Followed by Code Block In-Reply-To: References: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> Message-ID: <69DA5A76-E7BE-4C34-AC26-57FB1EEB8375@kineticode.com> On Feb 18, 2009, at 10:19 AM, Waylan Limberg wrote: > This was a hotly discussed issue a while back with all sorts of > suggestions. Search the archives. I believe the final consensus was to > create an alternate markup for codeblocks, which address both this use > case and well as consecutive, but separate, codeblocks. However, I > believe that only PHP Extra and Python implementations have > implemented fenced code blocks. > > http://michelf.com/projects/php-markdown/extra/#fenced-code-blocks Ah, right, I forgot about those. Definitely a better workaround. Thanks, David From david at kineticode.com Wed Feb 18 13:44:03 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 10:44:03 -0800 Subject: A Modest Definition List Proposal Message-ID: Howdy, I've been thinking a lot about definition list syntax, and what I did and didn't like about the PHP Markdown Extra syntax (which seems to be a de-facto standard, discount notwithstanding, yes?). What I came up with is a single character change to the PHP Markdown Extra syntax. I just published a detailed explanation of my thoughts and reasoning for this on [my blog](http://justatheory.com/computers/markup/modest-markdown-proposal.html ). If you would excuse the temerity of my late entry into what I'm sure has been a contentious issue, I would love feedback. In a nutshell, I embrace the PHP Markdown Extra syntax, with one change: I would like to see the colon replaced with a tilde (for backwards compatibility, both should be supported). That means that a simple definition list would look like this: > Apple: > ~ Pomaceous fruit of plants of the genus Malus in the family > Rosaceae. > ~ An american computer company. > > Orange: > ~ The fruit of an evergreen tree of the genus Citrus. And a more complicated one would look like this: > Term 1: > > ~ This is a definition with two paragraphs. Lorem ipsum > dolor sit amet, consectetuer adipiscing elit. Aliquam > hendrerit mi posuere lectus. > > Vestibulum enim wisi, viverra nec, fringilla in, laoreet > vitae, risus. > > ~ Second definition for term 1, also wrapped in a paragraph > because of the blank line preceding it. > > Term 2: > > ~ This definition has a code block, a blockquote and a list. > > code block. > > > block quote > > on two lines. > > 1. first list item > 2. second list item See my blog entry for more detailed description of why I prefer the tilde to the colon for this purpose. The best things about it are that it makes for a more natural bullet, already has precedent in dictionaries, and suggest equivalency if you're familiar with mathematics, which makes for a nice mnemonic. Comments? Has this ship already sailed? Best, David From waylan at gmail.com Wed Feb 18 15:19:23 2009 From: waylan at gmail.com (Waylan Limberg) Date: Wed, 18 Feb 2009 15:19:23 -0500 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: On Wed, Feb 18, 2009 at 1:44 PM, David E. Wheeler wrote: [snip] > > In a nutshell, I embrace the PHP Markdown Extra syntax, with one change: I > would like to see the colon replaced with a tilde (for backwards > compatibility, both should be supported). That means that a simple > definition list would look like this: > [snip] > Comments? Has this ship already sailed? You make a convincing argument. And I must admit your proposal is very nice to look at/read/write. But if it ain't broke, don't fix it. The current implementation was set before I came along some few years ago, and I have never searched through the archives to see how it came about or why. But, people have been using it for this long without issue and there are already numerous existing documents out there that use it, so I see no reason to change it. In fact that last point (numerous existing documents) seems to be the de-facto response to any suggested changes on this list - and understandably so. No doubt that's why you suggested leaving the existing syntax in place, but then we would have two ways to define deflists. What happens when an author mixes the two? Ack! Yeah, this ship has sailed IMO. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg From david at kineticode.com Wed Feb 18 15:36:56 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 12:36:56 -0800 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: <181404B1-4D9D-48D0-9A4E-6EF8903F897D@kineticode.com> On Feb 18, 2009, at 12:19 PM, Waylan Limberg wrote: >> Comments? Has this ship already sailed? > > You make a convincing argument. And I must admit your proposal is very > nice to look at/read/write. Thank you. > But if it ain't broke, don't fix it. > > The current implementation was set before I came along some few years > ago, and I have never searched through the archives to see how it came > about or why. But, people have been using it for this long without > issue and there are already numerous existing documents out there that > use it, so I see no reason to change it. In fact that last point > (numerous existing documents) seems to be the de-facto response to any > suggested changes on this list - and understandably so. No doubt > that's why you suggested leaving the existing syntax in place, but > then we would have two ways to define deflists. What happens when an > author mixes the two? Ack! Yeah, this ship has sailed IMO. I don't think it's a problem to have two different kinds of bullets for definition list items; after all, you can already use +, -, or * for unordered lists. And you can mix them without penalty, so the same would be true here. FWIW, the change to MultiMarkdown.pl to make this work would just be this: --- bin/MultiMarkdown.pl.orig 2008-01-18 15:08:43.000000000 -0800 +++ bin/MultiMarkdown.pl 2009-02-18 12:28:47.000000000 -0800 @@ -2559,7 +2559,7 @@ my $definition = qr{ \n?[ ]{0,$less_than_tab} - \:[ \t]+(.*?)\n + [:~][ \t]+(.*?)\n ((?=\n*[ ]{0,$less_than_tab}\S)|\n\n|\Z) # Lookahead for non-space at line-start, # two returns, or end of doc }sx; Plus documentation, of course. Doesn't get much simpler than that. Thanks for your reply. Best, David From david at kineticode.com Wed Feb 18 16:46:23 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 13:46:23 -0800 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: On Feb 18, 2009, at 10:44 AM, David E. Wheeler wrote: > See my blog entry for more detailed description of why I prefer the > tilde to the colon for this purpose. The best things about it are > that it makes for a more natural bullet, already has precedent in > dictionaries, and suggest equivalency if you're familiar with > mathematics, which makes for a nice mnemonic. > > Comments? Has this ship already sailed? Aristotle was kind enough to point me to some older posts on the subject of definition lists, where I saw this message from Mssr. Gruber: On Jul 27, 2005, at 7:33 AM, John Gruber wrote: > And since the ones with multiple terms and/or definitions are the > exception, not the norm, I think in the common cases, you'd wind up > with something that looks like this: > > Term 1:: Definition a blah blah blah blah blah > Term 2:: Definition b foo bar baz > Term 3:: Definition c even more blah blah blah Was this ever implemented? I haven't noticed it in the documentation for PHP Markdown Extra or MultiMarkdown. I think that, using the tilde as I've suggested in this thread, this can be even better: Term 1 ~ Definition a blah blah blah blah blah Term 2 ~ Definition b foo bar baz Term 3 ~ Definition c even more blah blah blah Basically, it's the same rule, only you don't have to have a newline before the definition starts. Also, the single ~ is a little less ?unnatural? looking than the double : (and I say that as a Perl hacker, so I'm used to ?::?!). Best, David From tom at jumpingrock.net Wed Feb 18 17:50:32 2009 From: tom at jumpingrock.net (Tom Humiston) Date: Wed, 18 Feb 2009 17:50:32 -0500 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> A problem I see with your suggestion about not including newlines is that interpreting the form "xxx ~ yyy" as a DT/DD pair precludes the use of " ~ " (space-tilde-space) in some other ways it's likely to be used ~ for instance, as an alternative to the plain hyphen. I also suppose that's why the suggestion in 2005 was for double colons. Colon-newline seems pretty clear, if anything is. (Mind you, I am NOT involved in writing implementations whatsoever; I'm just watching the mailing list.) Tom Humiston On 18 Feb 2009, at 4:46 PM, David E. Wheeler wrote: > On Jul 27, 2005, at 7:33 AM, John Gruber wrote: > >> And since the ones with multiple terms and/or definitions are the >> exception, not the norm, I think in the common cases, you'd wind up >> with something that looks like this: >> >> Term 1:: Definition a blah blah blah blah blah >> Term 2:: Definition b foo bar baz >> Term 3:: Definition c even more blah blah blah > > Was this ever implemented? I haven't noticed it in the documentation > for PHP Markdown Extra or MultiMarkdown. > > I think that, using the tilde as I've suggested in this thread, this > can be even better: > > Term 1 ~ Definition a blah blah blah blah blah > Term 2 ~ Definition b foo bar baz > Term 3 ~ Definition c even more blah blah blah > > Basically, it's the same rule, only you don't have to have a newline > before the definition starts. Also, the single ~ is a little less > ?unnatural? looking than the double : (and I say that as a Perl > hacker, so I'm used to ?::?!). > > Best, > > David From david at kineticode.com Wed Feb 18 17:58:21 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 14:58:21 -0800 Subject: A Modest Definition List Proposal In-Reply-To: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> Message-ID: <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> On Feb 18, 2009, at 2:50 PM, Tom Humiston wrote: > A problem I see with your suggestion about not including newlines is > that interpreting the form "xxx ~ yyy" as a DT/DD pair precludes the > use of " ~ " (space-tilde-space) in some other ways it's likely to > be used ~ for instance, as an alternative to the plain hyphen. Yeah. I think ~~ would work okay, too, and gets around that problem. Term 1 ~~ Definition a blah blah blah blah blah Term 2 ~~ Definition b foo bar baz Term 3 ~~ Definition c even more blah blah blah Although I think that it's a bit of a red herring. > I also suppose that's why the suggestion in 2005 was for double > colons. Colon-newline seems pretty clear, if anything is. (Mind you, > I am NOT involved in writing implementations whatsoever; I'm just > watching the mailing list.) I didn't see anyone suggest tilde for definitions in 2005, though I did notice that Aristotle tried it out for terms. I agree with him that tildes didn't work so well there. :-) Best, David From pagaltzis at gmx.de Wed Feb 18 18:40:07 2009 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Thu, 19 Feb 2009 00:40:07 +0100 Subject: A Modest Definition List Proposal In-Reply-To: <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> Message-ID: <20090218234007.GB22773@klangraum.plasmasturm.org> * David E. Wheeler [2009-02-19 00:00]: > Although I think that it's a bit of a red herring. I don?t know. John has stated that one of his rules when making design decisions is how likely it is that users will trigger a particular interpretation accidentally when they *don?t* want it. Another is how likely is it that they will choose this construct when writing in plaintext outside of a pre-assumed context that the document is Markdown. The tilde doesn?t seem any more likely to be chosen independently than the colon-based syntaxes, and seems significantly more likely to be used for other meanings. I don?t want to be down on your proposal or anything ? it really looks a whole lot nicer to a reader of the plaintext version. But I think it is a significantly more problematic choice when considering marginally-proficient (or in the context of something like weblog comments, possibly entirely unaware!) writers of Markdown. Thorny problem. :-( Regards, -- Aristotle Pagaltzis // From david at kineticode.com Wed Feb 18 18:53:31 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 15:53:31 -0800 Subject: A Modest Definition List Proposal In-Reply-To: <20090218234007.GB22773@klangraum.plasmasturm.org> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> Message-ID: On Feb 18, 2009, at 3:40 PM, Aristotle Pagaltzis wrote: > * David E. Wheeler [2009-02-19 00:00]: >> Although I think that it's a bit of a red herring. > > I don?t know. John has stated that one of his rules when making > design decisions is how likely it is that users will trigger a > particular interpretation accidentally when they *don?t* want it. > Another is how likely is it that they will choose this construct > when writing in plaintext outside of a pre-assumed context that > the document is Markdown. Right. I actually think that using ~ as a range operator (essentially) is fairly rare outside of electronic circles, at least in US English. > The tilde doesn?t seem any more likely to be chosen independently > than the colon-based syntaxes, and seems significantly more > likely to be used for other meanings. Hrm. I disagree. It's pretty rare outside of personal URLs, IME. And it's a very nice bullet character, not unlike -. > I don?t want to be down on your proposal or anything ? it really > looks a whole lot nicer to a reader of the plaintext version. Thanks! > But I think it is a significantly more problematic choice when > considering marginally-proficient (or in the context of something > like weblog comments, possibly entirely unaware!) writers of > Markdown. > > Thorny problem. :-( I don't think it's too problematic, as tildes are pretty rare. However, one other thing I did play around with, since really I was just looking for a much better character than ?:? to use as a bullet, was an old friend, ?o?: Term 1: o This is a definition with two paragraphs. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus. o Second definition for term 1, also wrapped in a paragraph because of the blank line preceding it. Term 2: o This definition has a code block, a blockquote and a list. code block. > block quote > on two lines. 1. first list item 2. second list item I still prefer ~, as it's more distinctive and offers more useful mnemonics, but I think that o might get around the issues you raise. Still, it looks pretty crappy in the single-line syntax, as it's not really a separator in the same way that ~ is: Term 1 o Definition a blah blah blah blah blah Term 2 o Definition b foo bar baz Term 3 o Definition c even more blah blah blah Thanks for your comments. Best, David From qaramazov at gmail.com Wed Feb 18 19:37:06 2009 From: qaramazov at gmail.com (Yuri Takhteyev) Date: Wed, 18 Feb 2009 16:37:06 -0800 Subject: A Modest Definition List Proposal In-Reply-To: References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> Message-ID: > Right. I actually think that using ~ as a range operator (essentially) is > fairly rare outside of electronic circles, at least in US English. In other words, by at least 5% of the world population. :) But even just looking at the US English, ~ is often used for approximation, for the home directory, for equivalence, etc. So, things like "The cost is ~ $3", "cd to ~ before doing this", "The N needs a ~ over it", "If we assume x ~ y, then" will all suddenly become definition lists? > Term 1 o Definition a blah blah blah blah blah > Term 2 o Definition b foo bar baz > Term 3 o Definition c even more blah blah blah ?. O unico problema ? o "o" do Portugues, que ? um artigo nessa linguagem. (Our friend "o" is a _word_ in some languages.) - yuri -- http://spu.tnik.org/ From joehall at gmail.com Wed Feb 18 19:46:50 2009 From: joehall at gmail.com (Joseph Lorenzo Hall) Date: Wed, 18 Feb 2009 19:46:50 -0500 Subject: A Modest Definition List Proposal In-Reply-To: References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> Message-ID: <928946aa0902181646h19530f78qb484873260e5ca35@mail.gmail.com> Yeah, Markdown users in the hard sciences would trigger that constantly. best, Joe On 2/18/09, Yuri Takhteyev wrote: >> Right. I actually think that using ~ as a range operator (essentially) is >> fairly rare outside of electronic circles, at least in US English. > > In other words, by at least 5% of the world population. :) > > But even just looking at the US English, ~ is often used for > approximation, for the home directory, for equivalence, etc. So, > things like "The cost is ~ $3", "cd to ~ before doing this", "The N > needs a ~ over it", "If we assume x ~ y, then" will all suddenly > become definition lists? > >> Term 1 o Definition a blah blah blah blah blah >> Term 2 o Definition b foo bar baz >> Term 3 o Definition c even more blah blah blah > > ?. O unico problema ? o "o" do Portugues, que ? um artigo nessa linguagem. > > (Our friend "o" is a _word_ in some languages.) > > - yuri > > -- > http://spu.tnik.org/ > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ From david at kineticode.com Wed Feb 18 19:58:38 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 16:58:38 -0800 Subject: A Modest Definition List Proposal In-Reply-To: References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> Message-ID: <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> On Feb 18, 2009, at 4:37 PM, Yuri Takhteyev wrote: >> Right. I actually think that using ~ as a range operator >> (essentially) is >> fairly rare outside of electronic circles, at least in US English. > > In other words, by at least 5% of the world population. :) > > But even just looking at the US English, ~ is often used for > approximation, for the home directory, for equivalence, etc. So, > things like "The cost is ~ $3", "cd to ~ before doing this", "The N > needs a ~ over it", "If we assume x ~ y, then" will all suddenly > become definition lists? Yeah, okay. Forget the one-line format, then. No one has implemented it so far anyway, as near as I can tell. :-) >> Term 1 o Definition a blah blah blah blah blah >> Term 2 o Definition b foo bar baz >> Term 3 o Definition c even more blah blah blah > > ?. O unico problema ? o "o" do Portugues, que ? um artigo nessa > linguagem. > > (Our friend "o" is a _word_ in some languages.) D'oh! Oh yeah! Sorry for the cultural imperialism. :-) Best, David From jgm at berkeley.edu Wed Feb 18 20:01:16 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Wed, 18 Feb 2009 17:01:16 -0800 Subject: Disambiguate List Item Followed by Code Block In-Reply-To: References: <229CFE37-0CCB-4396-AE15-8FD91D430FFC@kineticode.com> Message-ID: <20090219010116.GA32038@berkeley.edu> +++ Waylan Limberg [Feb 18 09 13:19 ]: > On Wed, Feb 18, 2009 at 12:33 PM, David E. Wheeler wrote: > > Howdy, > > > > Quick question: Since list items with multiple paragraphs need to be > > indented four spaces, and code blocks are also indented four spaces, is > > there any way to disambiguate a list followed by a code block? > > This was a hotly discussed issue a while back with all sorts of > suggestions. Search the archives. I believe the final consensus was to > create an alternate markup for codeblocks, which address both this use > case and well as consecutive, but separate, codeblocks. However, I > believe that only PHP Extra and Python implementations have > implemented fenced code blocks. > > http://michelf.com/projects/php-markdown/extra/#fenced-code-blocks pandoc too: http://johnmacfarlane.net/pandoc/README.html#delimited-code-blocks From pagaltzis at gmx.de Wed Feb 18 21:59:41 2009 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Thu, 19 Feb 2009 03:59:41 +0100 Subject: A Modest Definition List Proposal In-Reply-To: <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> Message-ID: <20090219025941.GA25124@klangraum.plasmasturm.org> * David E. Wheeler [2009-02-19 02:00]: > Yeah, okay. [?] D?oh! Oh yeah! Told you it is a thorny problem. :-( It *looks* simple, yeah? Regards, -- Aristotle Pagaltzis // From david at kineticode.com Thu Feb 19 00:22:04 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 18 Feb 2009 21:22:04 -0800 Subject: A Modest Definition List Proposal In-Reply-To: <20090219025941.GA25124@klangraum.plasmasturm.org> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> <20090219025941.GA25124@klangraum.plasmasturm.org> Message-ID: <644939ED-D4B8-4F4F-836D-EFA77B0D522C@kineticode.com> On Feb 18, 2009, at 6:59 PM, Aristotle Pagaltzis wrote: >> Yeah, okay. [?] D?oh! Oh yeah! > > Told you it is a thorny problem. :-( It *looks* simple, yeah? I still think that ~ works well (at least as well as :) in a non- single-line usage, which is all that's currently implemented with :, anyway. That said, there is no way to get any standard blessed as official here aside from Gruber adding it to Markdown.pl, right? Except for folks adding their own preferred methods to the existing implementations? Best, David From qaramazov at gmail.com Thu Feb 19 01:52:45 2009 From: qaramazov at gmail.com (Yuri Takhteyev) Date: Wed, 18 Feb 2009 22:52:45 -0800 Subject: A Modest Definition List Proposal In-Reply-To: <644939ED-D4B8-4F4F-836D-EFA77B0D522C@kineticode.com> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> <20090219025941.GA25124@klangraum.plasmasturm.org> <644939ED-D4B8-4F4F-836D-EFA77B0D522C@kineticode.com> Message-ID: > That said, there is no way to get any standard blessed as official here > aside from Gruber adding it to Markdown.pl, right? Except for folks adding > their own preferred methods to the existing implementations? Correct. Or one could say there is no way to get any standard blessed as official here period. The closest you can get is to convince Michel to add it to Markdown Extra, in which case there is a reasonable chance that some of the other implementations will add optional support for it. In this particular case, I find it hard to see this proposal going very far, though. (Of course, Michel can prove me wrong.) You of course can implement it for yourself. If you are into Python and want to use python markdown [1], we have an extension mechanism that would make adding support for feature like this quite easy. Support for definitions list is already implemented as an extension, so you should be able to extend the classes defined in the extension module, swapping your own regular expression for the default one. (Or, for a quick and dirty solution, copy our module and change ":" to "~" in the regular expression on line 29.) You can then distribute the extension and try to get it adopted. :) - yuri [1]: http://www.freewisdom.org/projects/python-markdown/ -- http://spu.tnik.org/ From daniel.winterstein at gmail.com Thu Feb 19 04:16:10 2009 From: daniel.winterstein at gmail.com (Daniel Winterstein) Date: Thu, 19 Feb 2009 09:16:10 +0000 Subject: Tables Message-ID: @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. Table: Lesser Australian wines Idea 2: Use a table tag to mark a table block. If the contents are not html, then convert them 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 is particularly heavy and best suited for hand-to-hand combat.
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: 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. Table: Lesser Australian wines What do you think? Regards, Daniel From michel.fortin at michelf.com Thu Feb 19 06:48:23 2009 From: michel.fortin at michelf.com (Michel Fortin) Date: Thu, 19 Feb 2009 06:48:23 -0500 Subject: A Modest Definition List Proposal In-Reply-To: References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> <20090219025941.GA25124@klangraum.plasmasturm.org> <644939ED-D4B8-4F4F-836D-EFA77B0D522C@kineticode.com> Message-ID: Le 2009-02-19 ? 1:52, Yuri Takhteyev a ?crit : > Correct. Or one could say there is no way to get any standard blessed > as official here period. The closest you can get is to convince Michel > to add it to Markdown Extra, in which case there is a reasonable > chance that some of the other implementations will add optional > support for it. In this particular case, I find it hard to see this > proposal going very far, though. (Of course, Michel can prove me > wrong.) It seems I've been called into this discussion. :-) Well, that whole thread left me wondering. I'm of opinion that using a tilde is as good as a colon, perhaps even better visually. It has the advantage of looking better when you add a colon at the end of your term (which, I think, happen often enough): Term: : Definition Term: ~ Definition The current syntax using a colon has been there... since PHP Markdown Extra's debuts (July 2005). There is obviously a lot of documents out there using it, so there's not way I'll just change it to something else. As for accepting the tilde as an alternate marker, there's obviously a precedent of that: unordered lists which can be made of `*`, `+`, or `- `, so it wouldn't be counter-nature to add one for definition lists. On the other hand, that precedent was meant to allow other syntaxes in common use to work with Markdown; I'm not sure any syntax we can come with for definition lists is already in common use. Definition lists are already some sort of specialized niche syntax within Markdown and HTML: useful when you need one, but not something a lot of people care for or even know it exists. So in the end I'm pretty much ambivalent to this proposal: I like it but I don't think it's worth wasting another marker character and dealing with possible clashes (legitimate text with a tilde in it). That said, perhaps I'll change my mind the next time I have to write a definition list. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From waylan at gmail.com Thu Feb 19 09:32:46 2009 From: waylan at gmail.com (Waylan Limberg) Date: Thu, 19 Feb 2009 09:32:46 -0500 Subject: Tables In-Reply-To: References: Message-ID: On Thu, Feb 19, 2009 at 4:16 AM, Daniel Winterstein 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 From drdrang at gmail.com Thu Feb 19 10:25:11 2009 From: drdrang at gmail.com (Dr. Drang) Date: Thu, 19 Feb 2009 09:25:11 -0600 Subject: Tables In-Reply-To: References: Message-ID: On Thu, Feb 19, 2009 at 3:16 AM, Daniel Winterstein wrote: > > 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 It seems to me that your first and last design goals are incompatible. A table looks like a table because of its vertical alignment, and there's no way to ensure vertical alignment in plain text unless you use a fixed-width font. To me, PHP Markdown Extra and MultiMarkdown have the right idea. The pipe characters make the table easy to write and are the traditional cell separators in ASCII tables. Once the table is written, it's relatively easy to add spaces to get everything aligned and make the plain text version look good. Getting the plain text aligned also helps you see where you have extra or missing columns. I wrote a [TextMate command][1] for doing this, and I'm sure it wouldn't be difficult to add similar commands to other text editors. -- Dr. Drang [1]: http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/ From jgm at berkeley.edu Thu Feb 19 11:23:00 2009 From: jgm at berkeley.edu (John MacFarlane) Date: Thu, 19 Feb 2009 08:23:00 -0800 Subject: Tables In-Reply-To: References: Message-ID: <20090219162300.GA4602@berkeley.edu> > - 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 12 12 12 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 Header Aligned Aligned Aligned ----------- ------- --------------- ------------------------- First row 12.0 Example of a row that spans multiple lines. Second row 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. > Table: Lesser Australian wines > > > Idea 2: Use a table tag to mark a table block. If the contents are not > html, then convert them > > > 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 is > particularly heavy and best suited for hand-to-hand combat. >
> > 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: > > 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. > Table: Lesser Australian wines > > > What do you think? > Regards, > Daniel > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > From gruber at fedora.net Thu Feb 19 12:42:58 2009 From: gruber at fedora.net (John Gruber) Date: Thu, 19 Feb 2009 12:42:58 -0500 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: On 18 Feb 2009, at 1:44 PM, David E. Wheeler wrote: > What I came up with is a single character change to the PHP Markdown > Extra syntax. I just published a detailed explanation of my thoughts > and reasoning for this on [my blog](http://justatheory.com/computers/markup/modest-markdown-proposal.html > ). Unlike most syntax suggestions, your suggestion to use tilde as the marker for definitions strikes me as genuinely Markdown-ish. I'm not sure it's any better than colon, though. -J.G. From david at kineticode.com Thu Feb 19 12:47:01 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 19 Feb 2009 09:47:01 -0800 Subject: A Modest Definition List Proposal In-Reply-To: References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> <20090219025941.GA25124@klangraum.plasmasturm.org> <644939ED-D4B8-4F4F-836D-EFA77B0D522C@kineticode.com> Message-ID: <22BCA7A1-2F12-43A9-B43C-EA73547586A6@kineticode.com> On Feb 19, 2009, at 3:48 AM, Michel Fortin wrote: > It seems I've been called into this discussion. :-) And thanks for taking the bate. :-) A quick comment: I started using Markdown about six months ago to write the documentation for pgTAP, my PostgreSQL unit-testing framework. Since the format for PostgreSQL documentation is a plain- text README, and I knew I was going to want it in HTML and perhaps other formats, I adopted Markdown for the documentation without a second thought. It felt right, it works almost exactly like I've always worked in email, and I've been absolutely thrilled with the [plain text][1] and [HTML][2] results. [1] https://svn.kineticode.com/pgtap/trunk/README.pgtap [2] https://svn.kineticode.com/pgtap/trunk/README.pgtap It has just been a delight to work with, very rewarding. And I guess I shouldn't be surprised that the community behind it, represented by this list, is no different. I really appreciate you guys taking the time to really ponder a possible change to something you've been using as-is for almost 4 years when a late interloper like myself barges in and says, ?what about this?? Such openness is all to rare in the OSS world, and just makes me love Markdown all the more. So thanks for taking me and my proposal seriously. Later, we'll see if folks are as willing when I look at tables. ;-P > Well, that whole thread left me wondering. I'm of opinion that using > a tilde is as good as a colon, perhaps even better visually. It has > the advantage of looking better when you add a colon at the end of > your term (which, I think, happen often enough): > > Term: > : Definition > > Term: > ~ Definition Yes, much more natural looking to me, and it stands out a bit more; in a lot of non-programming fonts, colons are really tiny. > The current syntax using a colon has been there... since PHP > Markdown Extra's debuts (July 2005). There is obviously a lot of > documents out there using it, so there's not way I'll just change it > to something else. Yes, I was pleased to realize that that one character was the only thing that wasn't working for me in the PHP Markdown Extra syntax. I started pondering the syntax thinking that a more radical change would be necessary to make it appeal to me. But this is so simple and easy to allow for backwards compatibility that I was really happy to have it. Plus, it's dead easy to modify existing implementations to support it, which both makes it an easier sell and makes it easier for me to just do on my own. > As for accepting the tilde as an alternate marker, there's obviously > a precedent of that: unordered lists which can be made of `*`, `+`, > or `-`, so it wouldn't be counter-nature to add one for definition > lists. On the other hand, that precedent was meant to allow other > syntaxes in common use to work with Markdown; I'm not sure any > syntax we can come with for definition lists is already in common > use. Definition lists are already some sort of specialized niche > syntax within Markdown and HTML: useful when you need one, but not > something a lot of people care for or even know it exists. Even with the colon, the Markdown Extra syntax is so much better than any other DL syntax I've seen. So I agree about the lack of precedent in other markup syntaxes. But I didn't know that `*`, `+`, and `-` were there for compatibility; as a user of Markdown, I just thought it was for convenience that I could use either one. In fact, I actually thought they were there so that I could use different bullets at different levels of a nested list, which would be more natural than using just one in plain text. All that is just to say that I think there are two ways to look at the precedent of list bullets, regardless of the history, and that convenience and flexibility apply to the idea of the interchangeability of `:` and `~` in definition lists. > So in the end I'm pretty much ambivalent to this proposal: I like it > but I don't think it's worth wasting another marker character and > dealing with possible clashes (legitimate text with a tilde in it). I think we determined that that was only an issue in single-line term/ definition combinations, which aren't implemented with `::` either, AFAIK. When the `~` has to come at the beginning of the line, it's no worse than the possible conflict of using `-` for an unordered list bullet. > That said, perhaps I'll change my mind the next time I have to write > a definition list. This came up for me because I write a lot of documentation for libraries I write, and many of the functions and methods support a parameter list of arguments. This is a very natural fit for definition lists, so I could potentially use them all the time, like so: ~~~~~~~~~~~~~~~~~~ ### `new()` ### $fsa = FSA::Rules->new( \%params, foo_state => { ... }, bar_state => { ... }, ); Constructs and returns a new FSA::Rules object. An optional first argument is a hash reference that may contain one or more of these keys: start ~ Causes the `start()` method to be called on the machine before returning it. done ~ A value to which to set the `done` attribute. strict ~ A value to which to set the `strict` attribute. state_class ~ The name of the class to use for state objects. Defaults to "FSA::State". Use this parameter if you want to use a subclass of FSA::State. ~~~~~~~~~~~~~~~~~~ I've borrowed this from one of my Perl modules, where the docs are in [POD][3], which I've come to hate, but I could definitely see using something like this when writing documentation elsewhere. For example, PostgreSQL 8.4 supports named parameters on functions, so I'd likely use something like this a *lot* there. [3] http://search.cpan.org/perldoc?perlpod Anyway, if you start writing more definition lists and want to try it, here's a patch for PHP Markdown Extra. :-) ~~~~~~~~~~~~~~~~~~ --- markdown.php.orig 2009-02-19 09:42:43.000000000 -0800 +++ markdown.php 2009-02-19 09:42:45.000000000 -0800 @@ -2400,7 +2400,7 @@ [ ]{0,'.$less_than_tab.'} ((?>.*\S.*\n)+) # $3 = defined term \n? - [ ]{0,'.$less_than_tab.'}:[ ]+ # colon starting definition + [ ]{0,'.$less_than_tab.'}[:~][ ]+ # colon or tilde starting definition ) (?s:.+?) ( # $4 ~~~~~~~~~~~~~~~~~~ I'd add some tests, too, but I haven't found any. Think I'll do it for MultiMarkdown, though. Do you have a repository of some kind I could check out? Thanks, David PS: Sorry to be so long-winded, and, once again, I appreciate your forbearance. From david at kineticode.com Thu Feb 19 12:53:51 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 19 Feb 2009 09:53:51 -0800 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: On Feb 19, 2009, at 9:42 AM, John Gruber wrote: >> What I came up with is a single character change to the PHP >> Markdown Extra syntax. I just published a detailed explanation of >> my thoughts and reasoning for this on [my blog](http://justatheory.com/computers/markup/modest-markdown-proposal.html >> ). > > Unlike most syntax suggestions, your suggestion to use tilde as the > marker for definitions strikes me as genuinely Markdown-ish. I'm not > sure it's any better than colon, though. Thanks John. Like I said, I prefer it to a colon because, in my mind at least, a colon goes at the end of things, not the beginning of things. The colon just looks weird to me, while the tilde does not. I'm speaking purely from a visual communication point of view about the plain-text representation here, of course. But, like I said, it's dead easy to support both in the existing implementations. Best, David From david at kineticode.com Thu Feb 19 12:54:20 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 19 Feb 2009 09:54:20 -0800 Subject: A Modest Definition List Proposal In-Reply-To: <22BCA7A1-2F12-43A9-B43C-EA73547586A6@kineticode.com> References: <77205771-7847-4DFE-93A6-5D927E9F519E@jumpingrock.net> <917DDBED-2544-4AD7-B8EC-3284D6B7A4E1@kineticode.com> <20090218234007.GB22773@klangraum.plasmasturm.org> <26AA7AB8-77C0-47EA-9AB8-970173FD84DC@kineticode.com> <20090219025941.GA25124@klangraum.plasmasturm.org> <644939ED-D4B8-4F4F-836D-EFA77B0D522C@kineticode.com> <22BCA7A1-2F12-43A9-B43C-EA73547586A6@kineticode.com> Message-ID: <735FA7B6-0EEB-4146-BC29-C3CB91AE46C6@kineticode.com> On Feb 19, 2009, at 9:47 AM, David E. Wheeler wrote: > A quick comment: I started using Markdown about six months ago to > write the documentation for pgTAP, my PostgreSQL unit-testing > framework. Since the format for PostgreSQL documentation is a plain- > text README, and I knew I was going to want it in HTML and perhaps > other formats, I adopted Markdown for the documentation without a > second thought. It felt right, it works almost exactly like I've > always worked in email, and I've been absolutely thrilled with the > [plain text][1] and [HTML][2] results. > > [1] https://svn.kineticode.com/pgtap/trunk/README.pgtap > [2] https://svn.kineticode.com/pgtap/trunk/README.pgta Sorry, that second link should have been: [2] http://pgtap.projects.postgresql.org/documentation.html Best, David From gruber at fedora.net Mon Feb 23 11:59:38 2009 From: gruber at fedora.net (John Gruber) Date: Mon, 23 Feb 2009 11:59:38 -0500 Subject: A Modest Definition List Proposal In-Reply-To: References: Message-ID: <7DDBB38B-70C5-41F5-BB10-71B9C030C11B@fedora.net> On 19 Feb 2009, at 12:53 PM, David E. Wheeler wrote: > Thanks John. Like I said, I prefer it to a colon because, in my mind > at least, a colon goes at the end of things, not the beginning of > things. I lean toward colon because I see colons coming not at the beginning or end, but in the middle, between things. In this case, between a term and its definition(s). -J.G. From david at kineticode.com Mon Feb 23 12:34:57 2009 From: david at kineticode.com (David E. Wheeler) Date: Mon, 23 Feb 2009 09:34:57 -0800 Subject: A Modest Definition List Proposal In-Reply-To: <7DDBB38B-70C5-41F5-BB10-71B9C030C11B@fedora.net> References: <7DDBB38B-70C5-41F5-BB10-71B9C030C11B@fedora.net> Message-ID: <3076F80A-7F4B-47A8-8524-8A1C739B058E@kineticode.com> On Feb 23, 2009, at 8:59 AM, John Gruber wrote: >> Thanks John. Like I said, I prefer it to a colon because, in my >> mind at least, a colon goes at the end of things, not the beginning >> of things. > > I lean toward colon because I see colons coming not at the beginning > or end, but in the middle, between things. In this case, between a > term and its definition(s). I can see that, but: 1. The same is true for tildes; even more true, since there is usually a space on either side of a tilde 2. The colon is very hard to see in some fonts; it makes a lousy bullet, IMHO, especially when it's the first character on a line 3. I've been thinking about table syntax, looking at what the OSS databases do, and PostgreSQL has a nice use for colons to show continued records: id | name | description ----+-----------------+------------------------------------ 6 | Inset | An inset element type 8 | Related Stories | A related stories element type. 5 | Illustration | An illustration media type : and I think you know what I mean. 2 | Column | A weekly column story type 10 | Story | A story document type That seems kind of nice to me because a colon is kind of like a broken pipe. But that's for a later discussion, and might not conflict with PHP Markdown Extra's use of a colon for DLs, anyway. As I said, we could support both just as we support `*`, `+`, and `-` for unordered list bullets. Best, David From benoit at transmekong.com Wed Feb 25 01:04:57 2009 From: benoit at transmekong.com (=?UTF-8?B?QmVub2l0IFBlcmR1IC0gVHJhbnNNw6lrb25n?=) Date: Wed, 25 Feb 2009 13:04:57 +0700 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: Message-ID: <49A4DF89.9060008@transmekong.com> Taking David's example further, here is a first try: id | name | description | more info -----+---------+-------------------+----------------- 6 | Inset | An inset element | just one element 8 | Stories | Another element | another element : with 2 lines, without : colons on the left. 9 | Other | Another element | another element : : : with 2 lines, with : : : colons on the left. 5 | Illust. | An illustration | new line, would this do? : : and I think you : Is it parseable? : : know what I mean. The colon at each empty cell looks like vertical ellipsis, that makes it pretty legible Adding a 'wrappable' cell definition would go a long way to make it perfect. From michel.fortin at michelf.com Wed Feb 25 06:52:06 2009 From: michel.fortin at michelf.com (Michel Fortin) Date: Wed, 25 Feb 2009 06:52:06 -0500 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <49A4DF89.9060008@transmekong.com> References: <49A4DF89.9060008@transmekong.com> Message-ID: Le 2009-02-25 ? 1:04, Benoit Perdu - TransM?kong a ?crit : > Taking David's example further, here is a first try: > > id | name | description | more info > -----+---------+-------------------+----------------- > 6 | Inset | An inset element | just one element > 8 | Stories | Another element | another element > : with 2 lines, without > : colons on the left. > 9 | Other | Another element | another element > : : : with 2 lines, with > : : : colons on the left. > 5 | Illust. | An illustration | new line, would this do? > : : and I think you : Is it parseable? > : : know what I mean. I doubt the no-colon-on-the-left lines will work. I mean, how do you know you're writing in fourth column without counting whitespace? (And if count whitespace it's unusable with proportional fonts.) > The colon at each empty cell looks like vertical ellipsis, that > makes it > pretty legible Colons are a nice way to do it, but I doubt the table will be readable by anyone not already aware of the syntax. To see what I mean, just take a look at the last column and forget for a moment that you know the difference in meaning between ":" and "|". It then looks like one big paragraph of continuous text. You can disambiguate by reading the text, then figure out the meaning of "|" and ":", but that's removing the usefulness of a table which should be scannable at first glance. If you want multiple lines per cell, I'd suggest using a more explicit grid, something like this: id | name | description | more info ====|=========|==================|===================== 6 | Inset | An inset element | just one element ----|---------|------------------|--------------------- 8 | Stories | Another element | another element | | | with 2 lines ----|---------|------------------|--------------------- 9 | Other | Another element | another element | | | with 2 lines ----|---------|------------------|--------------------- 5 | Illust. | An illustration | line breaks are not | | andn I think you | possible in a table | | know what I mena.| This is totally unambiguous and easy to scan for the reader. The problem is that, even though it's easy to read, it's also more tedious to write. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From sgbotsford at gmail.com Wed Feb 25 09:57:20 2009 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Wed, 25 Feb 2009 07:57:20 -0700 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> Message-ID: <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> > ? ? ? ? id | ?name ? | ?description ? ? | ? ? ?more info > ? ? ? ?====|=========|==================|===================== > ? ? ? ? ?6 | Inset ? | An inset element | just one element > ? ? ? ?----|---------|------------------|--------------------- > ? ? ? ? ?8 | Stories | Another element ?| another element > ? ? ? ? ? ?| ? ? ? ? | ? ? ? ? ? ? ? ? ?| with 2 lines > ? ? ? ?----|---------|------------------|--------------------- > ? ? ? ? ?9 | Other ? | Another element ?| another element > ? ? ? ? ? ?| ? ? ? ? | ? ? ? ? ? ? ? ? ?| with 2 lines > ? ? ? ?----|---------|------------------|--------------------- > ? ? ? ? ?5 | Illust. | An illustration ?| line breaks are not > ? ? ? ? ? ?| ? ? ? ? | andn I think you | possible in a table > ? ? ? ? ? ?| ? ? ? ? | know what I mena.| > > This is totally unambiguous and easy to scan for the reader. The problem is > that, even though it's easy to read, it's also more tedious to write. > One minor change. You don't need pipes in the horizontal separator lines. E.g: id | name | description | more info ==================================================== I suspect that if you were going to write a lot of tables, you'd write a perl program that would take an existing table that you slopped together, and would fix the spacing of pipes on all the lines to match the pipe spacing on the first line. Tables are critters where formatting is tangled with content. And with proportional type, a text only system requires agreement on tab spacing at minimum to get anything to look right. (I'm not a fan of monospace, so all these examples are wonky.) Add to this, the need for centering, the need for column spans. Allignment could be done with your horizontal separators. |-----------| Means use your default alignment. (Same as cell above) |<--------| Means left alignment. The < can appear anywhere between the |'s |---------->| Means right alignment. |-----=----| means center alignment. Column spans could be done by replacing the pipe with an underscore. |=========_===========| |This is a cell that spans two| columns, and is centred. |------------------|--------------| |Column 1 |Column 2| I'm working in a proportional font, so the above example is sure to be wonky. Note that these two ideas are contradictory. To merge, them (makes reading slightly harder, but writing slightly easier. | Default alignment | |< Left Alignment <| |> Right Alignment >| |= Centered alignment =| The alignment tags don't have to be paired, but can be for eye candy purposes. || Spans two columns of the stuff below | | Column 1 | Column 1 | -- Sherwood Botsford Sherwood's Forests Warburg, Alberta T0C 2T0 http://www.sherwoods-forests.com 780-848-2548 From david at kineticode.com Wed Feb 25 12:40:21 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 25 Feb 2009 09:40:21 -0800 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <49A4DF89.9060008@transmekong.com> References: <49A4DF89.9060008@transmekong.com> Message-ID: On Feb 24, 2009, at 10:04 PM, Benoit Perdu - TransM?kong wrote: > Taking David's example further, here is a first try: > > id | name | description | more info > -----+---------+-------------------+----------------- > 6 | Inset | An inset element | just one element > 8 | Stories | Another element | another element > : with 2 lines, without > : colons on the left. > 9 | Other | Another element | another element > : : : with 2 lines, with > : : : colons on the left. > 5 | Illust. | An illustration | new line, would this do? > : : and I think you : Is it parseable? > : : know what I mean. > > The colon at each empty cell looks like vertical ellipsis, that > makes it > pretty legible Yes, nice. I think I like how it looks without the left colons better, though it could potentially work both ways. > Adding a 'wrappable' cell definition would go a long way to make it > perfect. Do you mean something more should be added, or that the use of `:` to define wrapped cells in this example is what goes a long way? Thanks, David From david at kineticode.com Wed Feb 25 12:37:39 2009 From: david at kineticode.com (David E. Wheeler) Date: Wed, 25 Feb 2009 09:37:39 -0800 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: On Feb 25, 2009, at 6:57 AM, Sherwood Botsford wrote: > One minor change. You don't need pipes in the horizontal separator > lines. E.g: > id | name | description | more info > ==================================================== They could be optional; I prefer them. > Tables are critters where formatting is tangled with content. And > with proportional type, a text only system requires agreement on tab > spacing at minimum to get anything to look right. (I'm not a fan of > monospace, so all these examples are wonky.) I think you might be using the wrong markup language, then. The use of monospace fonts is an expectation for reading Markdown. Really, it's the whole point. > Add to this, the need for centering, the need for column spans. > > Allignment could be done with your horizontal separators. > > |-----------| Means use your default alignment. (Same as cell above) > |<--------| Means left alignment. The < can appear anywhere between > the |'s > |---------->| Means right alignment. > |-----=----| means center alignment. I dislike these. I have other ideas for alignment, but I need to do some more thinking and drafting before I have a proposal to submit. > Column spans could be done by replacing the pipe with an underscore. > |=========_===========| > |This is a cell that spans two| > columns, and is centred. > |------------------|--------------| > |Column 1 |Column 2| > > I'm working in a proportional font, so the above example is sure to > be wonky. Yes, and basically illegible. > Note that these two ideas are contradictory. > > To merge, them (makes reading slightly harder, but writing slightly > easier. > > | Default alignment | > |< Left Alignment <| > |> Right Alignment >| > |= Centered alignment =| > > The alignment tags don't have to be paired, but can be for eye candy > purposes. > > > || Spans two columns of the stuff below | > | Column 1 | Column 1 | IMHO, any formatting should be invisible in Markdown. That is, it should be implicit. The use of all these extra characters to show alignment and whatnot makes for ugly text-only tables. Best, David From chad.thecomfychair at gmail.com Wed Feb 25 16:59:47 2009 From: chad.thecomfychair at gmail.com (Chad Nelson) Date: Wed, 25 Feb 2009 16:59:47 -0500 Subject: [ANN] Cpp-Markdown 1.00 Message-ID: <49A5BF53.30106@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce that the Cpp-Markdown project is now available. Cpp-Markdown is a Markdown-to-HTML translator written in C++, and meant for use within C++ programs (rather than web applications). The code is still a little rough around the edges, but the results are pretty good: it passes all 23 tests in the Markdown test suite, and 12 of the 17 tests in the PHP Markdown test suite, of MDTest 1.1. It is released under the MIT license, so it can be used in other programs (including commercial ones) with almost no limitations. Its official site is here: (I've been trying to add it to the markdown wiki page at as well, but I can't seem to log in there with my reddit.com account information, and there's no visible way to apply for an account on that wiki itself. Could someone with write-access there add it, please? Thanks.) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmlv1MACgkQp9x9jeZ9/wRtgQCgpBqzu+LB8Yl6IIQfCood1KFR RcoAoNJeBzt6NDxHCheiOy+6SDXzRjDB =fXlQ -----END PGP SIGNATURE----- From seumas at idirect.ca Wed Feb 25 20:34:47 2009 From: seumas at idirect.ca (Seumas Mac Uilleachan) Date: Wed, 25 Feb 2009 20:34:47 -0500 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: <49A5F1B7.3010001@idirect.ca> David E. Wheeler wrote: > On Feb 25, 2009, at 6:57 AM, Sherwood Botsford wrote: > >> One minor change. You don't need pipes in the horizontal separator >> lines. E.g: >> id | name | description | more info >> ==================================================== > > They could be optional; I prefer them. > >> Tables are critters where formatting is tangled with content. And >> with proportional type, a text only system requires agreement on tab >> spacing at minimum to get anything to look right. (I'm not a fan of >> monospace, so all these examples are wonky.) > > I think you might be using the wrong markup language, then. The use of > monospace fonts is an expectation for reading Markdown. Really, it's > the whole point. Wait, what? Monospace is an expectation?!? I have never used monospace in my e-mail programs. Isn't THAT the main expectation of Markdown? That it approximates e-mail writing? I think the only time I actually use monospace fonts is with Alt-F1 (or Ctrl-Alt) Admittedly it is easier to create legible text documents with lots of bullets and tables and definition lists if you are using a monospace font but in my experience monospace fonts are generally just harder to read. The beauty of markdown is that you can approximate the spacing of monospace by varying the whitespace. Or just let it be "wonky". (Of course what looks beautiful in one proportional font will be wonky in another anyway) > >> Add to this, the need for centering, the need for column spans. >> >> Allignment could be done with your horizontal separators. >> >> |-----------| Means use your default alignment. (Same as cell above) >> |<--------| Means left alignment. The < can appear anywhere between >> the |'s >> |---------->| Means right alignment. >> |-----=----| means center alignment. > > I dislike these. I have other ideas for alignment, but I need to do > some more thinking and drafting before I have a proposal to submit. > >> Column spans could be done by replacing the pipe with an underscore. >> |=========_===========| >> |This is a cell that spans two| >> columns, and is centred. >> |------------------|--------------| >> |Column 1 |Column 2| >> >> I'm working in a proportional font, so the above example is sure to >> be wonky. > > Yes, and basically illegible. > >> Note that these two ideas are contradictory. >> >> To merge, them (makes reading slightly harder, but writing slightly >> easier. >> >> | Default alignment | >> |< Left Alignment <| >> |> Right Alignment >| >> |= Centered alignment =| >> >> The alignment tags don't have to be paired, but can be for eye candy >> purposes. >> >> >> || Spans two columns of the stuff below | >> | Column 1 | Column 1 | > > IMHO, any formatting should be invisible in Markdown. That is, it > should be implicit. The use of all these extra characters to show > alignment and whatnot makes for ugly text-only tables. > > Best, > > David > > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > From michel.fortin at michelf.com Wed Feb 25 20:52:55 2009 From: michel.fortin at michelf.com (Michel Fortin) Date: Wed, 25 Feb 2009 20:52:55 -0500 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: Le 2009-02-25 ? 9:57, Sherwood Botsford a ?crit : >> id | name | description | more info >> ====|=========|==================|===================== >> 6 | Inset | An inset element | just one element >> ----|---------|------------------|--------------------- >> 8 | Stories | Another element | another element >> | | | with 2 lines >> ----|---------|------------------|--------------------- >> 9 | Other | Another element | another element >> | | | with 2 lines >> ----|---------|------------------|--------------------- >> 5 | Illust. | An illustration | line breaks are not >> | | andn I think you | possible in a table >> | | know what I mena.| >> >> This is totally unambiguous and easy to scan for the reader. The >> problem is >> that, even though it's easy to read, it's also more tedious to write. >> > > One minor change. You don't need pipes in the horizontal separator > lines. E.g: > id | name | description | more info > ==================================================== My idea was to follow the way it currently works for tables in PHP Markdown Extra, which was made this way to make the difference clearer from the header syntax and to allow specifying text alignment for columns. > I suspect that if you were going to write a lot of tables, you'd write > a perl program that would take an existing table that you slopped > together, and would fix the spacing of pipes on all the lines to match > the pipe spacing on the first line. If you're going to write a Perl program for creating Markdown tables, why not create tables in HTML directly? It'd be a lot simpler to write a converter for that, and it would avoid cluttering the syntax with something you need a special program to make anyway. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From waylan at gmail.com Wed Feb 25 21:51:51 2009 From: waylan at gmail.com (Waylan Limberg) Date: Wed, 25 Feb 2009 21:51:51 -0500 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <49A5F1B7.3010001@idirect.ca> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> <49A5F1B7.3010001@idirect.ca> Message-ID: On Wed, Feb 25, 2009 at 8:34 PM, Seumas Mac Uilleachan wrote: > David E. Wheeler wrote: >> >> On Feb 25, 2009, at 6:57 AM, Sherwood Botsford wrote: >>> Tables are critters where formatting is tangled with content. ?And >>> with proportional type, a text only system requires agreement on tab >>> spacing at minimum to get anything to look right. (I'm not a fan of >>> monospace, so all these examples are wonky.) >> >> I think you might be using the wrong markup language, then. The use of >> monospace fonts is an expectation for reading Markdown. Really, it's the >> whole point. > > Wait, what? Monospace is an expectation?!? I have never used monospace in my > e-mail programs. Isn't THAT the main expectation of Markdown? That it > approximates e-mail writing? > Well, I wouldn't say monospace is an expectation, but Markdown does rely heavily (perhaps more so than most) on whitespace. It just so happens that that whitespace is easier for the human eye to "read" when the text is monospace. However, yes, email is rarely written in monospace. Of course, on most cases, the white space is all at the beginning of the line (code blocks, lists) and the different levels of indent are still discernible when not in monospace. So, when the comment is made that the "examples are wonky" because they are not in monospace, then IMO, the proposed syntax fails. We all know that Markdown is to be readable first, writable second. If every reader of the document must read it in monospace, then that's not readable first - it's writable first. I'd also like to point out JB comments [1] that Markdown it supposed to cover only a common subset of HTML. If your trying to represent something more complex, then you need to use HTML. I would say multiline table cells fall into that "more complex" category. I know I'm never going to use any of this overly complex syntax that has been proposed thus far. I'll just write some raw HTML for my table and be done with it quickly. Don't get me wrong, if I have some vary basic tables that can easily be represented with the simplest syntax, then sure, I'll use something link PHP Extra's. Anything more than that will get raw HTML. [1]: http://daringfireball.net/projects/markdown/syntax#html -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg From drdrang at gmail.com Wed Feb 25 22:00:30 2009 From: drdrang at gmail.com (Dr. Drang) Date: Wed, 25 Feb 2009 21:00:30 -0600 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: <9A508A69-F0D3-4845-B1E5-E8431C9E36B5@gmail.com> I had nothing to say about definition lists (remember when that was the topic?), but now that we've moved on to tables and the relative merits of proportional and monospace fonts, I do have some opinions: 1. Regular Markdown--by which I mean Gruber's Markdown.pl--looks good[^1] regardless of whether you're using proportional or monospaced fonts. I can't think of any construct in which the width of the characters makes a difference. 2. Plain text tables almost always look like crap *unless* you're using a monospaced font, because columns always include a mixture of visible characters and spaces. I suspect this is one of the reasons Gruber hasn't put tables into Markdown.pl. 3. Markdown was not intended to cover every situation; it's meant to be a simple, readable substitute for simple (X)HTML. In this spirit, we shouldn't expect table additions to Markdown to be able to handle every type of table, just the simpler types. I like the table syntax of PHP Markdown Extra and MultiMarkdown for this reason. 4. Using a script[^2] to align the pipes of a plain text table is very practical if you're writing in a monospaced font. You can write and edit the table quickly without regard to alignment, then make it readable by applying the script to it. It's much easier to make tables this way than to type them out in HTML. -- Dr. Drang drdrang at gmail.com [^1]: I wish it wouldn't wrap single-paragraph list items in

tags when you separate the items with blank lines (as I've done here), because it encourages the user to smush the list items together to avoid the

s. Lists with longer items look better with some air between them. [^2]: Like the fine script you'll find at [my blog][1]. [1]: http://www.leancrew.com/all-this/2008/08/tables-for-markdown-and-textmate/ From sgbotsford at gmail.com Wed Feb 25 23:18:51 2009 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Wed, 25 Feb 2009 21:18:51 -0700 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: <534004cc0902252018k23b2329fw35a9d55f24fa4afb@mail.gmail.com> > If you're going to write a Perl program for creating Markdown tables, why > not create tables in HTML directly? It'd be a lot simpler to write a > converter for that, and it would avoid cluttering the syntax with something > you need a special program to make anyway. Depends on how you use the program. I end up doing most of my actual coding in vi. In vi I write markdown source, because it's quick, I can sort of see how it lays out, and I don't worry about a billion html tags. I spend my time writing content, not matching tags. In my other writing I use "par" a lot. This is a program to reformat ascii text. It can do clever things like reformat email with multiple quoted levels, to different line lengths without sprinkling >'s everywhere midline. If you are a dedicated markdown user, a perl program that you can pipe a table through to put it in whatever syntax your favorite version of markdown likes, AND such a program removes a lot of the tedium of adjusting the space so that you, the writer can live with it, you have a win. I don't want to have a separate source file for my table, nor do I want to include an html table in my markdown. I want a perl command, or vi macro that takes bad table text (from markdown's view, and my personal view) and turns it into good table text. KIS Tables are complicated. How they are represented in simple text is going to be a compromise between control and legibility. The idea solution would be one that maximizes legibility in simple cases while allowing control short of full html code where the author needs it. -- Sherwood Botsford Sherwood's Forests Warburg, Alberta T0C 2T0 http://www.sherwoods-forests.com 780-848-2548 From michel.fortin at michelf.com Thu Feb 26 05:01:57 2009 From: michel.fortin at michelf.com (Michel Fortin) Date: Thu, 26 Feb 2009 05:01:57 -0500 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <9A508A69-F0D3-4845-B1E5-E8431C9E36B5@gmail.com> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> <9A508A69-F0D3-4845-B1E5-E8431C9E36B5@gmail.com> Message-ID: Le 2009-02-25 ? 22:00, Dr. Drang a ?crit : > 1. Regular Markdown--by which I mean Gruber's Markdown.pl--looks > good[^1] regardless of whether you're using proportional or > monospaced fonts. I can't think of any construct in which the width > of the characters makes a difference. Well, if you want list items spanning on multiple lines to align properly, it's pretty hard to do with spaces using a proportional font. 1. List item spanning on more than one line. > 2. Plain text tables almost always look like crap *unless* you're > using a monospaced font, because columns always include a mixture of > visible characters and spaces. I suspect this is one of the reasons > Gruber hasn't put tables into Markdown.pl. You can sometime use tabs in proportional fonts in some situations. It helps aligning things correctly, and not only for tables, but also with the list item example above. Although if you later view it with a different font it'll probably look like crap too. > 3. Markdown was not intended to cover every situation; it's meant to > be a simple, readable substitute for simple (X)HTML. In this spirit, > we shouldn't expect table additions to Markdown to be able to handle > every type of table, just the simpler types. I like the table syntax > of PHP Markdown Extra and MultiMarkdown for this reason. That's in part why I'm reticent to add a new type of table with cells spanning on multiple rows to PHP Markdown Extra. > 4. Using a script[^2] to align the pipes of a plain text table is > very practical if you're writing in a monospaced font. You can write > and edit the table quickly without regard to alignment, then make it > readable by applying the script to it. It's much easier to make > tables this way than to type them out in HTML. Indeed. I never though of that, but it's a good idea. That said, it's pretty easy to write a properly-aligned table without a script too. I've been doing that for some time. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From Bowerbird at aol.com Thu Feb 26 06:47:10 2009 From: Bowerbird at aol.com (Bowerbird at aol.com) Date: Thu, 26 Feb 2009 06:47:10 EST Subject: monospaced fonts Message-ID: > The use of? monospace fonts > is an expectation for reading Markdown. > Really, it's the whole point. um... no. going way back to "triumph of the nerds", the number-one example steve jobs used to symbolize the absence of any esthetics at microsoft (and thus -- by extension -- inside the head of bill gates) was the fact they found a monospaced font acceptable. it all goes back to a calligraphy class that jobs "dropped in on" while he was at reed. no. if you have a mac, and you're using a monospace font, you _missed_ the point. you missed the _whole_ point. -bowerbird ************** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) -------------- next part -------------- An HTML attachment was scrubbed... URL: From fletcher at fletcherpenney.net Thu Feb 26 06:57:24 2009 From: fletcher at fletcherpenney.net (Fletcher T. Penney) Date: Thu, 26 Feb 2009 06:57:24 -0500 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: On Feb 25, 2009, at 9:57 AM, Sherwood Botsford wrote: > I suspect that if you were going to write a lot of tables, you'd write > a perl program that would take an existing table that you slopped > together, and would fix the spacing of pipes on all the lines to match > the pipe spacing on the first line. Since I write most of my MultiMarkdown documents in TextMate, I (and others) have written Bundles that will do just this. I type out a table using the MMD delimiters (|), and the bundle command takes care of aligning columns and making it look nice. Sadly, I suspect that plain text tables require either the use of tabs (which vary based on the readers application), or fixed whitespace and a monospace font - which is tough to manually write. My thoughts: + I am perfectly willing to change the MMD table syntax if a better alternative (particularly a standard one) comes along + Not everyone uses monospace fonts - as nice as that would be for tables, I think it's not reasonable to expect that to be a requirement for viewing tables + I hope someone out there smarter than me creates a better table syntax ;) F- -- Fletcher T. Penney fletcher at fletcherpenney.net Beauty lies in the hands of the beer holder. - Anonymous From thantos at gmail.com Thu Feb 26 07:19:22 2009 From: thantos at gmail.com (Alexander Williams) Date: Thu, 26 Feb 2009 07:19:22 -0500 Subject: monospaced fonts In-Reply-To: References: Message-ID: <4f0341480902260419n1acad0a5xb3324ffffef372a@mail.gmail.com> On Thu, Feb 26, 2009 at 6:47 AM, wrote: > no. if you have a mac, and you're using a > monospace font, you _missed_ the point. > If you're using a Mac and you're *noy* using a monospaced font for presenting information in which it is important if things line up neatly with other things, you're violating a vital and central tenet of Apple design philosophy. And, no, that is not, "Whatever I want to do is what the right way is." Because that's just dumb. It's "Use the right tool for the job, generally the one that conveys the most embedded information without undue differentiation; elegance, simplicity, efficiency." If you're using a Mac and you're using a monospaced font, you're using a very pretty one that has aesthetic chops, it's insanely regular, and it looks the same as far as arrangement no matter who wrote it and what platform it was generated on. And so, it works with rare fluidity in these days of crying, stomping your feet, and pouting like an immature baboon. If you're going to be trying to communicate structure that requires intuitive, simple understanding of formatted output, you'll be using a monospace font, so that my table and your table while being visually indistinguishable don't turn out different output. "Principle of Least Surprise." You should look it up, sometime. Do you a lot of good, I think. Seems rather obvious, really, dunnit? -- Alexander Williams (thantos at gmail.com) Operation BSU (http://operationbsu.livejournal.com) "Like a morning show. Only interesting. And at night." -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.triantafillidis at gmail.com Thu Feb 26 07:22:45 2009 From: andreas.triantafillidis at gmail.com (Andreas Triantafillidis) Date: Thu, 26 Feb 2009 14:22:45 +0200 Subject: monospaced fonts In-Reply-To: References: Message-ID: <09C40F1A-E696-495B-9098-72B8EF291C83@gmail.com> > no. if you have a mac, and you're using a > monospace font, you _missed_ the point. i beg to differ i use a mac (in fact, I __love__ it), but also use text editors, email (plain text), and I post on a dozen or so blogs using marsedit + markdown filter + markdown parsing on the blog platforms not having monospace fonts would be a huge nuissance in text editors plus, let us not forget that there is a certain aesthetic in the abstract environment of plain text editing (yes, unix shell as well) cheers Andreas Triantafillidis From Bowerbird at aol.com Thu Feb 26 08:00:00 2009 From: Bowerbird at aol.com (Bowerbird at aol.com) Date: Thu, 26 Feb 2009 08:00:00 EST Subject: monospaced fonts Message-ID: alexander said: > If you're using a Mac and you're > _noy_?using a monospaced font > for presenting information in which > it is important if things line up neatly > with other things, you're violating a... there's no reason to have a protracted thread on this topic, so i'll try not to pick nits here... i agree with your (obvious) general point that -- when it is important that things "line up neatly" -- you should make sure things "line up neatly". (and once again, for the monospace font people:) i agree with your (obvious) general point that -- if it is important that things "line up neatly" -- you should make sure things "line up neatly". i hope you will agree with _my_ obvious counter: monospaced fonts aren't the only way to do that. indeed, they aren't even the most _common_ way. (that distinction still goes to the old-fashioned tab, by which i mean computation of the point to write.) in reference to the actual topic of the actual thread, if anyone were to write a markdown authoring-tool -- my favorite is still "showdown", it's very cool -- you'll discover that it's fairly easy to support tables. (even ones that are relatively complex, layout-wise; for instance, determining defaults for alignment is very simple, and they almost always work correctly.) you just discern the columns, size them appropriately, determine cell alignment, and write text at proper spot. so the regular emergence of this thread, reminiscent of punxsatawney phil the groundhog, is really unnecessary. > If you're using a Mac and you're using a monospaced font, > you're using a very pretty one that has?aesthetic?chops, it's > insanely regular, and it looks the same as far as arrangement > no matter?who?wrote it and what platform it was?generated?on. if you say so. but i think most monospaced fonts look pretty much the same, since it's impossible for me to ignore their disastrous kerning... but i don't care. use monospace all day. just don't tell steve, ok? might interfere with his recovery, and we all need him back soon. -bowerbird ************** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) -------------- next part -------------- An HTML attachment was scrubbed... URL: From benoit at transmekong.com Thu Feb 26 08:37:26 2009 From: benoit at transmekong.com (=?UTF-8?B?QmVub2l0IFBlcmR1IC0gVHJhbnNNw6lrb25n?=) Date: Thu, 26 Feb 2009 20:37:26 +0700 Subject: wrapped cell contents in tables In-Reply-To: References: Message-ID: <49A69B16.8080501@transmekong.com> > If you want multiple lines per cell, I'd suggest using a more explicit > grid, something like this: > > id | name | description | more info > ====|=========|==================|===================== > 6 | Inset | An inset element | just one element > ----|---------|------------------|--------------------- > 8 | Stories | Another element | another element > | | | with 2 lines > ----|---------|------------------|--------------------- > 9 | Other | Another element | another element > | | | with 2 lines > ----|---------|------------------|--------------------- > 5 | Illust. | An illustration | line breaks are not > | | andn I think you | possible in a table > | | know what I mena.| > > This is totally unambiguous and easy to scan for the reader. The > problem is that, even though it's easy to read, it's also more tedious > to write. > Reading you a second time, I agree that this would make it more legible. And writing this just entails inserting lines of dashes and pipes, typically of the same pattern as above, so IMO just cut and paste would do the trick. (or, even faster, Ctrl-K - Ctrl-U for the pico users) The one difficulty is that this is incompatible with the present syntax for tables in PHP Markdown Extra. A workaround could be to: * Keep the present syntax valid,that is where the head of the columns are separated from the data by a line of dashes and pipes * Allow for an alternative table syntax as per your scheme here-above, where the head cells are separated by a line of equal signs (=) and pipes, then where any line composed of dashes (-) and pipes (|) means we jump to next row. 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. Benoit From benoit at transmekong.com Thu Feb 26 08:19:37 2009 From: benoit at transmekong.com (=?UTF-8?B?QmVub2l0IFBlcmR1IC0gVHJhbnNNw6lrb25n?=) Date: Thu, 26 Feb 2009 20:19:37 +0700 Subject: wrapped contents in table cells In-Reply-To: References: Message-ID: <49A696E9.2020106@transmekong.com> >> The colon at each empty cell looks like vertical ellipsis, that >> makes it pretty legible > > Yes, nice. I think I like how it looks without the left colons better, > though it could potentially work both ways. > >> Adding a 'wrappable' cell definition would go a long way to make it >> perfect. > > Do you mean something more should be added, or that the use of `:` to > define wrapped cells in this example is what goes a long way? Yes, I meant that implementing such a syntax as this would go a long way towards perfection in my eyes. Thanks Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From drdrang at gmail.com Thu Feb 26 09:28:13 2009 From: drdrang at gmail.com (Dr. Drang) Date: Thu, 26 Feb 2009 08:28:13 -0600 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> <9A508A69-F0D3-4845-B1E5-E8431C9E36B5@gmail.com> Message-ID: <11A83672-C6D8-422F-B69C-C22D215DFAAD@gmail.com> On Feb 26, 2009, at 4:01 AM, Michel Fortin wrote: > > Well, if you want list items spanning on multiple lines to align > properly, it's pretty hard to do with spaces using a proportional > font. > > 1. List item > spanning on more > than one line. It's easy enough to get all but the first line to align perfectly. That the first line is a bit off can be thought of as an eccentric (but perfectly readable) stylistic choice. > You can sometime use tabs in proportional fonts in some situations. > It helps aligning things correctly, and not only for tables, but > also with the list item example above. > > Although if you later view it with a different font it'll probably > look like crap too. In my experience, tabs with proportional fonts really only work in word processors, where the placement of the tabs can be saved with the document. No such luck with plain text documents. I know that vi and Emacs can use header lines that describe the tab spacing, but they assume the use of a monospace font. > That said, it's pretty easy to write a properly-aligned table > without a script too. I've been doing that for some time. I used to do it by hand, too. It's easy, but tedious, and especially annoying when I found myself doing it again and again as I realized that the table I thought was in final form needed yet another round of editing. -- Dr. Drang drdrang at gmail.com From lists at mostrom.pp.se Thu Feb 26 09:35:34 2009 From: lists at mostrom.pp.se (=?ISO-8859-1?Q?Jan_Erik_Mostr=F6m?=) Date: Thu, 26 Feb 2009 15:35:34 +0100 Subject: Desktop app for viewing Markdown files Message-ID: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> Is there a file/document browser that render and display Markdown files? (for the Mac) jem From sgbotsford at gmail.com Thu Feb 26 10:03:24 2009 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Thu, 26 Feb 2009 08:03:24 -0700 Subject: Desktop app for viewing Markdown files In-Reply-To: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> Message-ID: <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> Most of the point of Markdown is that it can be viewed/edited in any simple text editor. Try TextEdit, SimpleText, or from the command-line (terminal window) vi. Lots of Mac geeks use an editor that starts with BB (BBedit?) In my usage markdown text is only viewed by me. I use it in combination with template toolkit. Others use it with various content management systems. The idea is that the writer is separated from worrying about a raft of html tags, and uses visual hints in his text to tell the html generator what to do. Many of these traditions come from text only communication such as email before HTML email came along, and usenet. E.g. using asterisks to indicate *emphasis*. In a more general sense, most of us can't worry about content and format at the same time and do a good job of both. You can sort of do it in a good word processor if you take the time when you start a project to define a good set of styles. I have yet to find such an editor that writes HTML code that isn't grossly bloated. On Thu, Feb 26, 2009 at 7:35 AM, Jan Erik Mostr?m wrote: > Is there a file/document browser that render and display Markdown files? > (for the Mac) > > ? ? ? ? ? ? ? ? ? ? ? ?jem > > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > -- Sherwood Botsford Sherwood's Forests Warburg, Alberta T0C 2T0 http://www.sherwoods-forests.com 780-848-2548 From lists at mostrom.pp.se Thu Feb 26 10:19:05 2009 From: lists at mostrom.pp.se (=?ISO-8859-1?Q?Jan_Erik_Mostr=F6m?=) Date: Thu, 26 Feb 2009 16:19:05 +0100 Subject: Desktop app for viewing Markdown files In-Reply-To: <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> Message-ID: On 26 feb 2009, at 16:03, Sherwood Botsford wrote: > Most of the point of Markdown is that it can be viewed/edited in any > simple text editor. > Try TextEdit, SimpleText, or from the command-line (terminal window) > vi. Lots of Mac geeks use an editor that starts with BB (BBedit?) Personally I use BBEdit. The thing isn't that I want to edit these files, rather browse them and see them rendered jem PS Ideally I would like to see of "view markdown files" in Path Finder DS From jason at jclark.org Thu Feb 26 10:26:40 2009 From: jason at jclark.org (Jason Clark) Date: Thu, 26 Feb 2009 10:26:40 -0500 Subject: Desktop app for viewing Markdown files In-Reply-To: References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> Message-ID: On Thu, Feb 26, 2009 at 10:19 AM, Jan Erik Mostr?m wrote: > Personally I use BBEdit. The thing isn't that I want to edit these files, > rather browse them and see them rendered > > Gruber recently linked to [Quicklook for Markdown][1], a plugin that adds QuickLook previews (and Spotlight indexing) for Markdown-formatted documents. I have not yet tried it myself, but it looks like it may do what you want. [1]: http://mdk.org.pl/2009/2/10/quicklook-for-markdown Jason Clark http://jclark.org/weblog/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From soypunk at gmail.com Thu Feb 26 10:32:42 2009 From: soypunk at gmail.com (Shawn Medero) Date: Thu, 26 Feb 2009 07:32:42 -0800 Subject: Desktop app for viewing Markdown files In-Reply-To: References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> Message-ID: <994fc8d00902260732md62d125o70f8883b3e4636d9@mail.gmail.com> On Thu, Feb 26, 2009 at 7:19 AM, Jan Erik Mostr?m wrote: > Personally I use BBEdit. The thing isn't that I want to edit these files, > rather browse them and see them rendered I'll assume you know BBEdit (8+ ?) renders Markdown files. There's also a Markdown QuickLook plugin. http://github.com/toland/qlmarkdown/tree/master Is that what you had in mind? (If PathFinder uses QuickLook...?) -s From minhee at dahlia.kr Thu Feb 26 10:52:41 2009 From: minhee at dahlia.kr (Hong MinHee) Date: Fri, 27 Feb 2009 00:52:41 +0900 Subject: Desktop app for viewing Markdown files In-Reply-To: <994fc8d00902260732md62d125o70f8883b3e4636d9@mail.gmail.com> References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> <994fc8d00902260732md62d125o70f8883b3e4636d9@mail.gmail.com> Message-ID: How about this? http://readown.googlecode.com/ 2009/2/27 Shawn Medero : > On Thu, Feb 26, 2009 at 7:19 AM, Jan Erik Mostr?m wrote: > >> Personally I use BBEdit. The thing isn't that I want to edit these files, >> rather browse them and see them rendered > > I'll assume you know BBEdit (8+ ?) renders Markdown files. > > There's also a Markdown QuickLook plugin. > > http://github.com/toland/qlmarkdown/tree/master > > Is that what you had in mind? (If PathFinder uses QuickLook...?) > > -s > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > From lists at mostrom.pp.se Thu Feb 26 11:18:40 2009 From: lists at mostrom.pp.se (=?ISO-8859-1?Q?Jan_Erik_Mostr=F6m?=) Date: Thu, 26 Feb 2009 17:18:40 +0100 Subject: Desktop app for viewing Markdown files In-Reply-To: <994fc8d00902260732md62d125o70f8883b3e4636d9@mail.gmail.com> References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> <534004cc0902260703x62c61a1dxb8eff2c025c40af0@mail.gmail.com> <994fc8d00902260732md62d125o70f8883b3e4636d9@mail.gmail.com> Message-ID: <456EFF90-F787-4131-A6F1-8F06F8725C2B@mostrom.pp.se> On 26 feb 2009, at 16:32, Shawn Medero wrote: > I'll assume you know BBEdit (8+ ?) renders Markdown files. Ohh, yes ... I actually made my own markdown preview in BBEdit before it was built-in ;-) > http://github.com/toland/qlmarkdown/tree/master > http://readown.googlecode.com/ Thanks! For those who try these two, note the Markdown files need to be in UTF-8 format otherwise nothing is displayed. jem -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at jumpingrock.net Thu Feb 26 12:07:33 2009 From: tom at jumpingrock.net (Tom Humiston) Date: Thu, 26 Feb 2009 12:07:33 -0500 Subject: Desktop app for viewing Markdown files In-Reply-To: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> Message-ID: MarsEdit. It's for writing blog posts. One can enter text in Markdown format and see a live preview in another panel, showing how it will look in a browser. Even if you don't actually publish to a blog. From the [vendor's website][1]: Perfect Previews Build a template to match your blog, then let MarsEdit's live preview show you how your posts will look before you publish them. Use Your Favorite Editor Combine the power of MarsEdit with your favorite editor. Integrates cleanly with BBEdit, SubEthaEdit, TextMate, or TextWrangler. "Nearly every word I write for Daring Fireball is published through MarsEdit." -- John Gruber, Daring Fireball Tom Humiston Website Designer & Psychic Healer Kalamazoo, Michigan, USA [1]: http://www.red-sweater.com/marsedit/ On 26 Feb 2009, at 9:35 AM, Jan Erik Mostr?m wrote: > Is there a file/document browser that render and display Markdown > files? (for the Mac) > > jem From david at kineticode.com Thu Feb 26 12:40:36 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 09:40:36 -0800 Subject: monospaced fonts In-Reply-To: References: Message-ID: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> On Feb 26, 2009, at 5:00 AM, Bowerbird at aol.com wrote: > i hope you will agree with _my_ obvious counter: > monospaced fonts aren't the only way to do that. > indeed, they aren't even the most _common_ way. > (that distinction still goes to the old-fashioned tab, > by which i mean computation of the point to write.) No, but it's the expectation with Markdown that you'll use a monospaced font. > in reference to the actual topic of the actual thread, > if anyone were to write a markdown authoring-tool > -- my favorite is still "showdown", it's very cool -- > you'll discover that it's fairly easy to support tables. > (even ones that are relatively complex, layout-wise; > for instance, determining defaults for alignment is > very simple, and they almost always work correctly.) > you just discern the columns, size them appropriately, > determine cell alignment, and write text at proper spot. > so the regular emergence of this thread, reminiscent of > punxsatawney phil the groundhog, is really unnecessary. I agree that the formatting of a table should be implicit as much as possible. > but i don't care. use monospace all day. just don't tell steve, > ok? > might interfere with his recovery, and we all need him back soon. If Steve wrote markdown, or wrote code, he's use a monospaced font, because it's the right tool for the job. Best, David From david at kineticode.com Thu Feb 26 12:42:30 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 09:42:30 -0800 Subject: wrapped cell contents in tables In-Reply-To: <49A69B16.8080501@transmekong.com> References: <49A69B16.8080501@transmekong.com> Message-ID: <72377CD1-327F-45F3-9BB8-A4D6BF33754C@kineticode.com> 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 From david at kineticode.com Thu Feb 26 12:42:37 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 09:42:37 -0800 Subject: wrapped contents in table cells In-Reply-To: <49A696E9.2020106@transmekong.com> References: <49A696E9.2020106@transmekong.com> Message-ID: On Feb 26, 2009, at 5:19 AM, Benoit Perdu - TransM?kong wrote: > Yes, I meant that implementing such a syntax as this would go a long > way towards perfection in my eyes. Thanks. David From david at kineticode.com Thu Feb 26 12:44:48 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 09:44:48 -0800 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <49A5F1B7.3010001@idirect.ca> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> <49A5F1B7.3010001@idirect.ca> Message-ID: <6ABD8B11-047D-4534-8C37-71F0116526F8@kineticode.com> On Feb 25, 2009, at 5:34 PM, Seumas Mac Uilleachan wrote: > Admittedly it is easier to create legible text documents with lots > of bullets and tables and definition lists if you are using a > monospace font but in my experience monospace fonts are generally > just harder to read. The beauty of markdown is that you can > approximate the spacing of monospace by varying the whitespace. Or > just let it be "wonky". (Of course what looks beautiful in one > proportional font will be wonky in another anyway) Yes, but it will look different in every proportional font. Even if you use tabs, some folks will have four-space tabs and others will have eight-space tabs, so you can't expect it to look the same. The only way to guarantee consistency is to use a monospaced font. It doesn't matter so much for things like paragraphs, of course, but once you get into some other things like nested lists, it can make all the difference. Best, David From david at kineticode.com Thu Feb 26 12:51:23 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 09:51:23 -0800 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> Message-ID: On Feb 26, 2009, at 3:57 AM, Fletcher T. Penney wrote: > My thoughts: > > + I am perfectly willing to change the MMD table syntax if a better > alternative (particularly a standard one) comes along > > + Not everyone uses monospace fonts - as nice as that would be for > tables, I think it's not reasonable to expect that to be a > requirement for viewing tables > > + I hope someone out there smarter than me creates a better table > syntax I can see that really opened a can of worms here. Sorry about that. I'll have to move up my plan to formally propose a table syntax. The comment that started this sub-thread was a throwaway line, really. I probably should have omitted it. Best, David From mistlail at yahoo.co.uk Thu Feb 26 14:04:08 2009 From: mistlail at yahoo.co.uk (Albert Skye) Date: Thu, 26 Feb 2009 11:04:08 -0800 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <11A83672-C6D8-422F-B69C-C22D215DFAAD@gmail.com> References: <49A4DF89.9060008@transmekong.com> <534004cc0902250657ted79f07kb41cdcea0d2de8b@mail.gmail.com> <9A508A69-F0D3-4845-B1E5-E8431C9E36B5@gmail.com> <11A83672-C6D8-422F-B69C-C22D215DFAAD@gmail.com> Message-ID: <20090226110408017839.130a4970@yahoo.co.uk> > In my experience, tabs with proportional fonts really only work in ... Elastic tabstops[1]. If your favourite editor does not already support this, please request/implement it. [1]: http://nickgravgaard.com/elastictabstops/ From mistlail at yahoo.co.uk Thu Feb 26 14:16:05 2009 From: mistlail at yahoo.co.uk (Albert Skye) Date: Thu, 26 Feb 2009 11:16:05 -0800 Subject: monospaced fonts In-Reply-To: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> References: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> Message-ID: <20090226111605544770.ec271b34@yahoo.co.uk> > ... use a monospaced font, because it's the right tool for the job. An examination of the threads in these[1] articles will quickly reveal that many are quite happily (and preferably) using variable-width fonts for programming. I, for one, have found Verdana to be an excellent choice; it has lots of space around the characters that need it, and similar characters which are easily confused in many fonts are clearly distinguished. Of course, much depends upon the quality of rendering. [1]: http://www.google.com/search?q=programming+%22proportional+font%22 From orc at pell.portland.or.us Thu Feb 26 16:37:06 2009 From: orc at pell.portland.or.us (orc at pell.portland.or.us) Date: 26 Feb 2009 21:37:06 GMT Subject: monospaced fonts References: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> Message-ID: In article <712EE2F9-AA00-46EC-B4E2-EA5924AE1069 at kineticode.com>, David E. Wheeler wrote: >On Feb 26, 2009, at 5:00 AM, Bowerbird at aol.com wrote: > >> i hope you will agree with _my_ obvious counter: >> monospaced fonts aren't the only way to do that. >> indeed, they aren't even the most _common_ way. >> (that distinction still goes to the old-fashioned tab, >> by which i mean computation of the point to write.) > >No, but it's the expectation with Markdown that you'll use a >monospaced font. You know, I've never even considered this; I can certainly see that it might be useful to use a monospaced font if you're working with an editor that bobbles leading indentation, but other than that there's nothing that cosmetically cares about what type of font is being used. Where is whitespace alignment important except at the start of a line? (And just what font would have sizeof(N.) be large enough so that you'd need to indent more than 7 leading spaces to line up with the text items? Wouldn't that count as a pathological case ("If you use the super-wide-periods font, your list items will look raggedy. Sorry.") and be ignored?) -david "tables? yuk!" parsons From orc at pell.chi.il.us Thu Feb 26 16:47:59 2009 From: orc at pell.chi.il.us (david parsons) Date: 26 Feb 2009 21:47:59 GMT Subject: monospaced fonts References: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> Message-ID: In article <712EE2F9-AA00-46EC-B4E2-EA5924AE1069 at kineticode.com>, David E. Wheeler wrote: >On Feb 26, 2009, at 5:00 AM, Bowerbird at aol.com wrote: > >> i hope you will agree with _my_ obvious counter: >> monospaced fonts aren't the only way to do that. >> indeed, they aren't even the most _common_ way. >> (that distinction still goes to the old-fashioned tab, >> by which i mean computation of the point to write.) > >No, but it's the expectation with Markdown that you'll use a >monospaced font. You know, I've never even considered this; I can certainly see that it might be useful to use a monospaced font if you're working with an editor that bobbles leading indentation, but other than that there's nothing that cosmetically cares about what type of font is being used. Where is whitespace alignment important except at the start of a line? (And just what font would have sizeof(N.) be large enough so that you'd need to indent more than 7 leading spaces to line up with the text items? Wouldn't that count as a pathological case ("If you use the super-wide-periods font, your list items will look raggedy. Sorry.") and be ignored?) -david "tables? yuk!" parsons From thantos at gmail.com Thu Feb 26 16:56:42 2009 From: thantos at gmail.com (Alexander Williams) Date: Thu, 26 Feb 2009 16:56:42 -0500 Subject: monospaced fonts In-Reply-To: References: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> Message-ID: <4f0341480902261356n4b53db9ak9df694f0216cf7e8@mail.gmail.com> On Thu, Feb 26, 2009 at 4:37 PM, wrote: > Where is whitespace alignment important except at the start of > a line? (And just what font would have sizeof(N.) be large > enough so that you'd need to indent more than 7 leading spaces > to line up with the text items? Wouldn't that count as a > pathological case ("If you use the super-wide-periods font, > your list items will look raggedy. Sorry.") and be ignored?) > The scary truth is that aside from the start of a line, "basic Markdown" doesn't give two burps in a whirlwind about monospace versus proportional. Secretly, *I* usually use Verdana as my typical editing font. It's *only* when having characters line up vertically becomes an issue that I use a mono font, and that's relatively rare. Primarily it really hits the fan whenever anyone starts talking table formats because then communicating vertical alignment becomes *meaningful*. Until then, it largely doesn't matter. If I had my druthers, Markdown would be more like some other "indentation aware" systems I use in which the actual amount / number of indentational whitespace characters at the beginning of a line don't matter, just the relative indentation to other text. That'd make it hard to do more than one level of indentation stepping at a time, but how often does that come up in actual practice? But, sadly, that's not how it's defined. And we get on. *(My personal theory is that the holy wars re monospaced vs proportional may be part of why there's no native table design in Markdown ...)* -- Alexander Williams (thantos at gmail.com) Operation BSU (http://operationbsu.livejournal.com) "Like a morning show. Only interesting. And at night." -------------- next part -------------- An HTML attachment was scrubbed... URL: From gruber at fedora.net Thu Feb 26 18:28:36 2009 From: gruber at fedora.net (John Gruber) Date: Thu, 26 Feb 2009 18:28:36 -0500 Subject: monospaced fonts In-Reply-To: <4f0341480902261356n4b53db9ak9df694f0216cf7e8@mail.gmail.com> References: <712EE2F9-AA00-46EC-B4E2-EA5924AE1069@kineticode.com> <4f0341480902261356n4b53db9ak9df694f0216cf7e8@mail.gmail.com> Message-ID: 1. Please consider this thread closed. 2. Use whatever font you want in your editor. 3. A hypothetical official table syntax for Markdown will almost certainly look very much, if not exactly, like Michel's table syntax in PHP Markdown Extra. -J.G. From Bowerbird at aol.com Thu Feb 26 18:43:13 2009 From: Bowerbird at aol.com (Bowerbird at aol.com) Date: Thu, 26 Feb 2009 18:43:13 EST Subject: elastic tabstops, proportional fonts, and more Message-ID: nick said: > http://nickgravgaard.com/elastictabstops/ exactly. thanks for writing it up, nick. the only thing i'd add is the notion that tables should be copyfit to the viewport. if the viewport gives you plenty of room, give the columns some breathing space. if not, tighten them as much as needed. *** > http://readown.googlecode.com/ cool. now how about an authoring-tool? bbedit? um, no thanks. i never understood the appeal of a text-editor with no support for styled text. _simpletext_ had styled text! sorry, if you don't do styled text, you do suck. i use tex-edit, from tom bender. fantastic. doesn't just _support_ styled text, but also lets you _do_searches_ with specific styles. and it costs $15, with free updates for life. that even gets you the fucking source code. heck, i'm gonna send tom $15 more today, because that guy is an asset to the world... i'll take another look at mars-edit as well... *** and while i'm here causing a fuss again, let me ask the big questions once again: who's gonna write the browser plug-in? and who's gonna get markdown bundled right into the very _guts_ of the browser? i want to _serve_ markdown files per se, and avoid the stupid .html middleman... the world is full of technical dummies who will kiss the feet of the person who gives them the means to return to "the old days" when .html was a simple thing to create... today's xhtml/css mess is one sick joke that the technoids pulled on the public to reassert the role of "required experts". it's time to disintermediate them again... that's my opinion, and i'm stickin' to it... *** david said: > The? comment that started this sub-thread > was a throwaway line, really ok, sorry i made even a small deal about it. but still, now you've got my curiosity going... while granting anyone and everyone my _full_ permission to use _whatever_ font they prefer, even if someone else thinks that it might not be the best tool for the job, i am wondering about the "expectation" markdown brings to the table. (ha, look, i made a little pun, to be lighthearted.) gruber, if you're reading, would you answer this: do you use a monospaced font to write your blog? or to write _anything_ that you do with markdown? -bowerbird ************** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at kineticode.com Thu Feb 26 19:54:40 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 16:54:40 -0800 Subject: RFC: Markdown Table Syntax Message-ID: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> On Feb 26, 2009, at 9:51 AM, I wrote: > I can see that really opened a can of worms here. Sorry about that. > I'll have to move up my plan to formally propose a table syntax. The > comment that started this sub-thread was a throwaway line, really. I > probably should have omitted it. And then, on Feb 26, 2009, at 3:28 PM, John Gruber wrote: > 3. A hypothetical official table syntax for Markdown will almost > certainly look very much, if not exactly, like Michel's table syntax > in PHP Markdown Extra. Well, perhaps it's foolish of me, but since I'd already spent several hours writing it up before I saw that post, I went ahead and finished my proposal as an informal request for comments, which I've [blogged here][]: [blogged here] http://www.justatheory.com/computers/markup/markdown-table-rfc.html The high-level overview is this: * I looked at prior art from database clients and MultiMarkdown * I identified a few things I liked in the DB clients that aren't in MultiMarkdown (continuing lines, implicit cell alignment) * I offered some refinements of the MultiMarkdown syntax Those refinements, in a nutshell, are, simply: * Implicit cell alignment using space characters, rather than the explicit formatting hints in the header lines * Cell content continuation using : for succeeding lines * Stricter use of space, for proper alignment in plain text (which all of the MultiMarkdown examples I?ve seen tend to do anyway) * Allow + to separate columns in the header-demarking lines * A table does not have to start right at the beginning of a line Many if not all of these refinements can preserve compatibility with what's already there, although such was not my goal. Overall, what I was concentrating on was how I'd like tables to look in plain text, given how often I've created them in code documentation, and how often I look at them in terminal-based database clients. I like what I've come up with, drawing as it does on solid prior art, and would appreciate those who take an interest in such arcana taking a look. Again, I appreciate how friendly and willing the folks have been on this list, especially to a presumptuous n00b like myself, and hope to continue to contribute to that for a long time. Best, David From michel.fortin at michelf.com Thu Feb 26 21:47:56 2009 From: michel.fortin at michelf.com (Michel Fortin) Date: Thu, 26 Feb 2009 21:47:56 -0500 Subject: RFC: Markdown Table Syntax In-Reply-To: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> Message-ID: <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> Le 2009-02-26 ? 19:54, David E. Wheeler a ?crit : > > > [...] > > Those refinements, in a nutshell, are, simply: > > * Implicit cell alignment using space characters, rather than > the explicit formatting hints in the header lines > * Cell content continuation using : for succeeding lines > * Stricter use of space, for proper alignment in plain text (which > all of the MultiMarkdown examples I?ve seen tend to do anyway) > * Allow + to separate columns in the header-demarking lines > * A table does not have to start right at the beginning of a line Perhaps you should mention that you're now forcing a table cells to be properly aligned using a monospace font. This in fact makes the syntax impossible to use in a proportional font context. While it's true that many people use a monospace font and that in a text editor you can change the font, I'd like to mention that Markdown is also used for writing comments and blog posts in textareas not formatted with a monospace font, and for which it may not be easy to change the font. Forcing proper alignment makes the table syntax unusable in these situations. Now, given that cell continuation using colons relies on that proper alignment with a monospace font feature (or else you risk mistaking colons in the text for column separators), I don't find that syntax very satisfying. Allowing `+` as column separator in the header underline looks like a good idea though. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From gruber at fedora.net Fri Feb 27 00:30:37 2009 From: gruber at fedora.net (John Gruber) Date: Fri, 27 Feb 2009 00:30:37 -0500 Subject: RFC: Markdown Table Syntax In-Reply-To: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> Message-ID: <5874E576-5D6A-4D59-A790-98406543277D@fedora.net> On 26 Feb 2009, at 7:54 PM, David E. Wheeler wrote: >> 3. A hypothetical official table syntax for Markdown will almost >> certainly look very much, if not exactly, like Michel's table >> syntax in PHP Markdown Extra. > > Well, perhaps it's foolish of me, but since I'd already spent > several hours writing it up before I saw that post, I went ahead and > finished my proposal as an informal request for comments, which I've > [blogged here][]: I never say never. Well, usually. -J.G. From david at kineticode.com Fri Feb 27 01:44:10 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 22:44:10 -0800 Subject: RFC: Markdown Table Syntax In-Reply-To: <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> Message-ID: On Feb 26, 2009, at 6:47 PM, Michel Fortin wrote: > Perhaps you should mention that you're now forcing a table cells to > be properly aligned using a monospace font. This in fact makes the > syntax impossible to use in a proportional font context. > > While it's true that many people use a monospace font and that in a > text editor you can change the font, I'd like to mention that > Markdown is also used for writing comments and blog posts in > textareas not formatted with a monospace font, and for which it may > not be easy to change the font. Forcing proper alignment makes the > table syntax unusable in these situations. > > Now, given that cell continuation using colons relies on that proper > alignment with a monospace font feature (or else you risk mistaking > colons in the text for column separators), I don't find that syntax > very satisfying. Well, they're not mutually exclusive. If we continue to allow the use of the colon to suggest alignment, and if a user doesn't need to continue a line, then the existing MultiMarkdown syntax should continue to work, even with a proportional font. But to get the line continuation feature, I don't see any way to do it other than requiring proper spacing. Of course, I'm so used to looking at database output in a terminal session using [Consolas][] that I'm sure I'm quite biased when it comes to spacing tables with a monospaced font. [Consolas] http://en.wikipedia.org/wiki/Consolas > Allowing `+` as column separator in the header underline looks like > a good idea though. Yeah, that alone allows one to simply paste most any output from psql or mysql and have it just work. Best, David From david at kineticode.com Fri Feb 27 01:44:47 2009 From: david at kineticode.com (David E. Wheeler) Date: Thu, 26 Feb 2009 22:44:47 -0800 Subject: RFC: Markdown Table Syntax In-Reply-To: <5874E576-5D6A-4D59-A790-98406543277D@fedora.net> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> <5874E576-5D6A-4D59-A790-98406543277D@fedora.net> Message-ID: On Feb 26, 2009, at 9:30 PM, John Gruber wrote: >>> 3. A hypothetical official table syntax for Markdown will almost >>> certainly look very much, if not exactly, like Michel's table >>> syntax in PHP Markdown Extra. >> >> Well, perhaps it's foolish of me, but since I'd already spent >> several hours writing it up before I saw that post, I went ahead >> and finished my proposal as an informal request for comments, which >> I've [blogged here][]: > > I never say never. Well, usually. /me chuckles :-) Best, David From Bowerbird at aol.com Fri Feb 27 02:01:07 2009 From: Bowerbird at aol.com (Bowerbird at aol.com) Date: Fri, 27 Feb 2009 02:01:07 EST Subject: elastic tabstops, proportional fonts, and more Message-ID: i said: > gruber, if you're reading, would you answer this: > do you use a monospaced font to write your blog? > or to write _anything_ that you do with markdown ends up gruber mentioned this just recently on his blog: > (Preemptively answering the inevitable question: > I use Monaco 10 for text documents, > but Consolas 12 for shell worksheets.) > http://daringfireball.net/linked/2008/12/15/bbedit-91 so david, your supposition on the "expectation" of markdown -- at least as conceived by gruber -- was entirely correct, and i have to admit that i was wrong. not the first time, not the last. :+) -bowerbird ************** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) -------------- next part -------------- An HTML attachment was scrubbed... URL: From qaramazov at gmail.com Fri Feb 27 02:22:29 2009 From: qaramazov at gmail.com (Yuri Takhteyev) Date: Thu, 26 Feb 2009 23:22:29 -0800 Subject: RFC: Markdown Table Syntax In-Reply-To: <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> Message-ID: > Now, given that cell continuation using colons relies on that proper > alignment with a monospace font feature (or else you risk mistaking colons > in the text for column separators), I don't find that syntax very > satisfying. Why not have two different kinds of table: one where each line is a row, and one where rows are show explicitly with dashes. The second type could use ===== or something else after the header: id | name | description | price ======|=============|==============================|======= 1 | gizmo | Takes care of the doohickies | 1.99 ??????+?????????????+??????????????????????????????+???????? 10 | dojigger | Handles: | 102.98 | | * gizmos | | | * doodads | | | * thingamobobs | Would mean: a header and two rows. - yuri -- http://spu.tnik.org/ From sgbotsford at gmail.com Fri Feb 27 10:26:18 2009 From: sgbotsford at gmail.com (Sherwood Botsford) Date: Fri, 27 Feb 2009 08:26:18 -0700 Subject: elastic tabstops, proportional fonts, and more In-Reply-To: References: Message-ID: <534004cc0902270726p4d9bf589p34360b966780624e@mail.gmail.com> G'day Nice rant. I sympathize. Ain't going to happen. In a nut shell, you're proposing that browsers interpret a whole new language. A simpler one than html, but non-the-less a new language. That new language is weak compared to html, in the sense that by itself it can't say, "Float this picture on the right side, resize it to 40% of the column width, put this line on top as the title, put these two paragraphs underneath it as the caption, and put a hairline border around the entire thing." I'll point out that RTF is far richer than markdown, RTF editors are simple for the masses to use, but RTF has not caught on as a browser presentation format. Nor has SVG for graphics, although it would allow you to do things that html can't. Nor has Math ML despite there being no good way to present mathematics in a browser. Markdown allows people to write without worrying about layout. Even this table stuff is a bit over the top, but tables in the day of typewriters were always a pain. (I'm dating myself...) I suspect that the Babylonian scribes cursed tables in their time. I agree that there is a lack of good simple easy ways to make content for an entire site that doesn't get you wrapped up in endless fiddling with the navigation links, and the presentation, AND is easy for a non-tech to use. There are a raft of CMS systems out there. None are trivial to set up for a non-technical person. And for that non-tech to *change* the site style is a very metal container of bass bait. At present Markdown fills a gap, and gives us a middle ground between working with straight html with paired tags for every sneeze, and products like dreamweaver with their wysiwyg view, but producing bloated non-standard html that is hard to integrate into any but a static site. By the way: If you succeed in your project how would like to take on the next biggie: Regularize English spelling? -- Sherwood Botsford Sherwood's Forests Warburg, Alberta T0C 2T0 http://www.sherwoods-forests.com 780-848-2548 From david at kineticode.com Fri Feb 27 11:55:56 2009 From: david at kineticode.com (David E. Wheeler) Date: Fri, 27 Feb 2009 08:55:56 -0800 Subject: RFC: Markdown Table Syntax In-Reply-To: References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> Message-ID: <7E03987F-74C7-4C26-A34D-E560C5D0C15E@kineticode.com> On Feb 26, 2009, at 11:22 PM, Yuri Takhteyev wrote: > Why not have two different kinds of table: one where each line is a > row, and one where rows are show explicitly with dashes. The second > type could use ===== or something else after the header: > > id | name | description | price > =====|=============|==============================|======= > 1 | gizmo | Takes care of the doohickies | 1.99 > ?????+????????????? > +?????????????????????????????? > +???????? > 10 | dojigger | Handles: | 102.98 > | | * gizmos | > | | * doodads | > | | * thingamobobs | > > Would mean: a header and two rows. I had to think about this for a few minutes, because the programmer side of me is rather attracted to the idea. It reduces ambiguity, and in this example gets out of the way. At also reduces the issue with white space. The problem I can see, however, is that it forces the common cases to adopt the syntax required by the edge cases. In general, I think that tables will often *not* have multiline cells. With my proposed syntax that would be: id | name | description | price ??????+????????????? +?????????????????????????????? +???????? 1 | gizmo | Takes care of the doohickies | 1.99 2 | doodad | Collects *gizmos* | 23.80 10 | dojigger | Handles stuff | 102.98 1024 | thingamabob | Self?explanatory, no? | 0.99 But if we require a separate between every row, it suddenly becomes much more verbose: id | name | description | price ======|=============|==============================|======== 1 | gizmo | Takes care of the doohickies | 1.99 ??????+????????????? +?????????????????????????????? +???????? 2 | doodad | Collects *gizmos* | 23.80 ??????+????????????? +?????????????????????????????? +???????? 10 | dojigger | Handles stuff | 102.98 ??????+????????????? +?????????????????????????????? +???????? 1024 | thingamabob | Self?explanatory, no? | 0.99 Which one would you rather read? It's harder for me to scan the table, as all those lines start to get in the way. And it takes up nearly twice as much screen real estate. I really am inspired by the example set by database client output, where there's just enough table layout to make it clear you're looking at a table, but not so much that it starts to get in the way of legibility. The important thing about a data is the content of the table, not the table itself. I should know I'm looking at a table, but beyond that, it should stay out of my way. Best, David From david at kineticode.com Fri Feb 27 12:00:27 2009 From: david at kineticode.com (David E. Wheeler) Date: Fri, 27 Feb 2009 09:00:27 -0800 Subject: RFC: Markdown Table Syntax In-Reply-To: <7E03987F-74C7-4C26-A34D-E560C5D0C15E@kineticode.com> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> <7E03987F-74C7-4C26-A34D-E560C5D0C15E@kineticode.com> Message-ID: <6D40927E-4997-46BC-848D-FB1A7FD49D21@kineticode.com> On Feb 27, 2009, at 8:55 AM, David E. Wheeler wrote: > id | name | description | price > ======|=============|==============================|======== > 1 | gizmo | Takes care of the doohickies | 1.99 > ??????+????????????? > +?????????????????????????????? > +???????? > 2 | doodad | Collects *gizmos* | 23.80 > ??????+????????????? > +?????????????????????????????? > +???????? > 10 | dojigger | Handles stuff | 102.98 > ??????+????????????? > +?????????????????????????????? > +???????? > 1024 | thingamabob | Self?explanatory, no? | 0.99 *SIGH*. Have I mentioned that I hate Mail.app? Please pretend that those separator lines aren't off by a character. Thanks, David From qaramazov at gmail.com Fri Feb 27 13:31:16 2009 From: qaramazov at gmail.com (Yuri Takhteyev) Date: Fri, 27 Feb 2009 10:31:16 -0800 Subject: RFC: Markdown Table Syntax In-Reply-To: <7E03987F-74C7-4C26-A34D-E560C5D0C15E@kineticode.com> References: <632890C2-6C4C-46EB-8719-B13390B4DEB4@kineticode.com> <4462BD1A-4070-4215-BE78-38754D68CBD9@michelf.com> <7E03987F-74C7-4C26-A34D-E560C5D0C15E@kineticode.com> Message-ID: > The problem I can see, however, is that it forces the common cases to adopt > the syntax required by the edge cases. In general, I think that tables will > often *not* have multiline cells. My proposal is for supporting _two_ table syntaxes. One simple that would work just like the current MD-Extra tables, and another one that would require rows to be separated manually. So, the the common case wouldn't change at all. > The > important thing about a data is the content of the table, not the table > itself. I should know I'm looking at a table, but beyond that, it should > stay out of my way. This is all good, until the HTML for your table gets totally off because you used one space too many or inadvertently triggered a row continuation by using a colon inside a table cell. Legibility cannot be the only criterion. It also need to make sure that the markup could be translated to HTML in a predictable manner. - yuri -- http://spu.tnik.org/ From Bowerbird at aol.com Fri Feb 27 16:42:14 2009 From: Bowerbird at aol.com (Bowerbird at aol.com) Date: Fri, 27 Feb 2009 16:42:14 EST Subject: elastic tabstops, proportional fonts, and more Message-ID: sherwood said: > Nice rant. um... thanks... i guess... although i consider a "rant" to be an emotional outburst, and i save my emotions for my poetry, and try to be _rational_ on listserves... > I sympathize.? Ain't going to happen. why not? > you're proposing that browsers > interpret a whole new language.? not really. not at all. they receive the .markdown that's served, convert it to the .html they expect, and then process that .html normally and display it... thus, the only added step is the _conversion_, and we know that that involves <100k of code, and can be accomplished in mere milliseconds. 100k of code in the bloatware that is a modern browser is next to nothing. and the milliseconds are a tremendous bargain offset by all the human _hours_ that'll be saved. the _bureaucracy_ of browser buy-in might be difficult to negotiate -- which is why i advocate making a plug-in -- but the tech part isn't hard. a plug-in would be enough to get a ball rolling... i'm convinced that millions of regular users would rather serve markdown (or another light markup) instead of .html, if they actually had the _choice_... and if millions of people started serving markdown, the browser-makers would eventually pay attention. -bowerbird p.s. the blogging programs might be a good place to get a ball rolling as well. if they gave notice that they wanna serve markdown, it might get attention. ************** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) -------------- next part -------------- An HTML attachment was scrubbed... URL: From chad.thecomfychair at gmail.com Fri Feb 27 17:03:15 2009 From: chad.thecomfychair at gmail.com (Chad Nelson) Date: Fri, 27 Feb 2009 17:03:15 -0500 Subject: Cpp-Markdown 1.00 In-Reply-To: <49A5BF53.30106@gmail.com> References: <49A5BF53.30106@gmail.com> Message-ID: <49A86323.7060603@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Since no one seemed to notice the question in my announcement message a couple days ago, I'm asking again: I've been trying to add Cpp-Markdown to the markdown wiki page at , but I can't seem to log in there with my reddit.com account information as the login page states (I'm told "that username doesn't exist"), and there's no visible way to apply for an account on that wiki itself. Is there some special trick to it? If new contributors aren't allowed, could someone who has write access already add it? All the information is in the below-quoted announcement message. I was planning to add MDTest to the testing packages too, since it isn't mentioned there and has been very useful in developing Cpp-Markdown. - -- Chad Nelson Oak Circle Software, Inc. * * * Chad Nelson wrote: > I'm happy to announce that the Cpp-Markdown project is now available. > > Cpp-Markdown is a Markdown-to-HTML translator written in C++, and meant > for use within C++ programs (rather than web applications). The code is > still a little rough around the edges, but the results are pretty good: > it passes all 23 tests in the Markdown test suite, and 12 of the 17 > tests in the PHP Markdown test suite, of MDTest 1.1. > > It is released under the MIT license, so it can be used in other > programs (including commercial ones) with almost no limitations. > > Its official site is here: > > (I've been trying to add it to the markdown wiki page at > as well, but I can't seem to log in > there with my reddit.com account information, and there's no visible way > to apply for an account on that wiki itself. Could someone with > write-access there add it, please? Thanks.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmoYyMACgkQp9x9jeZ9/wS54QCgxw4L6wT1UfYO0fH+egtnmHC7 UYcAoLpJZNW0HDpMwEcfO/88KH2NZN8V =NErI -----END PGP SIGNATURE----- From orc at pell.chi.il.us Fri Feb 27 19:58:24 2009 From: orc at pell.chi.il.us (david parsons) Date: 28 Feb 2009 00:58:24 GMT Subject: What is the most recent offical test suite ? Message-ID: I just recently became aware of MarkdownTest_1.0.3 (which discount fails, due to the behavior of code blocks changing from "leave whitespace alone except on the first line" to "leave whitespace alone", and the addition of a new kind of magic link that doesn't seem to be documented); is this the most recent version of the test suite, or is there a newer one out there? -david parsons From michel.fortin at michelf.com Fri Feb 27 21:42:54 2009 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 27 Feb 2009 21:42:54 -0500 Subject: What is the most recent offical test suite ? In-Reply-To: References: Message-ID: Le 2009-02-27 ? 19:58, david parsons a ?crit : > I just recently became aware of MarkdownTest_1.0.3 (which discount > fails, due to the behavior of code blocks changing from "leave > whitespace alone except on the first line" to "leave whitespace > alone", > and the addition of a new kind of magic link that doesn't seem to be > documented); is this the most recent version of the test suite, or is > there a newer one out there? I should really create a webpage for MDTest. Latest release: Mirror of my git repository (which is more up to date). MDTest is a testsuite system I build for testing Markdown parsers. It contains all the tests from John's MarkdownTest (the Markdown testsuite), in additions to another testsuite I made for testing PHP Markdown which should probably apply to any Markdown parser (the PHP Markdown testsuite) and other tests for PHP Markdown Extra. It was also built as a simple performance measurement tool. With the time it takes to process each test and some statistics, it's a lot easier to see how a parser performs with various inputs, as well as to compare parsers one against another. There is also an XML/HTML normalization system so the output can be compared ignoring insignificant whitespace and meaningless differences in output documents. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From pagaltzis at gmx.de Sat Feb 28 09:59:54 2009 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Sat, 28 Feb 2009 15:59:54 +0100 Subject: Cpp-Markdown 1.00 In-Reply-To: <49A86323.7060603@gmail.com> References: <49A5BF53.30106@gmail.com> <49A86323.7060603@gmail.com> Message-ID: <20090228145954.GA12650@klangraum.plasmasturm.org> Hi Chad, * Chad Nelson [2009-02-27 23:05]: > I've been trying to add Cpp-Markdown to the markdown wiki page > at Infogami seems to have fallen into neglect. > If new contributors aren't allowed, could someone who has write > access already add it? Done. Regards, -- Aristotle Pagaltzis // From pagaltzis at gmx.de Sat Feb 28 10:18:27 2009 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Sat, 28 Feb 2009 16:18:27 +0100 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: References: <49A4DF89.9060008@transmekong.com> Message-ID: <20090228151827.GB12650@klangraum.plasmasturm.org> * Michel Fortin [2009-02-25 12:55]: > If you want multiple lines per cell, I'd suggest using a more > explicit grid, something like this: > > id | name | description | more info > ====|=========|==================|===================== > 6 | Inset | An inset element | just one element > ----|---------|------------------|--------------------- > 8 | Stories | Another element | another element > | | | with 2 lines > ----|---------|------------------|--------------------- > 9 | Other | Another element | another element > | | | with 2 lines > ----|---------|------------------|--------------------- > 5 | Illust. | An illustration | line breaks are not > | | andn I think you | possible in a table > | | know what I mena.| > > This is totally unambiguous and easy to scan for the reader. > The problem is that, even though it's easy to read, it's also > more tedious to write. You can make a lot easier to write with a very simple tweak: id | name | description | more info ======================================================= 6 | Inset | An inset element | just one element ------------------------------------------------------- 8 | Stories | Another element | another element | | | with 2 lines ------------------------------------------------------- 9 | Other | Another element | another element | | | with 2 lines ------------------------------------------------------- 5 | Illust. | An illustration | line breaks are not | | andn I think you | possible in a table | | know what I mena.| That is ?sthetically less pleasing, but it?s no less legible, and it?s most definitely *far* less tedious to write. Regards, -- Aristotle Pagaltzis // From pagaltzis at gmx.de Sat Feb 28 10:20:53 2009 From: pagaltzis at gmx.de (Aristotle Pagaltzis) Date: Sat, 28 Feb 2009 16:20:53 +0100 Subject: A Modest Definition List Proposal (David E. Wheeler) In-Reply-To: <20090228151827.GB12650@klangraum.plasmasturm.org> References: <49A4DF89.9060008@transmekong.com> <20090228151827.GB12650@klangraum.plasmasturm.org> Message-ID: <20090228152053.GC12650@klangraum.plasmasturm.org> * Aristotle Pagaltzis [2009-02-28 16:18]: > You can make a lot easier to write with a very simple tweak: Sorry for the noise. Someday I?ll consistently remember to read the whole thread before following my impulse to respond. Regards, -- Aristotle Pagaltzis // From chad.thecomfychair at gmail.com Sat Feb 28 12:59:18 2009 From: chad.thecomfychair at gmail.com (Chad Nelson) Date: Sat, 28 Feb 2009 12:59:18 -0500 Subject: Cpp-Markdown 1.00 In-Reply-To: <20090228145954.GA12650@klangraum.plasmasturm.org> References: <49A5BF53.30106@gmail.com> <49A86323.7060603@gmail.com> <20090228145954.GA12650@klangraum.plasmasturm.org> Message-ID: <49A97B76.5060304@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Infogami seems to have fallen into neglect. > >> If new contributors aren't allowed, could someone who has write >> access already add it? > > Done. Thanks. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmpe3MACgkQp9x9jeZ9/wRoKQCggMnQAUod0dDD8kSAPNRCo+3C i48AoPQzlx7QiSzPg3voou6a1jLfqnWq =8hqm -----END PGP SIGNATURE----- From Bowerbird at aol.com Sat Feb 28 14:35:09 2009 From: Bowerbird at aol.com (Bowerbird at aol.com) Date: Sat, 28 Feb 2009 14:35:09 EST Subject: http://nickgravgaard.com/elastictabstops/ Message-ID: wow. i admired nick's _write-up_ of "elastic tabstops" when i read it... but i skipped his _example_, since java is disabled in my browser. during a re-read, i turned on java, temporarily, to see his example. and i'm _very_ impressed. in real time, on an interactive web-page, nick makes elastic tabstops work, and he makes them work _well_... i mean, i've done it inside an offline app. but this is on the live web! java, of course, is a non-starter, with all the exploits out these days, but my goodness, there must be _some_ other way to enable this... because if you look at this, and can honestly say you don't believe this blows out of the water these perennial threads that are trying to develop a more-sophisticated table format, you're plumb nuts. > http://nickgravgaard.com/elastictabstops/ seriously. -bowerbird ************** A Good Credit Score is 700 or Above. See yours in just 2 easy steps! (http://pr.atwola.com/promoclk/100126575x1218822736x1201267884/aol?redir=http:%2F%2Fwww.freecreditreport.com%2Fpm%2Fdefault.aspx%3Fsc%3D668072%26hmpgID %3D62%26bcd%3DfebemailfooterNO62) -------------- next part -------------- An HTML attachment was scrubbed... URL: From seumas at idirect.ca Sat Feb 28 17:36:11 2009 From: seumas at idirect.ca (Seumas Mac Uilleachan) Date: Sat, 28 Feb 2009 17:36:11 -0500 Subject: Desktop app for viewing Markdown files In-Reply-To: References: <22E0AC4F-E925-413C-BF20-CC7FBB1E16C8@mostrom.pp.se> Message-ID: <49A9BC5B.3090102@idirect.ca> Is there anything like that available for other OS'es (Linux, *BSD)? Tom Humiston wrote: > MarsEdit. It's for writing blog posts. One can enter text in Markdown > format and see a live preview in another panel, showing how it will > look in a browser. Even if you don't actually publish to a blog. > > From the [vendor's website][1]: > > Perfect Previews > Build a template to match your blog, then > let MarsEdit's live preview show you how > your posts will look before you publish them. > > Use Your Favorite Editor > Combine the power of MarsEdit with your > favorite editor. Integrates cleanly with > BBEdit, SubEthaEdit, TextMate, or > TextWrangler. > > "Nearly every word I write for Daring > Fireball is published through MarsEdit." > -- John Gruber, Daring Fireball > > Tom Humiston > Website Designer & Psychic Healer > Kalamazoo, Michigan, USA > > [1]: http://www.red-sweater.com/marsedit/ > > > On 26 Feb 2009, at 9:35 AM, Jan Erik Mostr?m wrote: > >> Is there a file/document browser that render and display Markdown >> files? (for the Mac) >> >> jem > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss >