python-markdown-discuss

[Python-markdown-discuss] Codehilite extension places code at the start of the document

[Kjell M. F. <kj...@gm...>]

Dear Python-markdown developers,

I have been playing with the development version of Markdown recently
and I love it. There are, however, a few bugs in the mainline version:

1. Converting an empty string raises an exception:

>>> import markdown
>>> markdown.markdown('')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "d:\python25\lib\site-packages\markdown-2.0_alpha2-py2.5.egg\markdown.py"
, line 2059, in markdown
    return md.convert(text)
  File "d:\python25\lib\site-packages\markdown-2.0_alpha2-py2.5.egg\markdown.py"
, line 1939, in convert
    root = self.applyInlinePatterns(tree).getroot()
  File "d:\python25\lib\site-packages\markdown-2.0_alpha2-py2.5.egg\markdown.py"
, line 1843, in applyInlinePatterns
    el = markdownTree.getroot()
AttributeError: 'unicode' object has no attribute 'getroot'

A workaround is to call markdown like this:

markdown.markdown(inputdata or " ")

to ensure that an empty string is not used.

2. The codehilite extension is broken. The code snippets are inserted
at the start of the document. This bug is triggered by markdown's test
suite, so you are probably aware of this one (the codehilite test was
uncommented in the main test file).

3. When converting a code block a newline and several spaces are
inserted between the <pre> and <code> tag:

In [6]: text = """This is a normal paragraph:
   ...:
   ...:     This is a code block.
   ...: """

In [7]: markdown.markdown(text)
Out[7]: u'<p>This is a normal paragraph:</p>\n<pre>\n  <code>This is a code bloc
k.\n</code>\n</pre>'

The extra spaces give visual results in the output. According to the
Markdown syntax spec. the correct markup should be:
<p>This is a normal paragraph:</p>

<pre><code>This is a code block.
</code></pre>


Thank you for the work you have put into Python Markdown! I will
submit some tickets with bug reports tomorrow if you prefer that.

Regards,
Kjell Magne Fauske

Re: [Python-markdown-discuss] Codehilite extension places code at the start of the document

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

On Thu, Aug 21, 2008 at 3:58 PM, Kjell Magne Fauske <kj...@gm...> wrote:
> Dear Python-markdown developers,
>
> I have been playing with the development version of Markdown recently
> and I love it.

Glad to hear.

> There are, however, a few bugs in the mainline version:

Thanks for the reports Kjell. If you don't mind doing so, bug reports
in the tracker would be helpful. That way we won't lose track of them.

>
> 1. Converting an empty string raises an exception:
>

Hmm, I thought we had addressed this before, but maybe that was `None`
rather than an empty string. Anyway, this used to work before the
conversion to ElementTree. Unfortunately, the current testing
framework doesn't provide a way to test this one. Just another
reminder that we need some UnitTests to ensure we don't break the API
or this sort of thing.

[snip]
>
> 2. The codehilite extension is broken. The code snippets are inserted
> at the start of the document. This bug is triggered by markdown's test
> suite, so you are probably aware of this one (the codehilite test was
> uncommented in the main test file).
>
> 3. When converting a code block a newline and several spaces are
> inserted between the <pre> and <code> tag:
>

After Artem updated the extensions to use ElementTree I thought a few
things looked strange in the CodeHilite extension, but I haven't had a
change to look closely yet. Actually, because of some recent changes
to Markdown, I'm thinking that extension could be doing things a
little different than it used to. It's on my todo list.


-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Codehilite extension places code at the start of the document

[Kjell M. F. <kj...@gm...>]

On Thu, Aug 21, 2008 at 10:29 PM, Waylan Limberg <wa...@gm...> wrote:
> On Thu, Aug 21, 2008 at 3:58 PM, Kjell Magne Fauske <kj...@gm...> wrote:
>> Dear Python-markdown developers,
>>
>> I have been playing with the development version of Markdown recently
>> and I love it.
>
> Glad to hear.
>
>> There are, however, a few bugs in the mainline version:
>
> Thanks for the reports Kjell. If you don't mind doing so, bug reports
> in the tracker would be helpful. That way we won't lose track of them.
>

I have now added the bugs to the tracker:
http://www.freewisdom.org/projects/python-markdown/Tickets

Thank you all for the prompt replies. I'm looking forward to the next release.

Regards,
Kjell Magne Fauske

Re: [Python-markdown-discuss] Codehilite extension places code at the start of the document

[Artem Y. <ne...@gm...>]

Kjell Magne Fauske wrote:
> Dear Python-markdown developers,
>
> I have been playing with the development version of Markdown recently
> and I love it. There are, however, a few bugs in the mainline version:
>   

Thanks  :)

> 1. Converting an empty string raises an exception:
>   

Fixed it :)

>
> 2. The codehilite extension is broken. The code snippets are inserted
> at the start of the document. This bug is triggered by markdown's test
> suite, so you are probably aware of this one (the codehilite test was
> uncommented in the main test file).
>
> 3. When converting a code block a newline and several spaces are
> inserted between the <pre> and <code> tag:
>   

It's because in indentation function we process all nodes in same way,  
I'll try to fix it, and we also will need to update tests after this.

Re: [Python-markdown-discuss] Codehilite extension places code at the start of the document

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

On Thu, Aug 21, 2008 at 5:26 PM, Artem Yunusov <ne...@gm...> wrote:
> Kjell Magne Fauske wrote:
>>
>> 1. Converting an empty string raises an exception:
>>
>
> Fixed it :)

Except you brought back the old problem. I remember what it was now:

In [1]: md.convert(None)

Out[1]: u''

In [2]: md.convert('foo')

Out[2]: u'<p>foo</p>'

In [3]: md.convert(None)

Out[3]: u'<p>foo</p>'

Obviously, that last one is wrong. Of course, the reason is that we
are using the same instance for each, but that's the point - we want
to support that usecase. That's why I need to write some UnitTests -
or at least some doctests.



-- 
----
Waylan Limberg
wa...@gm...