python-markdown-discuss — A general purpose discussion list

[Python-markdown-discuss] Python-Markdown 2.0.1-beta BugFix Release

[Waylan L. <wa...@gm...>]

Python-Markdown 2.0.1-beta is available for download and testing. It
should resolve the various command line problems people were having,
so, please test it on your various systems and report back. The
commandline script is now called `markdown` (no .py) and on windows
you also get a batch script wrapper.

You can get the files here:

http://tinyurl.com/dje42b

or

https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=680783

As this is only a beta release, the files are not available from PyPI,
and therefore not available with easy_install. However, you can
download the tar.gz file and pass it in to easy_install for testing
purposes. For example:

    easy_install Markdown-2.0.1-beta.tar.gz

If you used easy_install before, you probably want to install that way
using the `-U` option to force an upgrade. However, you may still need
to remove the old `markdown.py` script from your scripts dir.

Assuming this resolves the issues, I'll do a final release in the next
few weeks.

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] [python-markdown-2.0][patch] mardown.py can not be run

[Marco P. <mar...@gm...>]

I vote for "markdown-process" (without the ".py").

If you use setuptools, it should take care of everything.
Cheers,
Marco

On Wed, Apr 22, 2009 at 8:36 PM, Waylan Limberg <wa...@gm...> wrote:
> No, actually that's not a guaranteed fix - more of a hack which works
> in many cases but not all. This is the same as the other report we
> received. The only real fix is to rename markdown.py to something
> else. I'm going with "markdown" (no ".py") unless someone has a better
> suggestion.
>
> On Wed, Apr 22, 2009 at 2:18 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Should we perhaps just do this for all operating systems?
>>
>> - yuri
>>
>> On Sat, Apr 18, 2009 at 9:05 AM, solsTiCe d'Hiver
>> <sol...@gm...> wrote:
>>> hi.
>>> i upgraded to python-markdown.py and when i try to run markdown.py, i
>>> got this error
>>> $ markdown.py
>>> Traceback (most recent call last):
>>>  File "/usr/bin/markdown.py", line 44, in <module>
>>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>>>  File "/usr/bin/markdown.py", line 44, in <module>
>>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>>> ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL
>>>
>>> so the fix is to use the patch below ( i guess joined files are filtered
>>> in this ML ?)
>>> --- markdown.py 2009-04-18 17:58:57.000000000 +0200
>>> +++ markdown.py 2009-04-18 17:59:33.000000000 +0200
>>> @@ -30,10 +30,9 @@
>>>  """
>>>
>>>  import sys, os
>>> -if sys.platform == 'win32':
>>> +if sys.platform == 'win32' or sys.platform == 'linux2':
>>>         # We have to remove the Scripts dir from path on windows.
>>>         # If we don't, it will try to import itself rather than
>>> markdown lib.
>>> -        # This appears to *not* be a problem on *nix systems, only
>>> Windows.
>>>         try:
>>>             sys.path.remove(os.path.dirname(__file__))
>>>         except (ValueError, NameError):
>>>
>>> so obviously this appears to be a problem too for linux at least but i
>>> guess all the other *nix too.
>>>
>>> i use archlinux and python 2.6.1
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Stay on top of everything new and different, both inside and
>>> around Java (TM) technology - register by April 22, and save
>>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>>> 300 plus technical and hands-on sessions. Register today.
>>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>>> _______________________________________________
>>> Python-markdown-discuss mailing list
>>> Pyt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>>
>>
>>
>>
>> --
>> http://spu.tnik.org/
>>
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
Marco Pantaleoni

Re: [Python-markdown-discuss] [python-markdown-2.0][patch] mardown.py can not be run

[Waylan L. <wa...@gm...>]

No, actually that's not a guaranteed fix - more of a hack which works
in many cases but not all. This is the same as the other report we
received. The only real fix is to rename markdown.py to something
else. I'm going with "markdown" (no ".py") unless someone has a better
suggestion.

On Wed, Apr 22, 2009 at 2:18 PM, Yuri Takhteyev <qar...@gm...> wrote:
> Should we perhaps just do this for all operating systems?
>
> - yuri
>
> On Sat, Apr 18, 2009 at 9:05 AM, solsTiCe d'Hiver
> <sol...@gm...> wrote:
>> hi.
>> i upgraded to python-markdown.py and when i try to run markdown.py, i
>> got this error
>> $ markdown.py
>> Traceback (most recent call last):
>>  File "/usr/bin/markdown.py", line 44, in <module>
>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>>  File "/usr/bin/markdown.py", line 44, in <module>
>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>> ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL
>>
>> so the fix is to use the patch below ( i guess joined files are filtered
>> in this ML ?)
>> --- markdown.py 2009-04-18 17:58:57.000000000 +0200
>> +++ markdown.py 2009-04-18 17:59:33.000000000 +0200
>> @@ -30,10 +30,9 @@
>>  """
>>
>>  import sys, os
>> -if sys.platform == 'win32':
>> +if sys.platform == 'win32' or sys.platform == 'linux2':
>>         # We have to remove the Scripts dir from path on windows.
>>         # If we don't, it will try to import itself rather than
>> markdown lib.
>> -        # This appears to *not* be a problem on *nix systems, only
>> Windows.
>>         try:
>>             sys.path.remove(os.path.dirname(__file__))
>>         except (ValueError, NameError):
>>
>> so obviously this appears to be a problem too for linux at least but i
>> guess all the other *nix too.
>>
>> i use archlinux and python 2.6.1
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Stay on top of everything new and different, both inside and
>> around Java (TM) technology - register by April 22, and save
>> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
>> 300 plus technical and hands-on sessions. Register today.
>> Use priority code J9JMT32. http://p.sf.net/sfu/p
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> http://spu.tnik.org/
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] [python-markdown-2.0][patch] mardown.py can not be run

[Yuri T. <qar...@gm...>]

Should we perhaps just do this for all operating systems?

- yuri

On Sat, Apr 18, 2009 at 9:05 AM, solsTiCe d'Hiver
<sol...@gm...> wrote:
> hi.
> i upgraded to python-markdown.py and when i try to run markdown.py, i
> got this error
> $ markdown.py
> Traceback (most recent call last):
>  File "/usr/bin/markdown.py", line 44, in <module>
>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>  File "/usr/bin/markdown.py", line 44, in <module>
>    from markdown import COMMAND_LINE_LOGGING_LEVEL
> ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL
>
> so the fix is to use the patch below ( i guess joined files are filtered
> in this ML ?)
> --- markdown.py 2009-04-18 17:58:57.000000000 +0200
> +++ markdown.py 2009-04-18 17:59:33.000000000 +0200
> @@ -30,10 +30,9 @@
>  """
>
>  import sys, os
> -if sys.platform == 'win32':
> +if sys.platform == 'win32' or sys.platform == 'linux2':
>         # We have to remove the Scripts dir from path on windows.
>         # If we don't, it will try to import itself rather than
> markdown lib.
> -        # This appears to *not* be a problem on *nix systems, only
> Windows.
>         try:
>             sys.path.remove(os.path.dirname(__file__))
>         except (ValueError, NameError):
>
> so obviously this appears to be a problem too for linux at least but i
> guess all the other *nix too.
>
> i use archlinux and python 2.6.1
>
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://spu.tnik.org/

[Python-markdown-discuss] [python-markdown-2.0][patch] mardown.py can not be run

[solsTiCe d'H. <sol...@gm...>]

hi.
i upgraded to python-markdown.py and when i try to run markdown.py, i
got this error
$ markdown.py 
Traceback (most recent call last):
  File "/usr/bin/markdown.py", line 44, in <module>
    from markdown import COMMAND_LINE_LOGGING_LEVEL
  File "/usr/bin/markdown.py", line 44, in <module>
    from markdown import COMMAND_LINE_LOGGING_LEVEL
ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL

so the fix is to use the patch below ( i guess joined files are filtered
in this ML ?)
--- markdown.py	2009-04-18 17:58:57.000000000 +0200
+++ markdown.py	2009-04-18 17:59:33.000000000 +0200
@@ -30,10 +30,9 @@
 """
 
 import sys, os
-if sys.platform == 'win32':
+if sys.platform == 'win32' or sys.platform == 'linux2':
         # We have to remove the Scripts dir from path on windows.
         # If we don't, it will try to import itself rather than
markdown lib.
-        # This appears to *not* be a problem on *nix systems, only
Windows.
         try:
             sys.path.remove(os.path.dirname(__file__))
         except (ValueError, NameError):

so obviously this appears to be a problem too for linux at least but i
guess all the other *nix too.

i use archlinux and python 2.6.1

Re: [Python-markdown-discuss] installer gave problems due to installing markdown.py in /bin

[Waylan L. <wa...@gm...>]

On Wed, Apr 15, 2009 at 10:50 AM, Dirk van Oosterbosch, IR labs
<la...@ix...> wrote:
> Hi All,
>
> I updated my markdown (from an old version, when I was still running
> python 2.5 and mac 10.4) to the latest 2.0 release.
> But I ran into a problem when I tried to 'import markdown' from the
> interpreter:
>

Dirk, thanks for the detailed report. I ran into this problem the
other day [1]. Just haven't had time to fix it. It appears that the
problem relates to the way setuptools (and easy_install) installs
scripts. If you download the source and ``setup.py install`` the
problem doesn't exist AFAICT. I'd suggest removing your current
install and doing that until we can get a more permanent fix in place.

So, the fix is to rename the commandline script. The easiest choice is
to simply call it ``markdown`` (no .py) but then there's no indication
that its the python implementation. We could do ``pymarkdown``, but
I'm not crazy about that. Anyone have any suggestions?

I'm thinking that once we get this fix in, I'll release 2.0.1 as a
bug-fix release so we can avoid too many more people running into
this.

[1]: http://www.freewisdom.org/projects/python-markdown/Tickets/000028

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Python-markdown-discuss] installer gave problems due to installing markdown.py in /bin

[Dirk v. O. IR l. <la...@ix...>]

Hi All,

I updated my markdown (from an old version, when I was still running  
python 2.5 and mac 10.4) to the latest 2.0 release.
But I ran into a problem when I tried to 'import markdown' from the  
interpreter:

ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL

After a long hard search (my knowledge and understanding of how python  
modules, init files and the pythonpath work is rather limited), I  
found the culprit cause:
The installer (which runs through 'easy_install markdown', or through  
'sudo python setup.py install'), installs a command line version of  
markdown, called markdown.py in the bin.
On my mac it installs this command line version markdown.py in / 
Library/Frameworks/Python.framework/Versions/2.6/bin
On a freebsd machine it installs in in /usr/local/bin

The problem is that this bin directory is present in my sys.path as  
well as in my $PATH
The latter is obviously on purpose: the command line executable should  
be on my $PATH to be able to run it in the command line.
However, since that bin is also included in python's sys.path, my  
guess is that every attempt to 'import markdown' or 'from markdown  
import ...' will import that command line version, and not the  
__init__.py in the site-packages/markdown/
(I don't know why or how I could prevent this the inclusion of this  
bin in my sys.path)

My quick fix was to rename that command line version into something  
else or to move the markdown.py to somewhere where it can be found on  
the $PATH, but not in sys.path.

Just to report my findings.
And maybe somebody could improve the installer, explain me what I was  
doing wrong or update the installation documentation.

best
dirk





-- 
-----------------------------
Dirk van Oosterbosch
de Wittenstraat 225
1052 AT Amsterdam
the Netherlands

http://labs.ixopusada.com
-----------------------------
--

Re: [Python-markdown-discuss] Python-Markdown 2.0 Final Released!

[Yuri T. <qar...@gm...>]

> Yuri, the front page needs updating, but it's locked out to block
> spammers, so I can't edit it. While your at it, change the download
> link on that page to PyPI: <http://pypi.python.org/pypi/Markdown/2.0>

I made you admin, so you can edit it.

> Also, the available extensions page has some formatting issues. The
> wikilinks in a nested list aren't working. Looks like a bug in your
> wiki.

Yes, it's a bug. For now, I just broke the list into two to avoid the nesting.

Sorry I've been missing in action...

- yuri

-- 
http://spu.tnik.org/

Re: [Python-markdown-discuss] Python-Markdown 2 plugin for pyblosxom

[Waylan L. <wa...@gm...>]

Hey thanks tchomby!

I added the link to the integration page.

On Sat, Apr 11, 2009 at 11:29 AM, tchomby <tc...@go...> wrote:
> A plugin that integrates python-markdown 2 into the weblog system pyblosxom:
>
>    http://gist.github.com/93153
>
> Maybe add this to the integration page on the python-markdown site?
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Python-markdown-discuss] Python-Markdown 2 plugin for pyblosxom

[tchomby <tc...@go...>]

A plugin that integrates python-markdown 2 into the weblog system pyblosxom:

    http://gist.github.com/93153

Maybe add this to the integration page on the python-markdown site?

Re: [Python-markdown-discuss] Python-Markdown 2.0 Final Released!

[Waylan L. <wa...@gm...>]

On Mon, Apr 6, 2009 at 10:25 PM, Waylan Limberg <wa...@gm...> wrote:
> We have versions for Python 2.3-2.6 and Python 3.0!

So, I discovered that by having a copy of the Python3.0 version of
Markdown on PyPI, that was getting downloaded by easy_install even
when Python3.0 is not installed - so I removed it. It seems that the
correct way [1] is to only distribute the 2.x version of your code and
the end user runs 2to3 on it. As 2to3 runs without errors on markdown,
I guess we need to leave it to the user.

If anyone has tried installing via easy_install and got the wrong
version, you should try again. Sorry for the confusion.

[1]: http://mail.python.org/pipermail/python-dev/2008-March/077818.html

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] Python-Markdown 2.0 Final Released!

[Waylan L. <wa...@gm...>]

FYI, I just updated the wiki with all the 2.0 docs. Available
Extensions is probably the most interesting page:

http://www.freewisdom.org/projects/python-markdown/Available_Extensions

Yuri, the front page needs updating, but it's locked out to block
spammers, so I can't edit it. While your at it, change the download
link on that page to PyPI: <http://pypi.python.org/pypi/Markdown/2.0>

Also, the available extensions page has some formatting issues. The
wikilinks in a nested list aren't working. Looks like a bug in your
wiki.

On Mon, Apr 6, 2009 at 10:25 PM, Waylan Limberg <wa...@gm...> wrote:
> I am happy to announce the release of Python-Markdown 2.0 final. We
> have versions for Python 2.3-2.6 and Python 3.0!
>
> See the release notes here:
>
> https://sourceforge.net/project/shownotes.php?release_id=674043&group_id=153041
>
> Download from PyPI here:
>
> http://pypi.python.org/pypi/Markdown/2.0
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>



-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

[Python-markdown-discuss] Python-Markdown 2.0 Final Released!

[Waylan L. <wa...@gm...>]

I am happy to announce the release of Python-Markdown 2.0 final. We
have versions for Python 2.3-2.6 and Python 3.0!

See the release notes here:

https://sourceforge.net/project/shownotes.php?release_id=674043&group_id=153041

Download from PyPI here:

http://pypi.python.org/pypi/Markdown/2.0

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] Announcing Micro-wiki version 0.2

[Ron G. <ro...@fl...>]

Gents,

I've just released µWiki version 0.2.  The main change from 0.1 is  
that it now has revision control (based on Bazaar's merge3 code).   
Also, it no longer uses markdown.py (sorry guys).  All markdown-to- 
html conversion is now done in Javascript using Showdown.  This is so  
I don't have to maintain two parallel converters to support syntax  
extensions.

Comments and feedback are welcome.

rg


On Feb 21, 2009, at 10:27 AM, Ron Garret wrote:

> Gents,
>
> I've written a small experimental wiki called µWiki (pronounced  
> micro-wiki) that uses code that you've written: markdown.py,  
> showdown, Yaro and Selector.  The wiki itself is only about 100  
> LOC.  More information can be found here:
>
> http://www.flownet.com/ron/code/uwiki.html
>
> This is an alpha-test version.  Any comments, feedback or  
> suggestions any of you may have would be much appreciated.
>
> Thanks,
> Ron Garret
> ro...@fl...
>

Re: [Python-markdown-discuss] python markdown line breaks with 80-char wrapped text don't make sense with hanging paragraphs

[alec r. <al...@sp...>]

Oh wow; awesome!  Thanks for the update--sorry I didn't find out that
this was already known and fixed, earlier.

Thanks for your time.


Looking forward to Monday,
a.


On Wed, Apr 1, 2009 at 10:30 PM, Waylan Limberg <wa...@gm...> wrote:
> Hi Alec. Thanks for the report. I'm assuming your using
> Python-Markdown 1.7. However, this bug has already been fixed and will
> be available in the next release (2.0) which will most likely be
> available on Monday. Yes, this coming Monday, April 6. If I have the
> time, it might even come on Sunday night. Watch this list for the
> announcement or at http://twitter.com/WaylanL
>
> For the record, I broke your example down into the simplest broken test case:
>
>    - A list item [with]()
>      [hanging]() indent.
>
> See here for a comparison:
>
> http://babelmark.bobtfish.net/?markdown=-+A+list+item+[with]()%0D%0A++[hanging]()+indent.
>
> The key to problem is that the hard line break only occurs when the
> first line ends with a link *and* the second line begins with one.
> Actually, most any inline markup will do it (italics, bold, etc).
> Given how inline patterns used to work, this makes sense (sort of).
> However, in 2.0 that code has been completely refactored and works
> very differently. We've eliminated a lot (hopefully all) of these edge
> cases.
>
> On Wed, Apr 1, 2009 at 7:41 PM, alec resnick <al...@sp...> wrote:
>> Hi!  I recently ran into this problem while using the
>> django.contrib.markup addon, and it turns out that the issue (I think)
>> is with Python Markdown.
>>
>> With the original text of:
>> """
>> - *bench space* :: Our [space](http://sproutward.org/greenhouse) and
>>  [equipment]() are available for use by individuals and groups. If
>>  you or your friends (or your research partners or your classmates or
>>  your children) want to figure out a way to make a project of yours
>>  happen at sprout--[let's see how we can make it
>>  happen](mailto:sp...@sp...).
>> """
>> python markdown inserts a line break after the first and, instead of
>> where the line break would make sense, in this case.  Dingus
>> (http://daringfireball.net/projects/markdown/dingus) does not have
>> this issue.  Refer to the bug listing at django (
>> http://code.djangoproject.com/ticket/10685 ) for details, or let me
>> know if I should refile a separate bug report through this mailing
>> list.
>>
>> Thanks!
>>
>> -a.
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>

Re: [Python-markdown-discuss] python markdown line breaks with 80-char wrapped text don't make sense with hanging paragraphs

[alec r. <al...@sp...>]

Yep, on a webpage, it's inserted as a hard break.  If you have a link
on the first line of an item, for example, the line breaks much
earlier than you anticipate (since the 80 char wrapping includes the
URI text).  Ideally, I'd like the output to be that of Dingus (that
is, without the line breaks)

-a.


On Wed, Apr 1, 2009 at 8:51 PM, Yuri Takhteyev <qar...@gm...> wrote:
> Does this cause any problems?
>
>  - yuri
>
> On Wed, Apr 1, 2009 at 4:41 PM, alec resnick <al...@sp...> wrote:
>> Hi!  I recently ran into this problem while using the
>> django.contrib.markup addon, and it turns out that the issue (I think)
>> is with Python Markdown.
>>
>> With the original text of:
>> """
>> - *bench space* :: Our [space](http://sproutward.org/greenhouse) and
>>  [equipment]() are available for use by individuals and groups. If
>>  you or your friends (or your research partners or your classmates or
>>  your children) want to figure out a way to make a project of yours
>>  happen at sprout--[let's see how we can make it
>>  happen](mailto:sp...@sp...).
>> """
>> python markdown inserts a line break after the first and, instead of
>> where the line break would make sense, in this case.  Dingus
>> (http://daringfireball.net/projects/markdown/dingus) does not have
>> this issue.  Refer to the bug listing at django (
>> http://code.djangoproject.com/ticket/10685 ) for details, or let me
>> know if I should refile a separate bug report through this mailing
>> list.
>>
>> Thanks!
>>
>> -a.
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> http://spu.tnik.org/
>

Re: [Python-markdown-discuss] python markdown line breaks with 80-char wrapped text don't make sense with hanging paragraphs

[Waylan L. <wa...@gm...>]

Hi Alec. Thanks for the report. I'm assuming your using
Python-Markdown 1.7. However, this bug has already been fixed and will
be available in the next release (2.0) which will most likely be
available on Monday. Yes, this coming Monday, April 6. If I have the
time, it might even come on Sunday night. Watch this list for the
announcement or at http://twitter.com/WaylanL

For the record, I broke your example down into the simplest broken test case:

    - A list item [with]()
      [hanging]() indent.

See here for a comparison:

http://babelmark.bobtfish.net/?markdown=-+A+list+item+[with]()%0D%0A++[hanging]()+indent.

The key to problem is that the hard line break only occurs when the
first line ends with a link *and* the second line begins with one.
Actually, most any inline markup will do it (italics, bold, etc).
Given how inline patterns used to work, this makes sense (sort of).
However, in 2.0 that code has been completely refactored and works
very differently. We've eliminated a lot (hopefully all) of these edge
cases.

On Wed, Apr 1, 2009 at 7:41 PM, alec resnick <al...@sp...> wrote:
> Hi!  I recently ran into this problem while using the
> django.contrib.markup addon, and it turns out that the issue (I think)
> is with Python Markdown.
>
> With the original text of:
> """
> - *bench space* :: Our [space](http://sproutward.org/greenhouse) and
>  [equipment]() are available for use by individuals and groups. If
>  you or your friends (or your research partners or your classmates or
>  your children) want to figure out a way to make a project of yours
>  happen at sprout--[let's see how we can make it
>  happen](mailto:sp...@sp...).
> """
> python markdown inserts a line break after the first and, instead of
> where the line break would make sense, in this case.  Dingus
> (http://daringfireball.net/projects/markdown/dingus) does not have
> this issue.  Refer to the bug listing at django (
> http://code.djangoproject.com/ticket/10685 ) for details, or let me
> know if I should refile a separate bug report through this mailing
> list.
>
> Thanks!
>
> -a.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] python markdown line breaks with 80-char wrapped text don't make sense with hanging paragraphs

[Yuri T. <qar...@gm...>]

Does this cause any problems?

  - yuri

On Wed, Apr 1, 2009 at 4:41 PM, alec resnick <al...@sp...> wrote:
> Hi!  I recently ran into this problem while using the
> django.contrib.markup addon, and it turns out that the issue (I think)
> is with Python Markdown.
>
> With the original text of:
> """
> - *bench space* :: Our [space](http://sproutward.org/greenhouse) and
>  [equipment]() are available for use by individuals and groups. If
>  you or your friends (or your research partners or your classmates or
>  your children) want to figure out a way to make a project of yours
>  happen at sprout--[let's see how we can make it
>  happen](mailto:sp...@sp...).
> """
> python markdown inserts a line break after the first and, instead of
> where the line break would make sense, in this case.  Dingus
> (http://daringfireball.net/projects/markdown/dingus) does not have
> this issue.  Refer to the bug listing at django (
> http://code.djangoproject.com/ticket/10685 ) for details, or let me
> know if I should refile a separate bug report through this mailing
> list.
>
> Thanks!
>
> -a.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://spu.tnik.org/

[Python-markdown-discuss] python markdown line breaks with 80-char wrapped text don't make sense with hanging paragraphs

[alec r. <al...@sp...>]

Hi!  I recently ran into this problem while using the
django.contrib.markup addon, and it turns out that the issue (I think)
is with Python Markdown.

With the original text of:
"""
- *bench space* :: Our [space](http://sproutward.org/greenhouse) and
  [equipment]() are available for use by individuals and groups. If
  you or your friends (or your research partners or your classmates or
  your children) want to figure out a way to make a project of yours
  happen at sprout--[let's see how we can make it
  happen](mailto:sp...@sp...).
"""
python markdown inserts a line break after the first and, instead of
where the line break would make sense, in this case.  Dingus
(http://daringfireball.net/projects/markdown/dingus) does not have
this issue.  Refer to the bug listing at django (
http://code.djangoproject.com/ticket/10685 ) for details, or let me
know if I should refile a separate bug report through this mailing
list.

Thanks!

-a.

Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Waylan L. <wa...@gm...>]

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

Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Waylan L. <wa...@gm...>]

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

Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Ron G. <ro...@fl...>]

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

[Python-markdown-discuss] Python-Markdown 2.0 Release Candidate 2

[Waylan L. <wa...@gm...>]

FYI, I just did another RC [1]. This one includes a Python3.0 version
as well. I would appreciate some testing. Especially that things
worked right for 3.0. And, am I naming the 3.0 file correctly?

[1]: https://sourceforge.net/project/showfiles.php?group_id=153041&package_id=183331&release_id=670491

Thanks.

On Mon, Mar 23, 2009 at 3:00 PM, Waylan Limberg <wa...@gm...> wrote:
> 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.
>



-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Waylan L. <wa...@gm...>]

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

Re: [Python-markdown-discuss] Python-Markdown 2.0 Release Candidate

[Ron G. <ron...@gm...>]

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