python-markdown-discuss — A general purpose discussion list

[Python-markdown-discuss] validating syntax of user input

[gordon p. <wgo...@gm...>]

Hi,

I am adding the Markdown markup language as an option for user input into my
web app.  I need to be able to validate the syntax of user submitted content
to ensure the markup will render properly before accepting the submission.
How can I verify that the input contains valid Markdown syntax?  I did not
see any error reporting mechanisms I could hook into in the code.  How
should I go about this?

Thanks,
Gordon

[Python-markdown-discuss] New bug tracker

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

Just letting everyone know that we are no longer using the bug tracker
at freewisdom.org. Instead, we will be using my Github repo [1] which
means that the official repo will now be on Github rather than
gitorious. Yuri and I have made this decision together for various
reasons.

The wiki on freewisdom.org has been updated to point to Github as
well. All open tickets on freewisdom.org have been closed with a note
pointing to their counterpart which I opened on github. Please address
any comments to those existing tickets on Github.

[1]: https://github.com/waylan/Python-Markdown/issues

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

Re: [Python-markdown-discuss] Support for custom start index for `ol` (merge request)

[Rohan J. <cr...@gm...>]

>
> Thanks Rohan. I made a few comment son the request page. Address those
> issues and I'll merge your request.
>

I fixed the issues you pointed out. The details are here:
https://gitorious.org/python-markdown/mainline/merge_requests/13#comment_49335

But I do have a question for everyone: Should this be a configurable
> setting, perhaps on the Markdown class? In other words, should we make
> it easy to turn on and off?


I am not sure that an additional setting could be of that much of use.

Rohan Jain <http://www.rohanjain.in/>
Web and Software Developer

Re: [Python-markdown-discuss] Support for custom start index for `ol` (merge request)

[Gerry L. <gjl...@gm...>]

On Sun, Apr 03, 2011 at 10:10:05PM -0400, Waylan Limberg wrote:
> Thanks Rohan. I made a few comment son the request page. Address those
> issues and I'll merge your request.
> 
> But I do have a question for everyone: Should this be a configurable
> setting, perhaps on the Markdown class? In other words, should we make
> it easy to turn on and off?
> 
> On Sun, Apr 3, 2011 at 11:41 AM, Rohan Jain <cr...@gm...> wrote:
> > The definition of ordered list
> > on http://daringfireball.net/projects/markdown/syntax
> > says that the list starting with a number different from `1` can, in future,
> > define the
> > starting index of the unordered list (search for `3. Bird` on the page).
> > So I wrote a patch for doing this. Here is the merge request:
> > https://gitorious.org/python-markdown/mainline/merge_requests/13

That approach seems eminently reasonable.  I'd say default it to 'OFF'
for backwards compatibility purposes; otherwise, someone somewhere will
trip over it.  I assume it would be a command line option as well?

Regards-
Gerry

Re: [Python-markdown-discuss] Support for custom start index for `ol` (merge request)

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

Thanks Rohan. I made a few comment son the request page. Address those
issues and I'll merge your request.

But I do have a question for everyone: Should this be a configurable
setting, perhaps on the Markdown class? In other words, should we make
it easy to turn on and off?

On Sun, Apr 3, 2011 at 11:41 AM, Rohan Jain <cr...@gm...> wrote:
> The definition of ordered list
> on http://daringfireball.net/projects/markdown/syntax
> says that the list starting with a number different from `1` can, in future,
> define the
> starting index of the unordered list (search for `3. Bird` on the page).
> So I wrote a patch for doing this. Here is the merge request:
> https://gitorious.org/python-markdown/mainline/merge_requests/13
>
> Rohan Jain
> Web and Software Developer
>
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
>
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



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

[Python-markdown-discuss] Support for custom start index for `ol` (merge request)

[Rohan J. <cr...@gm...>]

The definition of ordered list on
http://daringfireball.net/projects/markdown/syntax
says that the list starting with a number different from `1` can, in future,
define the
starting index of the unordered list (search for `3. Bird` on the page).
So I wrote a patch for doing this. Here is the merge request:
https://gitorious.org/python-markdown/mainline/merge_requests/13

<https://gitorious.org/python-markdown/mainline/merge_requests/13>Rohan
Jain<http://www.rohanjain.in/>
Web and Software Developer

Re: [Python-markdown-discuss] Ticket 81

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

Hmm, I see there are a bunch of open tickets. I never got notice of
any of them. Nope, no idea what that ticket is about.

Yuri, any idea why any ticket edits in the last couple months didn't
show up in the rss feed?

Waylan

On Sat, Mar 5, 2011 at 11:03 AM, Gerry LaMontagne <gjl...@gm...> wrote:
> The link for this ticket appears to be broken...  Any other examples of
> the bug in question?
>
> Regards-
> Gerry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iF4EAREIAAYFAk1yXu4ACgkQuZVaBQlJuPH0LAD+IMz17UcKVfQl7VeqZNbfOfdc
> WOdZb3wv27RcZl4z+c0A/ibhqOJS3DUxqR+Se6y4fc4ZgKEJW1ZZ/M9xVERDtWqh
> =05Rt
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



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

[Python-markdown-discuss] Ticket 81

[Gerry L. <gjl...@gm...>]

The link for this ticket appears to be broken...  Any other examples of
the bug in question?

Regards-
Gerry

Re: [Python-markdown-discuss] Linebreaks within paragraph handling (GitHub Flavored Markdown)

[Brian N. <bg...@gm...>]

Hi Waylan,

On Wed, Mar 2, 2011 at 11:24 AM, Waylan Limberg <wa...@gm...> wrote:
> Brian,
>
> Glad you have found Python-Markdown useful.  Of course, we try to
> support Markdown as close as possible, so we won't be implementing
> your request as a built in feature. In fact, for those of us who
> prefer command line text editors (vim or emacs) Markdown's default
> behavior with line breaks makes much more sense. However, in a web
> form, I can see the value in making all line breaks hard.

I completely understand that; I was thinking of writing it as an
extension. I've found the urlize extension that your wiki links too,
and with these two tweaks, I think Markdown will be perfect for my web
site users.

>
> This would be a super simple extension. I'm not aware that one already
> exists, but you could easily replace the current line break inline
> pattern with your own. In fact, you'd really only need to write the
> appropriate regex and pass it in using our extension API. See the docs
> for all the details [1].  Given the simplicity of something like this,
> my tutorials [2] [3] might be more helpful. If you need any help, feel
> free to ask.

I have been studying your blog posts and the Wiki page on writing
extensions. I was concerned that a simple inline pattern would break
too many things. For example, could this mess up a code block? I don't
think you want to blindly replace all newlines with <br /> tags do
you? If so, would writing a tree processor that looked for <p>
elements and did the hard breaking inside there be better?

Thanks for any advice. If you think an inline pattern will do the
trick without being heavy handed and stomping on other blocks I'll try
that. I really appreciate how python markdown has been designed with
these nice extension points.

>
> And when you have a working extension, please post a link to it on our
> wiki [4] so others may use it.

Definitely. Thanks.

BN

Re: [Python-markdown-discuss] Linebreaks within paragraph handling (GitHub Flavored Markdown)

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

Brian,

Glad you have found Python-Markdown useful.  Of course, we try to
support Markdown as close as possible, so we won't be implementing
your request as a built in feature. In fact, for those of us who
prefer command line text editors (vim or emacs) Markdown's default
behavior with line breaks makes much more sense. However, in a web
form, I can see the value in making all line breaks hard.

This would be a super simple extension. I'm not aware that one already
exists, but you could easily replace the current line break inline
pattern with your own. In fact, you'd really only need to write the
appropriate regex and pass it in using our extension API. See the docs
for all the details [1].  Given the simplicity of something like this,
my tutorials [2] [3] might be more helpful. If you need any help, feel
free to ask.

And when you have a working extension, please post a link to it on our
wiki [4] so others may use it.

[1]: http://www.freewisdom.org/projects/python-markdown/Writing_Extensions
[2]: http://achinghead.com/archive/86/python-markdown-adding-insert-delete/
[3]: http://achinghead.com/archive/87/python-markdown-changing-bold-italics/
[4]: http://www.freewisdom.org/projects/python-markdown/Available_Extensions

On Tue, Mar 1, 2011 at 4:50 PM, Brian Neal <bg...@gm...> wrote:
> Hi -
>
> First of all, thanks for your great work on this package. It is really useful.
>
> My users are easily confused and get tripped up by the way Markdown
> does not insert a <br /> tag when it encounters a newline in a
> paragraph-like construct. So I'm searching for a way to implement this
> behavior, just like StackOverflow and GitHub Flavored Markdown do:
> http://github.github.com/github-flavored-markdown/
>
> Has this been done by anyone before? If not, what is the best way to
> do this, as an extension? Any pointers on how to best do that? As a
> preprocessor or tree extension?
>
> Or is there already a Python implementation of GitHub flavored Markdown?
>
> Thanks,
> BN
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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

Re: [Python-markdown-discuss] Linebreaks within paragraph handling (GitHub Flavored Markdown)

[Gerry L. <gjl...@gm...>]

Standard markdown will insert the <br /> if a line is terminated with a
double space-CR sequence.  In other words, "<space><space><CR>" at the
end of a line.  Don't know if that's useful or not.

Otherwise, paragraphs are handled as a blockparser, you might look at
writing an extension to replace the processing done in the
ParagraphProcessor class.

Regards-
Gerry

On Tue, Mar 01, 2011 at 03:50:36PM -0600, Brian Neal wrote:
> Hi -
> 
> First of all, thanks for your great work on this package. It is really useful.
> 
> My users are easily confused and get tripped up by the way Markdown
> does not insert a <br /> tag when it encounters a newline in a
> paragraph-like construct. So I'm searching for a way to implement this
> behavior, just like StackOverflow and GitHub Flavored Markdown do:
> http://github.github.com/github-flavored-markdown/
> 
> Has this been done by anyone before? If not, what is the best way to
> do this, as an extension? Any pointers on how to best do that? As a
> preprocessor or tree extension?
> 
> Or is there already a Python implementation of GitHub flavored Markdown?
> 
> Thanks,
> BN
> 
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in 
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business 
> insights. http://p.sf.net/sfu/splunk-dev2dev 
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> 

[Python-markdown-discuss] Linebreaks within paragraph handling (GitHub Flavored Markdown)

[Brian N. <bg...@gm...>]

Hi -

First of all, thanks for your great work on this package. It is really useful.

My users are easily confused and get tripped up by the way Markdown
does not insert a <br /> tag when it encounters a newline in a
paragraph-like construct. So I'm searching for a way to implement this
behavior, just like StackOverflow and GitHub Flavored Markdown do:
http://github.github.com/github-flavored-markdown/

Has this been done by anyone before? If not, what is the best way to
do this, as an extension? Any pointers on how to best do that? As a
preprocessor or tree extension?

Or is there already a Python implementation of GitHub flavored Markdown?

Thanks,
BN

Re: [Python-markdown-discuss] Ticket 80

[Dmitry T. <dty...@gm...>]

> Which means when using
> cElementTree, we need both cElementTree.Comment and
> ElementTree.Comment available. Crazy!

:-)

> Personally, I consider this a bug in cElementTree (it works with the
> builtin serializers because cElementTree actually uses ElementTree's
> serializers and they test again ElementTree.Comment) as it makes it
> ridiculously difficult to test for comment nodes in our own code when
> we are supporting both ElementTree and cElementTree at the same time.

I agree with you. It "defeats the purpose of cElementTree in the first place".

> However, given the current rate of ElementTree's development right
> now, I would expect that a fix would take a long time to propagate to
> all our users, so I've just committed what should be a working
> workaround.

Thanks, now I can remove my workarounds.

> Please let me know if you run into any problems with it.

No problems discovered.

Re: [Python-markdown-discuss] Ticket 80

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

After a little more testing, I have committed this. The good news is I
have added tests, so while we don't use comments within markdown
itself, we shouldn't break this in the future. Thanks for the report.
The latest is available via git.

On Fri, Oct 29, 2010 at 11:06 AM, Waylan Limberg <wa...@gm...> wrote:
> Ok, I think I have a working patch for this. I've attached a diff.
> Dimitry, any possibility you could test this against your code before
> I commit it?
>
> On Mon, Oct 18, 2010 at 4:40 AM, Dmitry Tyschenko <dty...@gm...> wrote:
>>> At first I was a little confused by your report as we don't do
>>> anything with comments - if they exist in the source they are pulled
>>> out as rawhtml and never see ElementTree.  Then I realized you must be
>>> using a third party extension which create html comments and inserts
>>> them into the tree. That is certainly something we want to support and
>>> allow you to do.
>>
>> I'm writing my own. You know this annoying bug in one popular browser,
>> when empty block height will be not zero until you put some content
>> inside, even if this content is comment.
>>
>>> However, it appears you are also using the html4 serializer - which we
>>> borrowed (with permission) from the ElementTree 1.3 Preview (still in
>>> alpha since 2007 AFAICT). Any changes to that serializer would ideally
>>> be changes made upstream as well.
>>
>>> In fact, your proposed fix, to also import parts of ElementTree when
>>> using cElementTree feels wrong and defeats the purpose of cElementTree
>>> in the first place. In fact, I see in the notes to ElementTree 1.3
>>> there is a note [3] that it only works with  cElementTree 1.0.6 or
>>> later. What version are you using?
>>
>> 1.0.6
>>
>> It's not mine idea to import ElementTree.Comment, that is what
>> cElementTree is doing.
>>
>> Problem is in checking that node is Comment. There is no such thing as
>> nodeType like in DOM. So ElementTree putting into tag field link to
>> ElementTree.Comment function and then making conditions like:
>>
>> if node.tag is ElementTree.Comment:
>>
>> Even if node was created using cElementTree implementation node.tag
>> will point to ElementTree.Comment. That is why i was thinking that
>> ElementTree.Comment implementation is called inside. If you look at
>> ElementTree.Comment you'll see why node.tag is ElementTree.Comment:
>>
>> def Comment(text=None):
>>    element = Element(Comment)
>>    element.text = text
>>    return element
>>
>>> Hmm, now I'm looking at the code and all isBlockLevel does it take a
>>> tag, which is a string. Perhaps elsewhere in the code, we are assuming
>>> every ElementTree element has a tag and that is where the exception is
>>> being raised. Like in markdown.treeprocessors.PrettifyTreeprocessor.
>>> Should we be checking that an element has a tag first and behave
>>> differently if not?
>>
>> As you now know node.tag isn't always a string, it can be function! So
>> isBlockLevel is raising TypeError exception.
>>
>> So to fix these bugs the question should be answered: what is the
>> propper way to check that node is Comment?
>>
>
>
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>



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

Re: [Python-markdown-discuss] Python markdown on Pypi

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

Italo,

We know. Pypi will be updated when we do another release. That won't
happen at least until we have fixed all the known bugs. There may be a
few other things I want to do as well, we'll see what happens there.

If you what the updates now, I suggest running the most recent code on
gitorious. Pip [1] even makes it easy to install.

[1]: http://pypi.python.org/pypi/pip

2010/10/29 Italo Maia <ita...@gm...>:
> Python markdown needs a update in pypi. Some important stuff like unicode
> for wikilinks is missing in the package there.
>
> --
> "A arrogância é a arma dos fracos."
>
> ===========================
> Italo Moreira Campelo Maia
> Graduado em Ciência da Computação - UECE
> Desenvolvedor WEB e Desktop (Java, Python, Lua)
> Coordenador do Pug-CE
> -----------------------------------------------------
> http://www.italomaia.com/
> http://twitter.com/italomaia/
> http://eusouolobomau.blogspot.com/
> -----------------------------------------------------
> turtle linux 910 - http://tiny.cc/blogturtle910
> ===========================
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



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

[Python-markdown-discuss] Python markdown on Pypi

[Italo M. <ita...@gm...>]

Python markdown needs a update in pypi. Some important stuff like unicode
for wikilinks is missing in the package there.

-- 
"A arrogância é a arma dos fracos."

===========================
Italo Moreira Campelo Maia
Graduado em Ciência da Computação - UECE
Desenvolvedor WEB e Desktop (Java, Python, Lua)
Coordenador do Pug-CE
-----------------------------------------------------
http://www.italomaia.com/
http://twitter.com/italomaia/
http://eusouolobomau.blogspot.com/
-----------------------------------------------------
turtle linux 910 - http://tiny.cc/blogturtle910
===========================

Re: [Python-markdown-discuss] Ticket 80

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

Ok, I think I have a working patch for this. I've attached a diff.
Dimitry, any possibility you could test this against your code before
I commit it?

On Mon, Oct 18, 2010 at 4:40 AM, Dmitry Tyschenko <dty...@gm...> wrote:
>> At first I was a little confused by your report as we don't do
>> anything with comments - if they exist in the source they are pulled
>> out as rawhtml and never see ElementTree.  Then I realized you must be
>> using a third party extension which create html comments and inserts
>> them into the tree. That is certainly something we want to support and
>> allow you to do.
>
> I'm writing my own. You know this annoying bug in one popular browser,
> when empty block height will be not zero until you put some content
> inside, even if this content is comment.
>
>> However, it appears you are also using the html4 serializer - which we
>> borrowed (with permission) from the ElementTree 1.3 Preview (still in
>> alpha since 2007 AFAICT). Any changes to that serializer would ideally
>> be changes made upstream as well.
>
>> In fact, your proposed fix, to also import parts of ElementTree when
>> using cElementTree feels wrong and defeats the purpose of cElementTree
>> in the first place. In fact, I see in the notes to ElementTree 1.3
>> there is a note [3] that it only works with  cElementTree 1.0.6 or
>> later. What version are you using?
>
> 1.0.6
>
> It's not mine idea to import ElementTree.Comment, that is what
> cElementTree is doing.
>
> Problem is in checking that node is Comment. There is no such thing as
> nodeType like in DOM. So ElementTree putting into tag field link to
> ElementTree.Comment function and then making conditions like:
>
> if node.tag is ElementTree.Comment:
>
> Even if node was created using cElementTree implementation node.tag
> will point to ElementTree.Comment. That is why i was thinking that
> ElementTree.Comment implementation is called inside. If you look at
> ElementTree.Comment you'll see why node.tag is ElementTree.Comment:
>
> def Comment(text=None):
>    element = Element(Comment)
>    element.text = text
>    return element
>
>> Hmm, now I'm looking at the code and all isBlockLevel does it take a
>> tag, which is a string. Perhaps elsewhere in the code, we are assuming
>> every ElementTree element has a tag and that is where the exception is
>> being raised. Like in markdown.treeprocessors.PrettifyTreeprocessor.
>> Should we be checking that an element has a tag first and behave
>> differently if not?
>
> As you now know node.tag isn't always a string, it can be function! So
> isBlockLevel is raising TypeError exception.
>
> So to fix these bugs the question should be answered: what is the
> propper way to check that node is Comment?
>



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

Re: [Python-markdown-discuss] Ticket 80

[Dmitry T. <dty...@gm...>]

> At first I was a little confused by your report as we don't do
> anything with comments - if they exist in the source they are pulled
> out as rawhtml and never see ElementTree.  Then I realized you must be
> using a third party extension which create html comments and inserts
> them into the tree. That is certainly something we want to support and
> allow you to do.

I'm writing my own. You know this annoying bug in one popular browser,
when empty block height will be not zero until you put some content
inside, even if this content is comment.

> However, it appears you are also using the html4 serializer - which we
> borrowed (with permission) from the ElementTree 1.3 Preview (still in
> alpha since 2007 AFAICT). Any changes to that serializer would ideally
> be changes made upstream as well.

> In fact, your proposed fix, to also import parts of ElementTree when
> using cElementTree feels wrong and defeats the purpose of cElementTree
> in the first place. In fact, I see in the notes to ElementTree 1.3
> there is a note [3] that it only works with  cElementTree 1.0.6 or
> later. What version are you using?

1.0.6

It's not mine idea to import ElementTree.Comment, that is what
cElementTree is doing.

Problem is in checking that node is Comment. There is no such thing as
nodeType like in DOM. So ElementTree putting into tag field link to
ElementTree.Comment function and then making conditions like:

if node.tag is ElementTree.Comment:

Even if node was created using cElementTree implementation node.tag
will point to ElementTree.Comment. That is why i was thinking that
ElementTree.Comment implementation is called inside. If you look at
ElementTree.Comment you'll see why node.tag is ElementTree.Comment:

def Comment(text=None):
    element = Element(Comment)
    element.text = text
    return element

> Hmm, now I'm looking at the code and all isBlockLevel does it take a
> tag, which is a string. Perhaps elsewhere in the code, we are assuming
> every ElementTree element has a tag and that is where the exception is
> being raised. Like in markdown.treeprocessors.PrettifyTreeprocessor.
> Should we be checking that an element has a tag first and behave
> differently if not?

As you now know node.tag isn't always a string, it can be function! So
isBlockLevel is raising TypeError exception.

So to fix these bugs the question should be answered: what is the
propper way to check that node is Comment?

Re: [Python-markdown-discuss] Ticket 80

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

On Sun, Oct 17, 2010 at 11:11 AM, Waylan Limberg <wa...@gm...> wrote:
[snip]
>
> I'm going to say that that is a limitation of the html4 serializer. If
> you are using cElementTree, you must be using version 1.0.6 or later.
> In other words, this is a bug in cElmentTree, not a bug in Markdown.
> Even if you are using a version greater than 1.0.6, I'd say this is
> still a bug in cElementTree.

I should point out that anyone can provide there own serializers, so
if the above is really not an option, you can always use your own
serializer that does what you want. I'm a little hesitant to do so
with our markdown.html4 module because that is under a different
license than the rest of the project and copyrighted to the author of
ElementTree.

> Of course, if anyone has any better suggestions, I'm open to entertain
> them - and we accept patches.
>
> Oh, and regarding your final comment regarding `markdown.isBlockLevel`
> choking in Comment nodes, I'll patch that. We definitely should
> support using Comment nodes there.

Hmm, now I'm looking at the code and all isBlockLevel does it take a
tag, which is a string. Perhaps elsewhere in the code, we are assuming
every ElementTree element has a tag and that is where the exception is
being raised. Like in markdown.treeprocessors.PrettifyTreeprocessor.
Should we be checking that an element has a tag first and behave
differently if not?

Oh, and in the most recent development codebase, its at
`markdown.util.isBlockLevel`. You can get the code here:

http://gitorious.org/python-markdown

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

[Python-markdown-discuss] Ticket 80

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

dtyschenko,

Thanks for you report on  Ticket 80[1] for Python-Markdown. I'm
responding to your report via the list [2] as I'm not sure how or if
we should fix the reported problem.

At first I was a little confused by your report as we don't do
anything with comments - if they exist in the source they are pulled
out as rawhtml and never see ElementTree.  Then I realized you must be
using a third party extension which create html comments and inserts
them into the tree. That is certainly something we want to support and
allow you to do.

However, it appears you are also using the html4 serializer - which we
borrowed (with permission) from the ElementTree 1.3 Preview (still in
alpha since 2007 AFAICT). Any changes to that serializer would ideally
be changes made upstream as well.

In fact, your proposed fix, to also import parts of ElementTree when
using cElementTree feels wrong and defeats the purpose of cElementTree
in the first place. In fact, I see in the notes to ElementTree 1.3
there is a note [3] that it only works with  cElementTree 1.0.6 or
later. What version are you using?

I'm going to say that that is a limitation of the html4 serializer. If
you are using cElementTree, you must be using version 1.0.6 or later.
In other words, this is a bug in cElmentTree, not a bug in Markdown.
Even if you are using a version greater than 1.0.6, I'd say this is
still a bug in cElementTree.

Of course, if anyone has any better suggestions, I'm open to entertain
them - and we accept patches.

Oh, and regarding your final comment regarding `markdown.isBlockLevel`
choking in Comment nodes, I'll patch that. We definitely should
support using Comment nodes there.

[1]: http://www.freewisdom.org/projects/python-markdown/Tickets/000080
[2]: https://lists.sourceforge.net/mailman/listinfo/python-markdown-discuss
[3]: http://effbot.org/zone/elementtree-13-intro.htm#performance

Waylan Limberg

[Python-markdown-discuss] New Extension: Typed Lists

[Gerry L. <gjl...@gm...>]

Greetings-

I've created an extension that recognizes and will generate markup for letter
marked or Roman numeral marked ordered lists.  It requires CSS settings for the
list types such as:

    ol.upper-alpha { list-style-type: upper-alpha; }
    ol.lower-roman { list-style-type: lower-roman; }

and so forth.

It recognizes upper and lower case letters as well as upper and lower
case Roman numerals for the list markers.  The extension generates the
normal markup for the standard numeric marked ordered lists.

I've created a [repository][1] on gitorious.  Feel free to use it or modify it
as you will.

[1]: [http://gitorious.org/markdown-typed_olist

Regards-
Gerry LaMontagne

Re: [Python-markdown-discuss] Ticket 76

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

Thanks for the feedback. I've closed the ticket.

Waylan

On Sat, Sep 18, 2010 at 9:33 PM, David Chambers
<dav...@gm...> wrote:
> Thanks for getting in touch, Gerry. I've grabbed the latest code and can
> confirm that this example works correctly for me now, too. I should have
> done this before filing the bug report; I'll do so in future.
> I managed to work around the issue by pulling out the problematic chunks of
> markup and reinserting them post processing, but it feels good to have the
> issue fixed.
> If I come across further cases of HTML being mangled now that I'm on 2.1.0,
> I'll write some appropriate test cases. I'm hopeful that this situation will
> not arise. :)
> David
>
>
> On 19 September 2010 12:53, Waylan Limberg <wa...@gm...> wrote:
>>
>> I believe David subscribes to the list, but I've copied him anyway.
>>
>> David, do you any input on this?
>>
>> And Gerry, thanks I haven't had the time to look at this yet.
>>
>> Waylan
>>
>> On Sat, Sep 18, 2010 at 10:52 AM, Gerry LaMontagne <gjl...@gm...>
>> wrote:
>> > I believe the issue raised in this ticket has been fixed in the latest
>> > commit of version 2.1.  At the very least, I tested the example provided
>> > and the returned html is correct- no newlines inserted or anything.
>> >
>> > I didn't see any contact info for the reporter, but if he has real-world
>> > test cases, and is willing, it would be useful for him to test drive the
>> > latest version from gitorious and provide further verification for the
>> > fixes made in the latest commit.  Perhaps he would be willing to provide
>> > some further test samples that we can incorporate into the test suite.
>> >
>> > I'd be willing to cobble the tests together given further examples.
>> >
>> > Regards-
>> > Gerry LaMontagne
>> >
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1.4.10 (GNU/Linux)
>> >
>> > iF4EAREIAAYFAkyU0icACgkQuZVaBQlJuPHttQD+PQ+JJAA//e8wlvWJhfzhNBZe
>> > p67vnDmp+vWVeMA2efUA/ilxPeUnzIklMzre5mBHjDy5A5etGBw2GjzBWTsKQt5y
>> > =qX68
>> > -----END PGP SIGNATURE-----
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Start uncovering the many advantages of virtual appliances
>> > and start using them to simplify application deployment and
>> > accelerate your shift to cloud computing.
>> > http://p.sf.net/sfu/novell-sfdev2dev
>> > _______________________________________________
>> > Python-markdown-discuss mailing list
>> > Pyt...@li...
>> > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>> >
>> >
>>
>>
>>
>> --
>> ----
>> \X/ /-\ `/ |_ /-\ |\|
>> Waylan Limberg
>
>



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

Re: [Python-markdown-discuss] Ticket 76

[David C. <dav...@gm...>]

Thanks for getting in touch, Gerry. I've grabbed the latest code and can
confirm that this example works correctly for me now, too. I should have
done this before filing the bug report; I'll do so in future.

I managed to work around the issue by pulling out the problematic chunks of
markup and reinserting them post processing, but it feels good to have the
issue fixed.

If I come across further cases of HTML being mangled now that I'm on 2.1.0,
I'll write some appropriate test cases. I'm hopeful that this situation will
not arise. :)

David


On 19 September 2010 12:53, Waylan Limberg <wa...@gm...> wrote:

> I believe David subscribes to the list, but I've copied him anyway.
>
> David, do you any input on this?
>
> And Gerry, thanks I haven't had the time to look at this yet.
>
> Waylan
>
> On Sat, Sep 18, 2010 at 10:52 AM, Gerry LaMontagne <gjl...@gm...>
> wrote:
> > I believe the issue raised in this ticket has been fixed in the latest
> > commit of version 2.1.  At the very least, I tested the example provided
> > and the returned html is correct- no newlines inserted or anything.
> >
> > I didn't see any contact info for the reporter, but if he has real-world
> > test cases, and is willing, it would be useful for him to test drive the
> > latest version from gitorious and provide further verification for the
> > fixes made in the latest commit.  Perhaps he would be willing to provide
> > some further test samples that we can incorporate into the test suite.
> >
> > I'd be willing to cobble the tests together given further examples.
> >
> > Regards-
> > Gerry LaMontagne
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> >
> > iF4EAREIAAYFAkyU0icACgkQuZVaBQlJuPHttQD+PQ+JJAA//e8wlvWJhfzhNBZe
> > p67vnDmp+vWVeMA2efUA/ilxPeUnzIklMzre5mBHjDy5A5etGBw2GjzBWTsKQt5y
> > =qX68
> > -----END PGP SIGNATURE-----
> >
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Python-markdown-discuss mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> >
> >
>
>
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>

Re: [Python-markdown-discuss] Ticket 76

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

I believe David subscribes to the list, but I've copied him anyway.

David, do you any input on this?

And Gerry, thanks I haven't had the time to look at this yet.

Waylan

On Sat, Sep 18, 2010 at 10:52 AM, Gerry LaMontagne <gjl...@gm...> wrote:
> I believe the issue raised in this ticket has been fixed in the latest
> commit of version 2.1.  At the very least, I tested the example provided
> and the returned html is correct- no newlines inserted or anything.
>
> I didn't see any contact info for the reporter, but if he has real-world
> test cases, and is willing, it would be useful for him to test drive the
> latest version from gitorious and provide further verification for the
> fixes made in the latest commit.  Perhaps he would be willing to provide
> some further test samples that we can incorporate into the test suite.
>
> I'd be willing to cobble the tests together given further examples.
>
> Regards-
> Gerry LaMontagne
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iF4EAREIAAYFAkyU0icACgkQuZVaBQlJuPHttQD+PQ+JJAA//e8wlvWJhfzhNBZe
> p67vnDmp+vWVeMA2efUA/ilxPeUnzIklMzre5mBHjDy5A5etGBw2GjzBWTsKQt5y
> =qX68
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



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

[Python-markdown-discuss] Ticket 76

[Gerry L. <gjl...@gm...>]

I believe the issue raised in this ticket has been fixed in the latest
commit of version 2.1.  At the very least, I tested the example provided
and the returned html is correct- no newlines inserted or anything.

I didn't see any contact info for the reporter, but if he has real-world
test cases, and is willing, it would be useful for him to test drive the
latest version from gitorious and provide further verification for the
fixes made in the latest commit.  Perhaps he would be willing to provide
some further test samples that we can incorporate into the test suite.

I'd be willing to cobble the tests together given further examples.

Regards-
Gerry LaMontagne