From andreas.solberg at uninett.no Fri Nov 14 13:26:42 2008 From: andreas.solberg at uninett.no (=?ISO-8859-1?Q?Andreas_=C5kre_Solberg?=) Date: Fri, 14 Nov 2008 19:26:42 +0100 Subject: definition lists? Message-ID: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> Any way of writing definition lists? Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3147 bytes Desc: not available Url : From lists at mostrom.pp.se Fri Nov 14 15:37:17 2008 From: lists at mostrom.pp.se (=?UTF-8?Q?Ja=6E_E=72ik_M=6Fs=74=72=C3=B6?= =?UTF-8?Q?m?=) Date: Fri, 14 Nov 2008 21:37:17 +0100 Subject: definition lists? In-Reply-To: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> Message-ID: Andreas ?kre Solberg 08-11-14 19.26 >Any way of writing definition lists? Depends on which implementation you use. There are a few implementation that allows this. jem -- Jan Erik Mostr?m - www.mostrom.pp.se From waylan at gmail.com Fri Nov 14 15:37:41 2008 From: waylan at gmail.com (Waylan Limberg) Date: Fri, 14 Nov 2008 15:37:41 -0500 Subject: definition lists? In-Reply-To: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> Message-ID: It's in the works. We had a working solution last week, but then refactored the core this week, so I have to refactor the definition list stuff. If you want it right now, your free to checkout from the git repo [1] at commit e968bbf (on Nov 6), or wait a few more days for me to get the refactor done and have the latest and greatest. One thing is for sure, I will have something included in the next release which I anticipate happening soonish. [1]: http://gitorious.org/projects/python-markdown/repos/mainline On Fri, Nov 14, 2008 at 1:26 PM, Andreas ?kre Solberg wrote: > Any way of writing definition lists? > > Andreas > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > > -- ---- Waylan Limberg waylan at gmail.com From eli at markelikalderon.com Wed Nov 19 20:50:22 2008 From: eli at markelikalderon.com (Mark Eli Kalderon) Date: Thu, 20 Nov 2008 01:50:22 +0000 Subject: Links and Message URIs Message-ID: <2F4C1639-1DE9-4AF6-A5DB-57121AE76CAA@markelikalderon.com> Here is a OS X message URI in angled brackets: Markdown yields:

Shouldn't it have given instead:

message://%3cE1KzXg9-0000Qb-3G at smtp1.mail.ox.ac.uk%3e

Best, Mark From waylan at gmail.com Wed Nov 19 22:12:54 2008 From: waylan at gmail.com (Waylan Limberg) Date: Wed, 19 Nov 2008 22:12:54 -0500 Subject: Links and Message URIs In-Reply-To: <2F4C1639-1DE9-4AF6-A5DB-57121AE76CAA@markelikalderon.com> References: <2F4C1639-1DE9-4AF6-A5DB-57121AE76CAA@markelikalderon.com> Message-ID: On Wed, Nov 19, 2008 at 8:50 PM, Mark Eli Kalderon wrote: > Here is a OS X message URI in angled brackets: > > > > Markdown yields: > >

> > Shouldn't it have given instead: > >

href="message://%3cE1KzXg9-0000Qb-3G at smtp1.mail.ox.ac.uk%3e">message://%3cE1KzXg9-0000Qb-3G at smtp1.mail.ox.ac.uk%3e

> Actually, it (sort of) does in a few implementations [1] . I can't speak for the others, but is works in python as a fluck. You see, the regex will only match the 3 schemes; ``http://``, ``https://``, & ``ftp://`` as well as email addresses. As it turns out, the email regex for this case is rather dumb in the Python implementation and looks for any string between angle brackets (``< >``) that has an ``@`` in it. It just so happens that your example message does. That's why its encoded as html entities rather than plain text. Discount appears to behave the same. It looks like PEG Markdown is the only implementation that gives you what you want. Presumably most are seeing it as raw html and passing it through untouched, which explains why the angle brackets are not escaped. Only Pandoc escapes the brackets - which I would think is more correct that raw html treatment in this case. However, it is an obscure enough edge case, that the code would have to special case for it to not see it as raw html, that I wouldn't expect it to never work consistently. [1]: http://babelmark.bobtfish.net/?markdown=%3Cmessage%3A%2F%2F%253cE1KzXg9-0000Qb-3G%40smtp1.mail.ox.ac.uk%253e%3E&src=1&dest=2 -- ---- Waylan Limberg waylan at gmail.com From nichols7 at googlemail.com Fri Nov 21 10:43:44 2008 From: nichols7 at googlemail.com (Thomas Nichols) Date: Fri, 21 Nov 2008 15:43:44 +0000 Subject: Link syntax (was: definition lists?) In-Reply-To: References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> Message-ID: <4926D730.3010502@googlemail.com> Tangentially, I notice that this post by Waylan uses a link syntax which doesn't seem to be defined by but seems to work in some implementations at - that is, from the git repo [1] instead of from the git repo [1][] or from the [git repo] [1]. The link definition is then [1]: http://gitorious.org/projects/python-markdown/repos/mainline Which of the outputs generated at (also available at in case the full URI gets mashed) is considered 'expected'? IIUC, what I'll refer to "Waylan's syntax" makes any text enclosed in square brackets into a candidate for a link; the parser then searches for a matching link definition. I'm undecided whether the simplicity of this syntax offsets the risk of breaking existing documents. A link will only be generated if a matching link definition is found, IIUC, so perhaps this risk is acceptably low? Please point me to a previous discussion if available, I couldn't find one in the archives. Regards, Thomas. Waylan Limberg wrote on 2008/11/14 20:37: > It's in the works. We had a working solution last week, but then > refactored the core this week, so I have to refactor the definition > list stuff. > > If you want it right now, your free to checkout from the git repo [1] > at commit e968bbf (on Nov 6), or wait a few more days for me to get > the refactor done and have the latest and greatest. > > One thing is for sure, I will have something included in the next > release which I anticipate happening soonish. > > [1]: http://gitorious.org/projects/python-markdown/repos/mainline > > On Fri, Nov 14, 2008 at 1:26 PM, Andreas ?kre Solberg > wrote: > >> Any way of writing definition lists? >> >> Andreas >> _______________________________________________ >> Markdown-Discuss mailing list >> Markdown-Discuss at six.pairlist.net >> http://six.pairlist.net/mailman/listinfo/markdown-discuss >> >> >> > > > > From waylan at gmail.com Fri Nov 21 11:31:22 2008 From: waylan at gmail.com (Waylan Limberg) Date: Fri, 21 Nov 2008 11:31:22 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: <4926D730.3010502@googlemail.com> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> Message-ID: On Fri, Nov 21, 2008 at 10:43 AM, Thomas Nichols wrote: > Tangentially, I notice that this post by Waylan uses a link syntax which > doesn't seem to be defined by > but seems to > work in some implementations at - that is, > > from the git repo [1] Actually, that syntax is a common shortcut used by many people in various mailing lists I subscribe to. Many of the people on these lists do not use (or perhaps even know) markdown syntax. I see it kind of a cross between ``[git repo] [1]`` and a footnote. I never expect these mailing list discussions to ever be feed through a markdown parser and don't go all out with the formatting. I use just enough to make it clear to the human reader in plain text without cluttering things up. For links, I find ``[1]`` works best in such situations and is the most commonly accepted approach in the circles I find myself in. I have concidered adding the ability to convert that syntax to links in Python-Markdown, but have not as the label would be wrong IMO. In the above example the result would be ... git repo 1 ... when it should be: ... git repo ... Although, now that I think about it, as the reference is removed by the parser, if the single bracketed text (``[1]``) is left alone in the text, it no longer has any meaning. That's probably worse that a link with a meaningless label. Perhaps Markdown should create the link when a reference for it exists. Although, I'd be more inclined to leave the brackets around the text to give it more meaning in the context: [1] or maybe [1] That said, its not really a big deal to me, as I only ever use that syntax when I do *not* expect the text I'm typing (i.e.: mailing list discussions) to be feed through a markdown parser. As long as that's the case, none of the above arguments (for or against) are relevant as I see it. -- ---- Waylan Limberg waylan at gmail.com From jrblevin at sdf.lonestar.org Fri Nov 21 11:36:30 2008 From: jrblevin at sdf.lonestar.org (Jason Blevins) Date: Fri, 21 Nov 2008 11:36:30 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: <4926D730.3010502@googlemail.com> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> Message-ID: <20081121163630.GA13126@roark.xbeta.org> Thomas Nichols wrote: > Tangentially, I notice that this post by Waylan uses a link syntax which > doesn't seem to be defined by > but seems to > work in some implementations at - that is, > > from the git repo [1] > instead of > from the git repo [1][] > or > from the [git repo] [1]. > > The link definition is then > > [1]: http://gitorious.org/projects/python-markdown/repos/mainline This was introduced in Markdown.pl 1.0.2b2. > Which of the outputs generated at > > (also available at in case the full URI gets > mashed) is considered 'expected'? On Babelmark Markdown.pl 1.0.2b8 honors this implicit reference syntax but 1.0.1 doesn't. I was aware of this syntax so my expected output is that of the beta version. I haven't used it myself though because I've often wondered how 'standard' it is. It looks like the majority of implementations do support it though. > IIUC, what I'll refer to "Waylan's syntax" makes any text enclosed in > square brackets into a candidate for a link; the parser then searches > for a matching link definition. I'm undecided whether the simplicity of > this syntax offsets the risk of breaking existing documents. A link will > only be generated if a matching link definition is found, IIUC, so > perhaps this risk is acceptably low? > > Please point me to a previous discussion if available, I couldn't find > one in the archives. I couldn't find any discussion of it on the list, but here's the changelog entry: 1.0.2b2 - 20 Mar 2005 + Experimental support for [this] as a synonym for [this][]. (Note to self: No test yet for this.) Be sure to test, e.g.: [permutations of this sort of [thing][].] Jason -- Jason Blevins Ph.D. Candidate, Department of Economics, Duke University http://jblevins.org/ From waylan at gmail.com Fri Nov 21 11:58:24 2008 From: waylan at gmail.com (Waylan Limberg) Date: Fri, 21 Nov 2008 11:58:24 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: <20081121163630.GA13126@roark.xbeta.org> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> <20081121163630.GA13126@roark.xbeta.org> Message-ID: On Fri, Nov 21, 2008 at 11:36 AM, Jason Blevins wrote: > > I couldn't find any discussion of it on the list, but here's the > changelog entry: > > 1.0.2b2 - 20 Mar 2005 > > + Experimental support for [this] as a synonym for [this][]. Interestingly, this a completely different use for single-bracketed text than I use and see on a daily basis. As I mentioned before, I see it more as a shortcut footnote type syntax for links only when text is expected to be read in plain text format. -- ---- Waylan Limberg waylan at gmail.com From jrblevin at sdf.lonestar.org Fri Nov 21 12:26:37 2008 From: jrblevin at sdf.lonestar.org (Jason Blevins) Date: Fri, 21 Nov 2008 12:26:37 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> <20081121163630.GA13126@roark.xbeta.org> Message-ID: <20081121172637.GA13403@roark.xbeta.org> Waylan Limberg wrote: > On Fri, Nov 21, 2008 at 11:36 AM, Jason Blevins > wrote: > > > > I couldn't find any discussion of it on the list, but here's the > > changelog entry: > > > > 1.0.2b2 - 20 Mar 2005 > > > > + Experimental support for [this] as a synonym for [this][]. > > Interestingly, this a completely different use for single-bracketed > text than I use and see on a daily basis. As I mentioned before, I see > it more as a shortcut footnote type syntax for links only when text is > expected to be read in plain text format. Thats a good point--I wasn't making the distinction before. Using numbers in brackets like so [1] is definitely a common notation for footnotes. I use it myself in emails but I didn't make the connection. It's also common for math and engineering journals to use that notation for references. Interestingly, that's how peg-markdown (with extensions via -x) renders footnotes. Instead of the link being a superscript '1', you get '[1]'. I actually like that better for the web I think. Superscripts are nice in print, but there you don't have to click on them. -- Jason Blevins Ph.D. Candidate, Department of Economics, Duke University http://jblevins.org/ From waylan at gmail.com Fri Nov 21 12:59:57 2008 From: waylan at gmail.com (Waylan Limberg) Date: Fri, 21 Nov 2008 12:59:57 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: <20081121172637.GA13403@roark.xbeta.org> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> <20081121163630.GA13126@roark.xbeta.org> <20081121172637.GA13403@roark.xbeta.org> Message-ID: On Fri, Nov 21, 2008 at 12:26 PM, Jason Blevins wrote: > Waylan Limberg wrote: >> On Fri, Nov 21, 2008 at 11:36 AM, Jason Blevins >> wrote: >> > >> > I couldn't find any discussion of it on the list, but here's the >> > changelog entry: >> > >> > 1.0.2b2 - 20 Mar 2005 >> > >> > + Experimental support for [this] as a synonym for [this][]. >> >> Interestingly, this a completely different use for single-bracketed >> text than I use and see on a daily basis. As I mentioned before, I see >> it more as a shortcut footnote type syntax for links only when text is >> expected to be read in plain text format. > > Thats a good point--I wasn't making the distinction before. Using > numbers in brackets like so [1] is definitely a common notation for > footnotes. I use it myself in emails but I didn't make the connection. > It's also common for math and engineering journals to use that notation > for references. Just to be clear, I'm not at all suggesting that markdown should adopt [1] at an alternate syntax for [^1]. I only ever use it for links in emails. I don't believe I said anything diferant than that, and no-one thus far seems to think I was, but I wanted to close that door before anyone opens it. > > Interestingly, that's how peg-markdown (with extensions via -x) renders > footnotes. Instead of the link being a superscript '1', you get '[1]'. > I actually like that better for the web I think. Superscripts are nice > in print, but there you don't have to click on them. I have seen that before, and I have mixed feeling about it. It's a little easier to see them, but they also detract from reading the main text a little more than a superscript. Of course, they don't bother me in plain text emails, so it's no big deal. -- ---- Waylan Limberg waylan at gmail.com From michel.fortin at michelf.com Fri Nov 21 13:28:08 2008 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 21 Nov 2008 13:28:08 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: <20081121163630.GA13126@roark.xbeta.org> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> <20081121163630.GA13126@roark.xbeta.org> Message-ID: <90BC99F6-38EA-48F2-80B1-8BAF417DA371@michelf.com> Le 2008-11-21 ? 11:36, Jason Blevins a ?crit : > On Babelmark Markdown.pl 1.0.2b8 honors this implicit reference > syntax but > 1.0.1 doesn't. I was aware of this syntax so my expected output is > that > of the beta version. I haven't used it myself though because I've > often > wondered how 'standard' it is. It looks like the majority of > implementations > do support it though. For PHP Markdown and PHP Markdown Extra, I've kept that syntax disabled on purpose, waiting for an non-beta release of Markdown.pl to make it official (at which point it'll be in the Markdown documentation). The problem is that Markdown.pl 1.0.2 doesn't seem like it'll go out of beta one day... -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From michel.fortin at michelf.com Fri Nov 21 13:28:13 2008 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 21 Nov 2008 13:28:13 -0500 Subject: Link syntax (was: definition lists?) In-Reply-To: <20081121172637.GA13403@roark.xbeta.org> References: <060A7CEA-2233-404A-A42F-B001680B603F@uninett.no> <4926D730.3010502@googlemail.com> <20081121163630.GA13126@roark.xbeta.org> <20081121172637.GA13403@roark.xbeta.org> Message-ID: Le 2008-11-21 ? 12:26, Jason Blevins a ?crit : > Superscripts are nice in print, but there you don't have to click on > them. With a proper stylesheet you can make them as easy to click as anything else. Look at footnotes on Daring Fireball for instance: The clickable region is big enough. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From waysoftheearth at yahoo.com.au Fri Nov 28 02:34:40 2008 From: waysoftheearth at yahoo.com.au (Simon Bull) Date: Fri, 28 Nov 2008 18:34:40 +1100 Subject: Extra markdown suggestions Message-ID: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> Hello List, I have recently started using Michel Fortin's PHP "Markdown Extra" implementation to programmatically transform my markdown text files into HTML. Firstly I'd like to say markdown is very cool -- thanks to everyone involved :) I'd also like to suggest two additions to markdown: 1) I very often use /this/ markdown to indicate emphasis since I find it much easier to type and read than _this_ or *this*. 2) I also use additional setext style headers like this: Header 1 XXXXXXXX Header 2 xxxxxxxx Header 3 ======== Header 4 ++++++++ Header 5 -------- Whether or not these suggestions would be a worthwhile addition to the markdown syntax is one topic. Another topic is about how to go about changing Michel Fortin's PHP code to implement these changes. Is this the right forum to discuss such code changes? Thanks List, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.fortin at michelf.com Fri Nov 28 20:56:20 2008 From: michel.fortin at michelf.com (Michel Fortin) Date: Fri, 28 Nov 2008 20:56:20 -0500 Subject: Extra markdown suggestions In-Reply-To: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> References: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> Message-ID: Le 2008-11-28 ? 2:34, Simon Bull a ?crit : > I have recently started using Michel Fortin's PHP "Markdown Extra" > implementation to programmatically transform my markdown text files > into > HTML. Firstly I'd like to say markdown is very cool -- thanks to > everyone > involved :) > > I'd also like to suggest two additions to markdown: > > 1) I very often use /this/ markdown to indicate emphasis since I > find it > much easier to type and read than _this_ or *this*. Not that you can add it for yourself, but I think Markdown already has enough syntaxes for emphasis. > 2) I also use additional setext style headers like this: > > Header 1 > XXXXXXXX > > Header 2 > xxxxxxxx > > Header 3 > ======== > > Header 4 > ++++++++ > > Header 5 > -------- > > Whether or not these suggestions would be a worthwhile addition to the > markdown syntax is one topic. One problem with your header syntax is that it's not an addition but a change from what Markdown currently does. Nothing prevents you from doing it yourself though. > Another topic is about how to go about changing Michel Fortin's PHP > code to > implement these changes. Look for the doHeaders function. > Is this the right forum to discuss such code > changes? Sure. -- Michel Fortin michel.fortin at michelf.com http://michelf.com/ From qaramazov at gmail.com Fri Nov 28 20:57:25 2008 From: qaramazov at gmail.com (Yuri Takhteyev) Date: Fri, 28 Nov 2008 17:57:25 -0800 Subject: Extra markdown suggestions In-Reply-To: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> References: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> Message-ID: > Another topic is about how to go about changing Michel Fortin's PHP code to > implement these changes. Is this the right forum to discuss such code > changes? In Python Markdown we've put a lot of effort precisely into making such changes as painless as possible. For example, adding support for /emphasis/ just requires one line in _your_ code: import markdown md = markdown.Markdown() md.inlinePatterns["slash_emphasis"] = \ markdown.inlinepatterns.SimpleTagPattern(r'(\/)([^\/]*)\2', 'em') print md.convert("this /should/ work") (This is for the version currently in git. The last released version makes it a little more complicated, though not that much more.) - yuri -- http://sputnik.freewisdom.org/ From waysoftheearth at yahoo.com.au Sat Nov 29 04:31:51 2008 From: waysoftheearth at yahoo.com.au (Simon Bull) Date: Sat, 29 Nov 2008 20:31:51 +1100 Subject: Extra markdown suggestions In-Reply-To: References: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> Message-ID: <7a70dba0811290131x5cc872bfh386a04a4795e31b@mail.gmail.com> Hey guys, Thanks for your quick replies. Michel -- I see your point re: changing the existing setext header rules. Yuri -- That looks great; I will take a look at the latest version and see if I can customise it as you suggest. Simon On Sat, Nov 29, 2008 at 12:57 PM, Yuri Takhteyev wrote: > > Another topic is about how to go about changing Michel Fortin's PHP code > to > > implement these changes. Is this the right forum to discuss such code > > changes? > > In Python Markdown we've put a lot of effort precisely into making > such changes as painless as possible. For example, adding support for > /emphasis/ just requires one line in _your_ code: > > import markdown > md = markdown.Markdown() > md.inlinePatterns["slash_emphasis"] = \ > markdown.inlinepatterns.SimpleTagPattern(r'(\/)([^\/]*)\2', 'em') > print md.convert("this /should/ work") > > (This is for the version currently in git. The last released version > makes it a little more complicated, though not that much more.) > > - yuri > > -- > http://sputnik.freewisdom.org/ > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss at six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at quillio.com Sun Nov 30 15:55:05 2008 From: public at quillio.com (Lou Quillio) Date: Sun, 30 Nov 2008 15:55:05 -0500 Subject: Extra markdown suggestions In-Reply-To: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> References: <7a70dba0811272334p409ff8b7i7d60082e378ffbbe@mail.gmail.com> Message-ID: On Fri, Nov 28, 2008 at 2:34 AM, Simon Bull wrote: > Another topic is about how to go about changing Michel Fortin's PHP code to > implement these changes. Is this the right forum to discuss such code > changes? Usually it's best to leverage the fact that Markdown won't touch existing markup. A preprocessor script -- perhaps abusing Michel's `doHeaders()` method -- would let you then run an unmodified `markdown.php` to finish the job. No hacks to maintain. LQ