Menu
▾
▴
python-markdown-discuss
|
From: Waylan L. <wa...@gm...> - 2009-03-09 02:28:02
|
I am pleased to announce that after much hard work, a Release Candidate for Python Markdown version 2.0 is now available for [download][]. Please, download it, install it, test it, beat it... and report any [bugs][]. Assuming no major bugs, we will release 2.0 final approximately one month from today. Until then, the project [site][] will continue to document version 1.7. Updated documentation is available in the `doc/` directory in the source files. Hopefully, all the included extensions will be documented before the final release. [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets [site]: http://www.freewisdom.org/projects/python-markdown Release Notes: =========== * Major refactor of the core and extension API. Extension authors should see the included documentation in `docs/writing_extensions.txt`. All parts of the syntax are now completely overridable by extensions. * Numerous extensions added to the standard distribution (off by default), including an "extra" extension which matches PHP Markdown Extra. See the `markdown/extensions/` directory for the full list. * The code has been refactored into a full Python library with a separate command line script. * Optional output of XHTML1 (default) or HTML4 with the option for extensions to add more. * Uses ElementTree to build (X)HTML document rather than home-grown NanoDom. * Most of the differences in Python-Markdown's output compared to perl and/or php have been eliminated. * And much more... See the changelog and [Git log][] for more details. [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Eric A. <gi...@gm...> - 2009-03-09 02:35:24
|
On Mar 9, 2009, at 10:27 AM, Waylan Limberg wrote: > I am pleased to announce that after much hard work, a Release > Candidate for Python Markdown version 2.0 is now available for > [download][]. Please, download it, install it, test it, beat it... and > report any [bugs][]. Assuming no major bugs, we will release 2.0 final > approximately one month from today. Until then, the project [site][] > will continue to document version 1.7. Updated documentation is > available in the `doc/` directory in the source files. Hopefully, all > the included extensions will be documented before the final release. Awesome. > > [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 > [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets > [site]: http://www.freewisdom.org/projects/python-markdown > > Release Notes: > =========== > > * Major refactor of the core and extension API. Extension authors > should see the included documentation in > `docs/writing_extensions.txt`. All parts of the syntax are now > completely overridable by extensions. > > * Numerous extensions added to the standard distribution (off by > default), including an "extra" extension which matches PHP Markdown > Extra. See the `markdown/extensions/` directory for the full list. > > * The code has been refactored into a full Python library with a > separate command line script. > > * Optional output of XHTML1 (default) or HTML4 with the option for > extensions to add more. > > * Uses ElementTree to build (X)HTML document rather than home-grown > NanoDom. > > * Most of the differences in Python-Markdown's output compared to perl > and/or php have been eliminated. > > * And much more... See the changelog and [Git log][] for more details. > > [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source > code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss |
|
From: Artem Y. <se...@sp...> - 2009-03-11 00:04:21
|
Glad it's almost released! I think performance increase should be also mentioned. Best Regards, Artem Yunusov On Mon, Mar 9, 2009 at 6:27 AM, Waylan Limberg <wa...@gm...> wrote: > I am pleased to announce that after much hard work, a Release > Candidate for Python Markdown version 2.0 is now available for > [download][]. Please, download it, install it, test it, beat it... and > report any [bugs][]. Assuming no major bugs, we will release 2.0 final > approximately one month from today. Until then, the project [site][] > will continue to document version 1.7. Updated documentation is > available in the `doc/` directory in the source files. Hopefully, all > the included extensions will be documented before the final release. > > [download]: > https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 > [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets > [site]: http://www.freewisdom.org/projects/python-markdown > > Release Notes: > =========== > > * Major refactor of the core and extension API. Extension authors > should see the included documentation in > `docs/writing_extensions.txt`. All parts of the syntax are now > completely overridable by extensions. > > * Numerous extensions added to the standard distribution (off by > default), including an "extra" extension which matches PHP Markdown > Extra. See the `markdown/extensions/` directory for the full list. > > * The code has been refactored into a full Python library with a > separate command line script. > > * Optional output of XHTML1 (default) or HTML4 with the option for > extensions to add more. > > * Uses ElementTree to build (X)HTML document rather than home-grown > NanoDom. > > * Most of the differences in Python-Markdown's output compared to perl > and/or php have been eliminated. > > * And much more... See the changelog and [Git log][] for more details. > > [Git log]: > http://gitorious.org/projects/python-markdown/repos/mainline/logs > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg > > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > |
|
From: Yuri T. <qar...@gm...> - 2009-03-11 00:17:13
|
> Glad it's almost released! I think performance increase should be also > mentioned. Yes, as well as the fact that Artem's work was crucial for getting this version of the ground last summer! BTW, has anyone done any benchmarks recently comparing the performance of this new release candidate to 1.7? - yuri -- http://spu.tnik.org/ |
|
From: Artem Y. <se...@sp...> - 2009-03-13 21:44:57
|
On Wed, Mar 11, 2009 at 4:17 AM, Yuri Takhteyev <qar...@gm...> wrote: > > Glad it's almost released! I think performance increase should be also > > mentioned. > > Yes, as well as the fact that Artem's work was crucial for getting > this version of the ground last summer! > Thanks, > > BTW, has anyone done any benchmarks recently comparing the performance > of this new release candidate to 1.7? > I did today, here is some of the results: 1.7 version: markdown-syntax:1.240000 bracket_re:2.870000 ordered-and-unordered-list:0.190000 2.0 release candidate: markdown-syntax:0.880000 bracket_re:1.670000 ordered-and-unordered-list:0.150000 So it didn't lose speed superiority! > - yuri > Regards, Artem > > -- > http://spu.tnik.org/ > |
|
From: Waylan L. <wa...@gm...> - 2009-03-17 14:05:53
|
Thanks Artem. Are those numbers averages from multiple runs there? In other words, is this something I can use in the release notes? Although, all I really need is a percentage of change - probably just for the "markdown-syntax" document. On Fri, Mar 13, 2009 at 5:38 PM, Artem Yunusov <se...@sp...> wrote: > On Wed, Mar 11, 2009 at 4:17 AM, Yuri Takhteyev <qar...@gm...> wrote: >> BTW, has anyone done any benchmarks recently comparing the performance >> of this new release candidate to 1.7? > > I did today, here is some of the results: > > 1.7 version: > markdown-syntax:1.240000 > bracket_re:2.870000 > ordered-and-unordered-list:0.190000 > > 2.0 release candidate: > markdown-syntax:0.880000 > bracket_re:1.670000 > ordered-and-unordered-list:0.150000 -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Artem Y. <se...@sp...> - 2009-03-18 07:05:58
|
On Tue, Mar 17, 2009 at 6:05 PM, Waylan Limberg <wa...@gm...> wrote: > Thanks Artem. Are those numbers averages from multiple runs there? In > other words, is this something I can use in the release notes? > Although, all I really need is a percentage of change - probably just > for the "markdown-syntax" document. I got this numbers using test-markdown.py, it repeats every test 10 times, so it's not average, it's sum, but for percentage it will be enough. I did it few times and numbers were almost the same. But I can redo it with timeit module to get better accuracy. > > > On Fri, Mar 13, 2009 at 5:38 PM, Artem Yunusov <se...@sp...> wrote: > > On Wed, Mar 11, 2009 at 4:17 AM, Yuri Takhteyev <qar...@gm...> > wrote: > >> BTW, has anyone done any benchmarks recently comparing the performance > >> of this new release candidate to 1.7? > > > > I did today, here is some of the results: > > > > 1.7 version: > > markdown-syntax:1.240000 > > bracket_re:2.870000 > > ordered-and-unordered-list:0.190000 > > > > 2.0 release candidate: > > markdown-syntax:0.880000 > > bracket_re:1.670000 > > ordered-and-unordered-list:0.150000 > > > > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg Regards, Artem |
|
From: Ron G. <ron...@gm...> - 2009-03-23 17:52:26
|
This is probably a stupid question, but since there have already been changes since 2.0rc1 I want to check the code out directly from gitorious. How do I do it? I know how to use git, I just don't know which URI to use. Thanks, rg On Mar 8, 2009, at 7:27 PM, Waylan Limberg wrote: > I am pleased to announce that after much hard work, a Release > Candidate for Python Markdown version 2.0 is now available for > [download][]. Please, download it, install it, test it, beat it... and > report any [bugs][]. Assuming no major bugs, we will release 2.0 final > approximately one month from today. Until then, the project [site][] > will continue to document version 1.7. Updated documentation is > available in the `doc/` directory in the source files. Hopefully, all > the included extensions will be documented before the final release. > > [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 > [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets > [site]: http://www.freewisdom.org/projects/python-markdown > > Release Notes: > =========== > > * Major refactor of the core and extension API. Extension authors > should see the included documentation in > `docs/writing_extensions.txt`. All parts of the syntax are now > completely overridable by extensions. > > * Numerous extensions added to the standard distribution (off by > default), including an "extra" extension which matches PHP Markdown > Extra. See the `markdown/extensions/` directory for the full list. > > * The code has been refactored into a full Python library with a > separate command line script. > > * Optional output of XHTML1 (default) or HTML4 with the option for > extensions to add more. > > * Uses ElementTree to build (X)HTML document rather than home-grown > NanoDom. > > * Most of the differences in Python-Markdown's output compared to perl > and/or php have been eliminated. > > * And much more... See the changelog and [Git log][] for more details. > > [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source > code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss |
|
From: Artem Y. <se...@sp...> - 2009-03-23 18:37:19
|
On Mon, Mar 23, 2009 at 9:52 PM, Ron Garret <ron...@gm...> wrote: > This is probably a stupid question, but since there have already been > changes since 2.0rc1 I want to check the code out directly from > gitorious. How do I do it? I know how to use git, I just don't know > which URI to use. > You can clone current version with: git clone git://gitorious.org/python-markdown/mainline.git > > Thanks, > rg Regards, Artem > > > On Mar 8, 2009, at 7:27 PM, Waylan Limberg wrote: > > > I am pleased to announce that after much hard work, a Release > > Candidate for Python Markdown version 2.0 is now available for > > [download][]. Please, download it, install it, test it, beat it... and > > report any [bugs][]. Assuming no major bugs, we will release 2.0 final > > approximately one month from today. Until then, the project [site][] > > will continue to document version 1.7. Updated documentation is > > available in the `doc/` directory in the source files. Hopefully, all > > the included extensions will be documented before the final release. > > > > [download]: > https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 > > [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets > > [site]: http://www.freewisdom.org/projects/python-markdown > > > > Release Notes: > > =========== > > > > * Major refactor of the core and extension API. Extension authors > > should see the included documentation in > > `docs/writing_extensions.txt`. All parts of the syntax are now > > completely overridable by extensions. > > > > * Numerous extensions added to the standard distribution (off by > > default), including an "extra" extension which matches PHP Markdown > > Extra. See the `markdown/extensions/` directory for the full list. > > > > * The code has been refactored into a full Python library with a > > separate command line script. > > > > * Optional output of XHTML1 (default) or HTML4 with the option for > > extensions to add more. > > > > * Uses ElementTree to build (X)HTML document rather than home-grown > > NanoDom. > > > > * Most of the differences in Python-Markdown's output compared to perl > > and/or php have been eliminated. > > > > * And much more... See the changelog and [Git log][] for more details. > > > > [Git log]: > http://gitorious.org/projects/python-markdown/repos/mainline/logs > > > > -- > > ---- > > \X/ /-\ `/ |_ /-\ |\| > > Waylan Limberg > > > > > ------------------------------------------------------------------------------ > > Open Source Business Conference (OSBC), March 24-25, 2009, San > > Francisco, CA > > -OSBC tackles the biggest issue in open source: Open Sourcing the > > Enterprise > > -Strategies to boost innovation and cut costs with open source > > participation > > -Receive a $600 discount off the registration fee with the source > > code: SFAD > > http://p.sf.net/sfu/XcvMzF8H > > _______________________________________________ > > Python-markdown-discuss mailing list > > Pyt...@li... > > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > |
|
From: Yuri T. <qar...@gm...> - 2009-03-23 18:26:15
|
See http://gitorious.org/projects/python-markdown/repos/mainline - yuri On Mon, Mar 23, 2009 at 10:52 AM, Ron Garret <ron...@gm...> wrote: > This is probably a stupid question, but since there have already been > changes since 2.0rc1 I want to check the code out directly from > gitorious. How do I do it? I know how to use git, I just don't know > which URI to use. > > Thanks, > rg > > On Mar 8, 2009, at 7:27 PM, Waylan Limberg wrote: > >> I am pleased to announce that after much hard work, a Release >> Candidate for Python Markdown version 2.0 is now available for >> [download][]. Please, download it, install it, test it, beat it... and >> report any [bugs][]. Assuming no major bugs, we will release 2.0 final >> approximately one month from today. Until then, the project [site][] >> will continue to document version 1.7. Updated documentation is >> available in the `doc/` directory in the source files. Hopefully, all >> the included extensions will be documented before the final release. >> >> [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 >> [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets >> [site]: http://www.freewisdom.org/projects/python-markdown >> >> Release Notes: >> =========== >> >> * Major refactor of the core and extension API. Extension authors >> should see the included documentation in >> `docs/writing_extensions.txt`. All parts of the syntax are now >> completely overridable by extensions. >> >> * Numerous extensions added to the standard distribution (off by >> default), including an "extra" extension which matches PHP Markdown >> Extra. See the `markdown/extensions/` directory for the full list. >> >> * The code has been refactored into a full Python library with a >> separate command line script. >> >> * Optional output of XHTML1 (default) or HTML4 with the option for >> extensions to add more. >> >> * Uses ElementTree to build (X)HTML document rather than home-grown >> NanoDom. >> >> * Most of the differences in Python-Markdown's output compared to perl >> and/or php have been eliminated. >> >> * And much more... See the changelog and [Git log][] for more details. >> >> [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs >> >> -- >> ---- >> \X/ /-\ `/ |_ /-\ |\| >> Waylan Limberg >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Python-markdown-discuss mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > -- http://spu.tnik.org/ |
|
From: Ron G. <ron...@gm...> - 2009-03-23 18:34:30
|
Thanks! On Mar 23, 2009, at 11:26 AM, Yuri Takhteyev wrote: > See http://gitorious.org/projects/python-markdown/repos/mainline > > - yuri > > > On Mon, Mar 23, 2009 at 10:52 AM, Ron Garret <ron...@gm...> > wrote: >> This is probably a stupid question, but since there have already been >> changes since 2.0rc1 I want to check the code out directly from >> gitorious. How do I do it? I know how to use git, I just don't know >> which URI to use. >> >> Thanks, >> rg >> >> On Mar 8, 2009, at 7:27 PM, Waylan Limberg wrote: >> >>> I am pleased to announce that after much hard work, a Release >>> Candidate for Python Markdown version 2.0 is now available for >>> [download][]. Please, download it, install it, test it, beat it... >>> and >>> report any [bugs][]. Assuming no major bugs, we will release 2.0 >>> final >>> approximately one month from today. Until then, the project [site][] >>> will continue to document version 1.7. Updated documentation is >>> available in the `doc/` directory in the source files. Hopefully, >>> all >>> the included extensions will be documented before the final release. >>> >>> [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 >>> [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets >>> [site]: http://www.freewisdom.org/projects/python-markdown >>> >>> Release Notes: >>> =========== >>> >>> * Major refactor of the core and extension API. Extension authors >>> should see the included documentation in >>> `docs/writing_extensions.txt`. All parts of the syntax are now >>> completely overridable by extensions. >>> >>> * Numerous extensions added to the standard distribution (off by >>> default), including an "extra" extension which matches PHP Markdown >>> Extra. See the `markdown/extensions/` directory for the full list. >>> >>> * The code has been refactored into a full Python library with a >>> separate command line script. >>> >>> * Optional output of XHTML1 (default) or HTML4 with the option for >>> extensions to add more. >>> >>> * Uses ElementTree to build (X)HTML document rather than home-grown >>> NanoDom. >>> >>> * Most of the differences in Python-Markdown's output compared to >>> perl >>> and/or php have been eliminated. >>> >>> * And much more... See the changelog and [Git log][] for more >>> details. >>> >>> [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs >>> >>> -- >>> ---- >>> \X/ /-\ `/ |_ /-\ |\| >>> Waylan Limberg >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>> Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source >>> code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Python-markdown-discuss mailing list >>> Pyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss >> >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. >> Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Python-markdown-discuss mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss >> > > > > -- > http://spu.tnik.org/ |
|
From: Waylan L. <wa...@gm...> - 2009-03-23 19:00:49
|
Hey Ron, I appreciate the testing. Especially considering that some of those changes were more than a simple bug-fix. I was intending to do another rc today (half-way between rc1 and when we plan on releasing 2.0 final) but being out-of-town this past weekend, I haven't got to it yet. I also wanted to do another rc because I forgot to include a Python 3.0 version with the last rc as we had previously discussed. Hopefully I'll get these out tonight. On Mon, Mar 23, 2009 at 1:52 PM, Ron Garret <ron...@gm...> wrote: > This is probably a stupid question, but since there have already been > changes since 2.0rc1 I want to check the code out directly from > gitorious. How do I do it? I know how to use git, I just don't know > which URI to use. > > Thanks, > rg > > On Mar 8, 2009, at 7:27 PM, Waylan Limberg wrote: > >> I am pleased to announce that after much hard work, a Release >> Candidate for Python Markdown version 2.0 is now available for >> [download][]. Please, download it, install it, test it, beat it... and >> report any [bugs][]. Assuming no major bugs, we will release 2.0 final >> approximately one month from today. Until then, the project [site][] >> will continue to document version 1.7. Updated documentation is >> available in the `doc/` directory in the source files. Hopefully, all >> the included extensions will be documented before the final release. >> >> [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 >> [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets >> [site]: http://www.freewisdom.org/projects/python-markdown >> >> Release Notes: >> =========== >> >> * Major refactor of the core and extension API. Extension authors >> should see the included documentation in >> `docs/writing_extensions.txt`. All parts of the syntax are now >> completely overridable by extensions. >> >> * Numerous extensions added to the standard distribution (off by >> default), including an "extra" extension which matches PHP Markdown >> Extra. See the `markdown/extensions/` directory for the full list. >> >> * The code has been refactored into a full Python library with a >> separate command line script. >> >> * Optional output of XHTML1 (default) or HTML4 with the option for >> extensions to add more. >> >> * Uses ElementTree to build (X)HTML document rather than home-grown >> NanoDom. >> >> * Most of the differences in Python-Markdown's output compared to perl >> and/or php have been eliminated. >> >> * And much more... See the changelog and [Git log][] for more details. >> >> [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs >> >> -- >> ---- >> \X/ /-\ `/ |_ /-\ |\| >> Waylan Limberg >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Python-markdown-discuss mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Ron G. <ron...@gm...> - 2009-03-23 19:19:24
|
My pleasure. Thanks for the code :-) Couple of comments. These are really design issues, not bugs, but FWIW: 1. The wikilink behavior has changed in a non-backwards-compatible way. Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they are not. Personally, I preferred the old way. 2. I don't like PHP table syntax because it makes it impossible to create a table without headers. I know this has been discussed before (though have not been able to find that discussion -- can someone send me a pointer?) so maybe there's a sound reason for choosing this syntax over some of the alternatives, but at the moment I can't think what it might be. One good thing about the new code is that it's really easy for me to change these things myself. :-) I mention them only in case there's a desire to prevent people from branching too much. rg On Mar 23, 2009, at 12:00 PM, Waylan Limberg wrote: > Hey Ron, > > I appreciate the testing. Especially considering that some of those > changes were more than a simple bug-fix. I was intending to do another > rc today (half-way between rc1 and when we plan on releasing 2.0 > final) but being out-of-town this past weekend, I haven't got to it > yet. > > I also wanted to do another rc because I forgot to include a Python > 3.0 version with the last rc as we had previously discussed. Hopefully > I'll get these out tonight. > > On Mon, Mar 23, 2009 at 1:52 PM, Ron Garret <ron...@gm...> > wrote: >> This is probably a stupid question, but since there have already been >> changes since 2.0rc1 I want to check the code out directly from >> gitorious. How do I do it? I know how to use git, I just don't know >> which URI to use. >> >> Thanks, >> rg >> >> On Mar 8, 2009, at 7:27 PM, Waylan Limberg wrote: >> >>> I am pleased to announce that after much hard work, a Release >>> Candidate for Python Markdown version 2.0 is now available for >>> [download][]. Please, download it, install it, test it, beat it... >>> and >>> report any [bugs][]. Assuming no major bugs, we will release 2.0 >>> final >>> approximately one month from today. Until then, the project [site][] >>> will continue to document version 1.7. Updated documentation is >>> available in the `doc/` directory in the source files. Hopefully, >>> all >>> the included extensions will be documented before the final release. >>> >>> [download]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=666767 >>> [bugs]: http://www.freewisdom.org/projects/python-markdown/Tickets >>> [site]: http://www.freewisdom.org/projects/python-markdown >>> >>> Release Notes: >>> =========== >>> >>> * Major refactor of the core and extension API. Extension authors >>> should see the included documentation in >>> `docs/writing_extensions.txt`. All parts of the syntax are now >>> completely overridable by extensions. >>> >>> * Numerous extensions added to the standard distribution (off by >>> default), including an "extra" extension which matches PHP Markdown >>> Extra. See the `markdown/extensions/` directory for the full list. >>> >>> * The code has been refactored into a full Python library with a >>> separate command line script. >>> >>> * Optional output of XHTML1 (default) or HTML4 with the option for >>> extensions to add more. >>> >>> * Uses ElementTree to build (X)HTML document rather than home-grown >>> NanoDom. >>> >>> * Most of the differences in Python-Markdown's output compared to >>> perl >>> and/or php have been eliminated. >>> >>> * And much more... See the changelog and [Git log][] for more >>> details. >>> >>> [Git log]: http://gitorious.org/projects/python-markdown/repos/mainline/logs >>> >>> -- >>> ---- >>> \X/ /-\ `/ |_ /-\ |\| >>> Waylan Limberg >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>> Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source >>> code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Python-markdown-discuss mailing list >>> Pyt...@li... >>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss >> >> >> ------------------------------------------------------------------------------ >> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) >> are >> powering Web 2.0 with engaging, cross-platform capabilities. >> Quickly and >> easily build your RIAs with Flex Builder, the Eclipse(TM)based >> development >> software that enables intelligent coding and step-through debugging. >> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >> _______________________________________________ >> Python-markdown-discuss mailing list >> Pyt...@li... >> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss >> > > > > -- > ---- > \X/ /-\ `/ |_ /-\ |\| > Waylan Limberg |
|
From: Waylan L. <wa...@gm...> - 2009-03-23 20:08:39
|
Thanks for the feedback Ron. I've responded you your concerns below to keep things in context. On Mon, Mar 23, 2009 at 3:19 PM, Ron Garret <ron...@gm...> wrote: > My pleasure. Thanks for the code :-) > > Couple of comments. These are really design issues, not bugs, but FWIW: > > 1. The wikilink behavior has changed in a non-backwards-compatible way. > Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they are not. > Personally, I preferred the old way. What was the old way? I don't remember changing that. Could you provide an example of the current output and the expected output? > 2. I don't like PHP table syntax because it makes it impossible to create a > table without headers. I know this has been discussed before (though have > not been able to find that discussion -- can someone send me a pointer?) so > maybe there's a sound reason for choosing this syntax over some of the > alternatives, but at the moment I can't think what it might be. Well, the reason is that this (PHP) is an already existing and highly distributed implementation. The idea is that one should be able to pass the same source documents through any implementation and get back the same result. So, I went with an already existing implementation. I was originally going to add in the option to allow tables without headers, but that presented the problem of how to define column alignment and I didn't want to introduce new syntax. On further reflection, I realized that the purpose of a table (in Markdown even more so than HTML) should only be for tabular data, and when does tabular data not have column headers? I suppose it's possible, but very unlikely. I suspect that is why the PHP implementation is so restrictive in that regard. Oh, you asked for a pointer to a previous discussion. Um, check the markdown list [1]. There was a recent discussion regarding table syntax with all sorts of alternatives discussed, but in the end, most of it was more complex that what fits with the Markdown philosophy. So I ignored those suggestions and went with what I believe to be the mostly widely used existing implementation. [1]: http://six.pairlist.net/pipermail/markdown-discuss/ > One good thing about the new code is that it's really easy for me to change > these things myself. :-) And it is for that very reason that I left the syntax as-is. Anyone can build upon the existing base - or even start over from scratch. > I mention them only in case there's a desire to > prevent people from branching too much. Anyone is encouraged to branch and create their own extensions. That is part of the point of our extension API. In fact, the extension API is what we pride ourselves in most with the project - even before performance. But, yeah, the default implementation isn't going to branch to far from the existing standard for the reasons mentioned above. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Ron G. <ron...@gm...> - 2009-03-23 20:21:53
|
On Mar 23, 2009, at 1:08 PM, Waylan Limberg wrote:
> Thanks for the feedback Ron. I've responded you your concerns below to
> keep things in context.
>
> On Mon, Mar 23, 2009 at 3:19 PM, Ron Garret <ron...@gm...>
> wrote:
>> My pleasure. Thanks for the code :-)
>>
>> Couple of comments. These are really design issues, not bugs, but
>> FWIW:
>>
>> 1. The wikilink behavior has changed in a non-backwards-compatible
>> way.
>> Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they
>> are not.
>> Personally, I preferred the old way.
>
> What was the old way? I don't remember changing that. Could you
> provide an example of the current output and the expected output?
>
The old one converted spaces to CamelCase. The new one converts
spaces to underscores.
Old:
Python 2.6.1 (r261:67515, Dec 6 2008, 16:42:21)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import markdown
>>> markdown.version
'1.7'
>>> markdown.markdown('[[wiki link]]',['wikilink'])
u'<p><a href="/WikiLink/" class="wikilink">wiki link</a>\n</p>'
New:
>>> import markdown
>>> markdown.version
'2.0-rc1'
>>> markdown.markdown('[[wiki link]]',['wikilinks'])
u'<p><a class="wikilink" href="/wiki_link/">wiki link</a></p>'
>>>
rg
|
|
From: Yuri T. <qar...@gm...> - 2009-03-23 22:27:28
|
>> 1. The wikilink behavior has changed in a non-backwards-compatible way.
>> Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they are not.
>> Personally, I preferred the old way.
The new way is closer to what Wikipedia does, which is a big plus, I
think. However, perhaps it would make sense to make this configurable.
Right now we have
label.replace(' ', '_')
in markdown/extensions/wikilinks.py
Both arguments to replace could perhaps be configurable, and the first
one should probably be treated as a regular expression. Alternatively,
we could have a config parameter that could be set to a function that
would be used to do the conversion, so you would have something like:
makeExtension(configs = {'make_url': lambda x: label.replace(' ', '')})
> Well, the reason is that this (PHP) is an already existing and highly
> distributed implementation. The idea is that one should be able to
> pass the same source documents through any implementation and get back
> the same result. So, I went with an already existing implementation.
I agree with this completely. I think it would be great to have a set
of extensions that get us as close as possible to PHP Markdown Extra.
People are free, however, to implement their own table extensions,
that have different behavior, and we can even add some of them to our
collections of extensions.
> Anyone is encouraged to branch and create their own extensions.
For extensions - definitely. Of course, it's good to always look for
opportunities for code reuse. E.g., instead of actually branching
code, it may be better to have a different extension that uses the
same module but just configures it differently.
- yuri
--
http://spu.tnik.org/
|
|
From: Waylan L. <wa...@gm...> - 2009-03-23 23:05:30
|
On Mon, Mar 23, 2009 at 4:21 PM, Ron Garret <ron...@gm...> wrote: > > On Mar 23, 2009, at 1:08 PM, Waylan Limberg wrote: > >> Thanks for the feedback Ron. I've responded you your concerns below to >> keep things in context. >> >> On Mon, Mar 23, 2009 at 3:19 PM, Ron Garret <ron...@gm...> >> wrote: >>> >>> 1. The wikilink behavior has changed in a non-backwards-compatible >>> way. >>> Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they >>> are not. >>> Personally, I preferred the old way. >> >> What was the old way? I don't remember changing that. Could you >> provide an example of the current output and the expected output? >> > > > The old one converted spaces to CamelCase. The new one converts > spaces to underscores. > Oh, sorry I misunderstood you. You put brackets around both. The old way worked only on CamelCase and did not use brackets at all. The new way only uses brackets and ignored case. If you notice, the extension name even changed from "wikilink" to "wikilinks" (the "s" was added) so that old code would not work without changes with the new extension. The point is, this is actually a different extension. As Yuri pointed out, this is actually considered a better wikilink syntax. Of course, you are free to implement the old syntax if you can. We ran into a few technical difficulties with some of the other changes in the code, which is why we dropped the old. But we'd be be happy to add it back in if you can get it to work. -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Ron G. <ron...@gm...> - 2009-03-23 23:26:41
|
On Mar 23, 2009, at 4:05 PM, Waylan Limberg wrote:
> On Mon, Mar 23, 2009 at 4:21 PM, Ron Garret <ron...@gm...>
> wrote:
>>
>> On Mar 23, 2009, at 1:08 PM, Waylan Limberg wrote:
>>
>>> Thanks for the feedback Ron. I've responded you your concerns
>>> below to
>>> keep things in context.
>>>
>>> On Mon, Mar 23, 2009 at 3:19 PM, Ron Garret <ron...@gm...>
>>> wrote:
>>>>
>>>> 1. The wikilink behavior has changed in a non-backwards-compatible
>>>> way.
>>>> Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they
>>>> are not.
>>>> Personally, I preferred the old way.
>>>
>>> What was the old way? I don't remember changing that. Could you
>>> provide an example of the current output and the expected output?
>>>
>>
>>
>> The old one converted spaces to CamelCase. The new one converts
>> spaces to underscores.
>>
> Oh, sorry I misunderstood you. You put brackets around both. The old
> way worked only on CamelCase and did not use brackets at all. The new
> way only uses brackets and ignored case. If you notice, the extension
> name even changed from "wikilink" to "wikilinks" (the "s" was added)
> so that old code would not work without changes with the new
> extension. The point is, this is actually a different extension.
>
> As Yuri pointed out, this is actually considered a better wikilink
> syntax. Of course, you are free to implement the old syntax if you
> can. We ran into a few technical difficulties with some of the other
> changes in the code, which is why we dropped the old. But we'd be be
> happy to add it back in if you can get it to work.
Doh! I just remembered...
We had this discussion about CamelCase versus [[brackets]] before and
you convinced me that brackets were better. So I actually went and
changed the old wikilink (no 'S') extension to use brackets. But I
forgot that I had done that, and I didn't change the name of the file,
so I just thought this was the way the old extension worked.
So forget everything I said about the way things used to work :-)
Instead, I would suggest ab initio that wikilinks be canonicalized
through a user-configurable canonicalizer that defaults to Wikipedia's
canonicalization rules. This would be a very simple change to make.
Just change:
label.replace(' ', '_')
to
self.canonicalize(label)
and then add 'canonicalize' to configs, defaulting to
wikipedia_canonicalize (which someone would still need to write, but
that's not hard).
Here's the CamelCase canonicalizer that I personally prefer:
def camelCase_canonicalize(s):
return ''.join([w[0].upper()+w[1:] for w in s.split()])
rg
|
|
From: Ron G. <ro...@fl...> - 2009-03-23 23:18:28
|
On Mar 23, 2009, at 3:27 PM, Yuri Takhteyev wrote: >>> 1. The wikilink behavior has changed in a non-backwards- >>> compatible way. >>> Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they >>> are not. >>> Personally, I preferred the old way. > > The new way is closer to what Wikipedia does, which is a big plus Perhaps, but if that's the goal then actually doing it the way Wikipedia does it would be even better than just being "way closer." Wikipedia contracts multiple spaces down to one, but markdown.py doesn't. Wikipedia allows wikilinks that start with an underscore; markdown.py doesn't. In general, I think the wikilink canonicalization algorithm ought to have the property that two wikilinks that look like the "ought" to be the same actually are the same. [[WikiLink]] and [[wiki link]] are perhaps arguable, but [[wiki link]] and [[wiki link]] aren't IMO. > I think. However, perhaps it would make sense to make this > configurable. That would be fine with me. Maybe this could even subsume base_url and end_url. > >> Well, the reason is that this (PHP) is an already existing and highly >> distributed implementation. The idea is that one should be able to >> pass the same source documents through any implementation and get >> back >> the same result. So, I went with an already existing implementation. > > I agree with this completely. I think it would be great to have a set > of extensions that get us as close as possible to PHP Markdown Extra. That's a fine goal, but what's wrong with being a superset of PHP MD Extra? rg |
|
From: Waylan L. <wa...@gm...> - 2009-03-24 01:05:26
|
On Mon, Mar 23, 2009 at 6:55 PM, Ron Garret <ro...@fl...> wrote: > > On Mar 23, 2009, at 3:27 PM, Yuri Takhteyev wrote: > >>>> 1. The wikilink behavior has changed in a non-backwards- >>>> compatible way. >>>> Before, [[WikiLink]] and [[wiki link]] were equivalent. Now they >>>> are not. >>>> Personally, I preferred the old way. >> >> The new way is closer to what Wikipedia does, which is a big plus > > Perhaps, but if that's the goal then actually doing it the way > Wikipedia does it would be even better than just being "way closer." > Wikipedia contracts multiple spaces down to one, but markdown.py > doesn't. Ok, I hadn't considered that one, and it is a little strange but see my comments below. > Wikipedia allows wikilinks that start with an underscore; > markdown.py doesn't. Yes it does. Any allowed character it allowed at any location in the link. > In general, I think the wikilink canonicalization algorithm ought to > have the property that two wikilinks that look like the "ought" to be > the same actually are the same. [[WikiLink]] and [[wiki link]] are > perhaps arguable, but [[wiki link]] and [[wiki link]] aren't IMO. > The way things work now is that what you put between brackets is exactly what you get in the label. A long standing annoyance of mine is wikilink systems which don't allow me to format the label how I want as long as I use the allowed characters. This extension does. So, if I put double spaces in my link, then I want that to carry through to the label. Of course, the link itself has to be altered as spaces are not allowed in urls. So I did the simplest thing possible. I replaced the space with an underscore. Although it's not too sophisticated, it does return what should be valid urls consistently. >> I think. However, perhaps it would make sense to make this >> configurable. I see a few options here: 1. Improve the space replacement code, otherwise leaving things as is and tell people to write their own extension. Perhaps even subclassing ours to get their desired behavior. 2. Allow the config to accept a callable and provide a default which formats the wikilink for insertion into the url. 3. Allow the config to accept a callable that builds the entire url. This would remove the need for the 'start_url' and 'end_url' configs as they would be part of the callable. 4. Allow the config to accept a callable that builds the entire <a> element and returns it. Of course, we provide a default. For example, this would also allow people to easily override the default to add a class indicating whether the link points to an existing page or not. This would remove the need for all the existing config options. Personally, I think option 1 is good enough. One can always write their own extension that fits their needs. However, if we're going to really make things configurable, then we might as well go all the way with 4. My only concern about that it that it requires any customization to require working with ET. That might be too high a barrier of entry for some. Despite my preference, I suppose the same could be said of option 1 (requiring them to write their own extension to change the behavior). Which leaves us with 2 or 3. Any thoughts? -- ---- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg |
|
From: Ron G. <ro...@fl...> - 2009-03-24 04:50:24
|
On Mar 23, 2009, at 6:05 PM, Waylan Limberg wrote:
>
>> Wikipedia allows wikilinks that start with an underscore;
>> markdown.py doesn't.
>
> Yes it does. Any allowed character it allowed at any location in the
> link.
>
Ah. There is a bug there, but it's not what I thought:
>>> markdown.markdown('[[foo _baz_]]',['wikilinks'])
u'<p>[[foo <em>baz</em>]]</p>'
Apparently it doesn't like _emphasis_ inside a wikilink.
>> In general, I think the wikilink canonicalization algorithm ought to
>> have the property that two wikilinks that look like the "ought" to be
>> the same actually are the same. [[WikiLink]] and [[wiki link]] are
>> perhaps arguable, but [[wiki link]] and [[wiki link]] aren't IMO.
>>
>
> The way things work now is that what you put between brackets is
> exactly what you get in the label. A long standing annoyance of mine
> is wikilink systems which don't allow me to format the label how I
> want as long as I use the allowed characters. This extension does. So,
> if I put double spaces in my link, then I want that to carry through
> to the label.
Yes, to the *label*, but not to the URL.
> Of course, the link itself has to be altered as spaces are not allowed
> in urls. So I did the simplest thing possible. I replaced the space
> with an underscore. Although it's not too sophisticated, it does
> return what should be valid urls consistently.
This is certainly arguable on both sides. IMO, there should be a
canonicalization process, otherwise you risk getting multiple pages
that really should be the same page. I think [[John F Kennedy]],
[[John F. Kennedy]] and [[John F Kennedy]] should all point to the
same place. But reasonable people could disagree.
>
>>> I think. However, perhaps it would make sense to make this
>>> configurable.
>
> I see a few options here:
>
> 1. Improve the space replacement code, otherwise leaving things as is
> and tell people to write their own extension. Perhaps even subclassing
> ours to get their desired behavior.
>
> 2. Allow the config to accept a callable and provide a default which
> formats the wikilink for insertion into the url.
>
> 3. Allow the config to accept a callable that builds the entire url.
> This would remove the need for the 'start_url' and 'end_url' configs
> as they would be part of the callable.
>
> 4. Allow the config to accept a callable that builds the entire <a>
> element and returns it. Of course, we provide a default. For example,
> this would also allow people to easily override the default to add a
> class indicating whether the link points to an existing page or not.
> This would remove the need for all the existing config options.
>
> Personally, I think option 1 is good enough. One can always write
> their own extension that fits their needs. However, if we're going to
> really make things configurable, then we might as well go all the way
> with 4. My only concern about that it that it requires any
> customization to require working with ET. That might be too high a
> barrier of entry for some. Despite my preference, I suppose the same
> could be said of option 1 (requiring them to write their own extension
> to change the behavior). Which leaves us with 2 or 3. Any thoughts?
I like option 3 myself. Makes it simpler and more powerful, which is
always a winning combination in my book.
rg
|
|
From: Waylan L. <wa...@gm...> - 2009-03-24 18:10:08
|
On Tue, Mar 24, 2009 at 12:50 AM, Ron Garret <ro...@fl...> wrote:
>
> On Mar 23, 2009, at 6:05 PM, Waylan Limberg wrote:
>
>>
>>> Wikipedia allows wikilinks that start with an underscore;
>>> markdown.py doesn't.
>>
>> Yes it does. Any allowed character it allowed at any location in the
>> link.
>>
>
> Ah. There is a bug there, but it's not what I thought:
>
> >>> markdown.markdown('[[foo _baz_]]',['wikilinks'])
> u'<p>[[foo <em>baz</em>]]</p>'
>
> Apparently it doesn't like _emphasis_ inside a wikilink.
>
So, before I fixed this, I addressed the multiple spaces issue.
Multiple spaces become one underscore in the url. That was easy. But,
moving on to this; I am of the assumption that emphasis doesn't belong
in a wikilink. If you want emphasis, then either wrap the entire link
(``_[[foo]]_``) or use regular markdown link syntax. So, then Ron's
above example becomes:
<p><a class="wikilink" href="/foo__baz_/">foo _baz_</a></p>
If a space is adjacent to an underscore, then we get double
underscores in the url. Should I try to work around this or not?
Thoughts?
I should point out that if I do work around it, then it would be
impossible to generate a url with double underscores. For example
``[[foo__bar]]`` becomes ``/foo_bar/``. I'm not as comfortable with
that as I am with combining spaces.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
|
|
From: Waylan L. <wa...@gm...> - 2009-03-25 02:27:39
|
I think I worked around this spaces and underscores thing. I just
pushed the change. Let me know what you think.
On Tue, Mar 24, 2009 at 2:09 PM, Waylan Limberg <wa...@gm...> wrote:
> On Tue, Mar 24, 2009 at 12:50 AM, Ron Garret <ro...@fl...> wrote:
>>
>> On Mar 23, 2009, at 6:05 PM, Waylan Limberg wrote:
>>
>>>
>>>> Wikipedia allows wikilinks that start with an underscore;
>>>> markdown.py doesn't.
>>>
>>> Yes it does. Any allowed character it allowed at any location in the
>>> link.
>>>
>>
>> Ah. There is a bug there, but it's not what I thought:
>>
>> >>> markdown.markdown('[[foo _baz_]]',['wikilinks'])
>> u'<p>[[foo <em>baz</em>]]</p>'
>>
>> Apparently it doesn't like _emphasis_ inside a wikilink.
>>
>
> So, before I fixed this, I addressed the multiple spaces issue.
> Multiple spaces become one underscore in the url. That was easy. But,
> moving on to this; I am of the assumption that emphasis doesn't belong
> in a wikilink. If you want emphasis, then either wrap the entire link
> (``_[[foo]]_``) or use regular markdown link syntax. So, then Ron's
> above example becomes:
>
> <p><a class="wikilink" href="/foo__baz_/">foo _baz_</a></p>
>
> If a space is adjacent to an underscore, then we get double
> underscores in the url. Should I try to work around this or not?
> Thoughts?
>
> I should point out that if I do work around it, then it would be
> impossible to generate a url with double underscores. For example
> ``[[foo__bar]]`` becomes ``/foo_bar/``. I'm not as comfortable with
> that as I am with combining spaces.
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X