python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] AtomicString

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

> There is absolutely no camelcase words in the text we pass in, so no
> wikilinks should be generated. However, it appears that the
> placeholder for the "markdownlink" is inserted into the text as
> ``\x02LinkPattern:000\x03``. Normally, this would later be replaced by

Yeah, that's an whoops.  I think rather than just avoiding camelcase
in placeholders, we should avoid anything meangingfull in them at all,
apart from STX and ETX codes.  We used to have some random combination
of characters.  Adding STX and ETX around it made it safer against us
trying to replace the occurrence of the placeholder in the original
text.  However, switching from a random combination to meaningful
things like "LinkPattern" creates the possibility of users messing
with our placeholders via extensions.  So, I we should do both: use a
meaningless combination of letters (without any punctuation), and then
wrap it with characters that users aren't allowed to put in the input
(STX and ETX).  E.g.:

STX = u'\u0002'  # Use STX ("Start of text") for start-of-placeholder
ETX = u'\u0003'  # Use ETX ("End of text") for end-of-placeholder
HTML_PLACEHOLDER_PREFIX = STX+"wyxhzde38k"
HTML_PLACEHOLDER = HTML_PLACEHOLDER_PREFIX + "%d"+ETX
INLINE_PLACEHOLDER_PREFIX = STX+"0ix2bavflj"
INLINE_PLACEHOLDER_SUFFIX = ETX
AMP_SUBSTITUTE = STX+"k75lziz62a"+ETX

Actually, come to think of it, perhaps even that %d is not a good idea.

(I am not checking this in, since Waylan seems to be actively working
on the file.)

 - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] AtomicString

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

On Fri, Aug 22, 2008 at 3:25 PM, Waylan Limberg <wa...@gm...> wrote:
[snip]
> There is absolutely no camelcase words in the text we pass in, so no
> wikilinks should be generated. However, it appears that the
> placeholder for the "markdownlink" is inserted into the text as
> ``\x02LinkPattern:000\x03``. [snip]

Sorry that should have been ``\x02inline:LinkPattern:0000\x03``.

Regardless, the point remains.

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

Re: [Python-markdown-discuss] AtomicString

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

Neale,

I'm getting the same bug with the included wikilink extension.
However, as far as I can tell, the extension is not the problem. It's
the way the inline placeholders work that is tripping up these
camelcase link generators. I've filed ticket #14 [1] for it.

Particularly note the last example I included in that ticket:

    In [4]: markdown.markdown('[markdownlink](/markdownlink)',
['wikilink'])
    Out[4]: u'<p>\x02inline:<a class="wikilink"
href="/LinkPattern/">LinkPattern</a>:0000\x03</p>'

There is absolutely no camelcase words in the text we pass in, so no
wikilinks should be generated. However, it appears that the
placeholder for the "markdownlink" is inserted into the text as
``\x02LinkPattern:000\x03``. Normally, this would later be replaced by
the html for the link. However, before that happens, the wikilink
extension looks for a match and finds one for "LinkPattern" which it
replaces with a link. Whoops. Obviously, markdown can't use camelcase
placeholders.

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

On Thu, Aug 21, 2008 at 6:12 PM, Neale Pickett <ne...@wo...> wrote:
> I was the one who suggested the AtomicString change that's recently been
> committed.  It's probably time to move discussion to the mail list.
>
> I'm writing a wiki and what prompted the change was that this:
>
>    <http://example.com/CamelCase/foo>
>
> Would turn into this:
>
>    <a href="http://example.com/CamelCase/foo">http://example.com/<a
>       href="CamelCase.wki">CamelCase</a>/foo</a>
>
> AtomicString fixes that by creating a new String class (inherits from
> unicode, actually) that won't receive further processing.  Then it's a
> simple matter of setting `e.text = AtomicString(whatever)`.
>
> I have a new problem in my WikiLinkPattern class.  Here is some
> debugging output:
>
>    handlematch u'If you are new to wiki, check out WikiHelp.'
>
>    handlematch u'If you are new to wiki, check out \x02inline:WikiLinkPattern:0000\x03.'
>
>    handlematch u'If you are new to wiki, check out \x02inline:\x02inline:WikiLinkPattern:0001\x03:0000\x03.'
>
> ad infinitum.  My WikiLink regex is matching the inline thingy.
>
> I know the upstream dudes are at least pondering removing inline
> entirely, possibly using a mechanism like AtomicString.  Should I hold
> off on fixing this locally?
>
> Neale
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
----
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

[Python-markdown-discuss] AtomicString

[Neale P. <ne...@wo...>]

I was the one who suggested the AtomicString change that's recently been
committed.  It's probably time to move discussion to the mail list.

I'm writing a wiki and what prompted the change was that this:

    <http://example.com/CamelCase/foo>

Would turn into this:

    <a href="http://example.com/CamelCase/foo">http://example.com/<a
       href="CamelCase.wki">CamelCase</a>/foo</a>

AtomicString fixes that by creating a new String class (inherits from
unicode, actually) that won't receive further processing.  Then it's a
simple matter of setting `e.text = AtomicString(whatever)`.

I have a new problem in my WikiLinkPattern class.  Here is some
debugging output:

    handlematch u'If you are new to wiki, check out WikiHelp.'

    handlematch u'If you are new to wiki, check out \x02inline:WikiLinkPattern:0000\x03.'

    handlematch u'If you are new to wiki, check out \x02inline:\x02inline:WikiLinkPattern:0001\x03:0000\x03.'

ad infinitum.  My WikiLink regex is matching the inline thingy.

I know the upstream dudes are at least pondering removing inline
entirely, possibly using a mechanism like AtomicString.  Should I hold
off on fixing this locally?

Neale

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...

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 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...

[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] 2.0-beta and 2.1-alpha

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

Waylan Limberg wrote:
> Artem,
>
> I've taken a quick glance at your code. I'll need more time to digest
> it fully, but here are a few quick observations and questions:
>
> I'm assuming your "2.0-beta" is the latest commit on the "master"
> branch, "2.1-alpha" is the "norec2" branch and the slower version (no
> tarball) is the "norec" branch. Am I right on that?
>   

Yep, that's it.
"2.1-alpha" is faster, but there are some issues, in spite of all tests 
works fine.
for instance:

* item 1
* item 2
    aditional text

* item 3

If splitting index will point to the third line, it'll treat it as code 
block, not as list. For now splitting function do only forward analyzing.
I'll fix it in few days.

> Second, have you tested the included extensions with the no-recursion
> stuff? At least the headerid and codehilite extensions could be
> affected by this.
>   

I tested headerid extension, but didn't test codehilite, because it 
makes only text changes.

> Third, I couldn't help but notice that in the "norec" branch you undid
> commit [ac578bc][]. Of course, if we're not using that one due to
> performance issues, no big deal.
>
> [ac578bc]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/ac578bc2e55183ff0d6d9002ccfdb82d38778a2b
>
>   

I think I just created this branch without pulling ac578bc to my local 
master branch. Yes, I don't think we'll be using it, due to performance 
issues.

> On Mon, Aug 18, 2008 at 1:59 PM, Artem Yunusov <ne...@gm...> wrote:
>   
>> Hello all,
>>
>> [2.0-beta][] and [2.1-alpha][] released. Major change in 2.1-alpha is
>> fix for recursion limit bug (ticket #3), now Python-Markdown can process
>> any length text. First I tried completely get rid of recursion, but that
>> version was slower (about 10%) then version with recursion. In 2.1-alpha
>> version input splits on parts and then every part processed, it has
>> almost same performance as 2.0-beta.
>>
>> [2.0-beta]: http://splyer.com/markdown2.0-beta.tar.gz
>> [2.1-alpha]: http://splyer.com/markdown2.1-alpha.tar.gz
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>>     
>
>
>
>   

Re: [Python-markdown-discuss] 2.0-beta and 2.1-alpha

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

Artem,

I've taken a quick glance at your code. I'll need more time to digest
it fully, but here are a few quick observations and questions:

I'm assuming your "2.0-beta" is the latest commit on the "master"
branch, "2.1-alpha" is the "norec2" branch and the slower version (no
tarball) is the "norec" branch. Am I right on that?

Second, have you tested the included extensions with the no-recursion
stuff? At least the headerid and codehilite extensions could be
affected by this.

Third, I couldn't help but notice that in the "norec" branch you undid
commit [ac578bc][]. Of course, if we're not using that one due to
performance issues, no big deal.

[ac578bc]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/ac578bc2e55183ff0d6d9002ccfdb82d38778a2b


On Mon, Aug 18, 2008 at 1:59 PM, Artem Yunusov <ne...@gm...> wrote:
> Hello all,
>
> [2.0-beta][] and [2.1-alpha][] released. Major change in 2.1-alpha is
> fix for recursion limit bug (ticket #3), now Python-Markdown can process
> any length text. First I tried completely get rid of recursion, but that
> version was slower (about 10%) then version with recursion. In 2.1-alpha
> version input splits on parts and then every part processed, it has
> almost same performance as 2.0-beta.
>
> [2.0-beta]: http://splyer.com/markdown2.0-beta.tar.gz
> [2.1-alpha]: http://splyer.com/markdown2.1-alpha.tar.gz
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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

[Python-markdown-discuss] 2.0-beta and 2.1-alpha

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

Hello all,

[2.0-beta][] and [2.1-alpha][] released. Major change in 2.1-alpha is 
fix for recursion limit bug (ticket #3), now Python-Markdown can process 
any length text. First I tried completely get rid of recursion, but that 
version was slower (about 10%) then version with recursion. In 2.1-alpha 
version input splits on parts and then every part processed, it has 
almost same performance as 2.0-beta.

[2.0-beta]: http://splyer.com/markdown2.0-beta.tar.gz
[2.1-alpha]: http://splyer.com/markdown2.1-alpha.tar.gz

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

Yeah, well I couldn't access my gmail account so I didn't know you
sent three copies.

Anyway, I made the adjustments you suggested and merged. I just pushed
the changes. If anyone has any problems please let me know.

On Mon, Aug 11, 2008 at 7:07 PM, Yuri Takhteyev <qar...@gm...> wrote:
> In case anyone is wondering, the reason for the triple message is
> gmail downtime...  They tell you they couldn't send the message even
> though they did...
>
>  - yuri
>
> On Mon, Aug 11, 2008 at 2:58 PM, Yuri Takhteyev <qar...@gm...> wrote:
>>> Unless I'm missing something, we can't do this unless we make markdown
>
> --
> http://sputnik.freewisdom.org/
>



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

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

In case anyone is wondering, the reason for the triple message is
gmail downtime...  They tell you they couldn't send the message even
though they did...

  - yuri

On Mon, Aug 11, 2008 at 2:58 PM, Yuri Takhteyev <qar...@gm...> wrote:
>> Unless I'm missing something, we can't do this unless we make markdown

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

> Unless I'm missing something, we can't do this unless we make markdown
> a package. At the least we'd have to put the contents of markdown.py
> in markdown/__init__.py which completely removes any usefulness of
> markdown.py as a commandline script. I suppose we could do
> markdown/markdown.py and then have markdown/__init__.py just do a
> ``import *``

Right... I am forgetting that Python is not Lua and you can't have it
both ways. :)

No, let's not turn markdown into a package.  Let's call the extension
package something else, but something explicit.  Perhaps
"markdown_extensions"?

 - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

> Unless I'm missing something, we can't do this unless we make markdown
> a package. At the least we'd have to put the contents of markdown.py
> in markdown/__init__.py which completely removes any usefulness of
> markdown.py as a commandline script. I suppose we could do
> markdown/markdown.py and then have markdown/__init__.py just do a
> ``import *``

Right... I am forgetting that Python is not Lua and you can't have it
both ways. :)

No, let's not turn markdown into a package.  Let's call the extension
package something else, but something explicit.  Perhaps
"markdown_extensions"?

 - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

> Unless I'm missing something, we can't do this unless we make markdown
> a package. At the least we'd have to put the contents of markdown.py
> in markdown/__init__.py which completely removes any usefulness of
> markdown.py as a commandline script. I suppose we could do
> markdown/markdown.py and then have markdown/__init__.py just do a
> ``import *``

Right... I am forgetting that Python is not Lua and you can't have it
both ways. :)

No, let's not turn markdown into a package.  Let's call the extension
package something else, but something explicit.  Perhaps
"markdown_extensions"?

 - yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

On Mon, Aug 11, 2008 at 4:31 PM, Yuri Takhteyev <yu...@si...> wrote:
> I like the re-org overall.   Just a few suggestions.
>
> First, let's move the extensions to a separate directory as Waylan
> did, but let's give it a more explicit name, now that we are at it.
> How about putting them in markdown/extensions, and then importing them
> as markdown.extensions.foo?

Unless I'm missing something, we can't do this unless we make markdown
a package. At the least we'd have to put the contents of markdown.py
in markdown/__init__.py which completely removes any usefulness of
markdown.py as a commandline script. I suppose we could do
markdown/markdown.py and then have markdown/__init__.py just do a
``import *``

>
> Second, let's get rid of the "mdx_" prefices for modules that will be
> moved into a package, but let's keep support for the old style mdx_*
> extensions (unpackaged).  Let's make this a fallback, thought.  I.e.,
> if someone wants to use "foo" extension, _first_ try to load
> markdown.extensions.foo, and if this doesn't work, check "mdx_foo".

No problem, I can do it that way too.

>
>  - yuri
>
> On Sun, Aug 10, 2008 at 2:40 PM, Artem Yunusov <ne...@gm...> wrote:
>> Waylan Limberg wrote:
>>> Anyone have any objections to either the docs or extensions move? If
>>> there's no objections, I'll merge it in. If I get objections to only
>>> one or the other, I can work with that too.
>>>
>>
>> I don't have any objections, and think it's good idea.
>>> One other question: if we do the extension reorg, should the
>>> extensions be 'mdx.mdx_extname.py' or 'mdx.extname.py'? It's just that
>>> the extra 'mdx' seems redundant - but given that we've already
>>> established that naming convention, maybe we should leave it.
>>> Thoughts?
>>>
>>
>> Vote for names without "mdx_" prefix :) we already have namespace for
>> extension and there is no need to add pseudo-namespace. I think in
>> general, such technique(adding prefixes) is unpythonic, because in
>> Python we have real namespacing.
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
>
> --
> http://sputnik.freewisdom.org/
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

[Yuri T. <yu...@si...>]

I like the re-org overall.   Just a few suggestions.

First, let's move the extensions to a separate directory as Waylan
did, but let's give it a more explicit name, now that we are at it.
How about putting them in markdown/extensions, and then importing them
as markdown.extensions.foo?

Second, let's get rid of the "mdx_" prefices for modules that will be
moved into a package, but let's keep support for the old style mdx_*
extensions (unpackaged).  Let's make this a fallback, thought.  I.e.,
if someone wants to use "foo" extension, _first_ try to load
markdown.extensions.foo, and if this doesn't work, check "mdx_foo".

 - yuri

On Sun, Aug 10, 2008 at 2:40 PM, Artem Yunusov <ne...@gm...> wrote:
> Waylan Limberg wrote:
>> Anyone have any objections to either the docs or extensions move? If
>> there's no objections, I'll merge it in. If I get objections to only
>> one or the other, I can work with that too.
>>
>
> I don't have any objections, and think it's good idea.
>> One other question: if we do the extension reorg, should the
>> extensions be 'mdx.mdx_extname.py' or 'mdx.extname.py'? It's just that
>> the extra 'mdx' seems redundant - but given that we've already
>> established that naming convention, maybe we should leave it.
>> Thoughts?
>>
>
> Vote for names without "mdx_" prefix :) we already have namespace for
> extension and there is no need to add pseudo-namespace. I think in
> general, such technique(adding prefixes) is unpythonic, because in
> Python we have real namespacing.
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] Proposed File Cleanup and reorg.

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

Waylan Limberg wrote:
> Anyone have any objections to either the docs or extensions move? If
> there's no objections, I'll merge it in. If I get objections to only
> one or the other, I can work with that too.
>   

I don't have any objections, and think it's good idea.
> One other question: if we do the extension reorg, should the
> extensions be 'mdx.mdx_extname.py' or 'mdx.extname.py'? It's just that
> the extra 'mdx' seems redundant - but given that we've already
> established that naming convention, maybe we should leave it.
> Thoughts?
>   

Vote for names without "mdx_" prefix :) we already have namespace for 
extension and there is no need to add pseudo-namespace. I think in 
general, such technique(adding prefixes) is unpythonic, because in 
Python we have real namespacing.

[Python-markdown-discuss] Proposed File Cleanup and reorg.

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

I just created a new branch [1] that reorganizes and (IMO) cleans up
the file system a little. All the text files are moved into a 'docs/'
dir and all the extensions have been moved into a 'mdx/' dir. It feels
so much less cluttered to me this way.

I should note that, as you can see in this commit [2], it still tries
the old way of importing the 'mdx_extname.py' first, then on failure,
'mdx.mdx_extname.py'. That way, people can create their own
extensions, give it the same name, put it on their PYTHONPATH and it
will override the distributed extension - all without them needing to
modify the distributed code. Thus, in any future upgrades, their work
won't get overwritten. Plus, those who don't actually install, but
have everything in the working dir still get the current behavior if
they want.

Anyone have any objections to either the docs or extensions move? If
there's no objections, I'll merge it in. If I get objections to only
one or the other, I can work with that too.

One other question: if we do the extension reorg, should the
extensions be 'mdx.mdx_extname.py' or 'mdx.extname.py'? It's just that
the extra 'mdx' seems redundant - but given that we've already
established that naming convention, maybe we should leave it.
Thoughts?

Oh, I added AUTHORS and INSTALL files in the docs. The INSTALL file is
vary incomplete and those sections of the README should probably be
removed.

[1]: http://gitorious.org/projects/python-markdown/repos/mainline/trees/reorg
[2]: http://gitorious.org/projects/python-markdown/repos/mainline/commits/2b7e391fcd51d3468133f628f2e013574cf16536#markdown.py
-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] GSoC version merged to mainline

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

> For instance for Debian/Ubuntu it'll be:
> apt-get install python-elementtree
>
> for BSD systems, i.e FreeBSD:
> cd /usr/ports/devel/py-elementtree; make install clean
>
> Fedora Core (and I suppose Red Hat too):
> yum install python-elementtree

This is all good if you have root access.  However, if you want to use
python markdown for a website running on shared hosting, then there is
a good chance that you have limited access, so those methods are out
of the question.  I know _I_ don't have root access to the machine
where the python markdown wiki is running.  And believe it or not,
some people don't even have shell access to their hosts - only ftp.
Last year I had to try install mediawiki via ftp.  Don't get me
started on this.

So, it's good to document all of those methods, but we also need to
keep in mind the user without root access.

- yuri

-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] GSoC version merged to mainline

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

Yuri Takhteyev wrote:
>> Or for any platform:
>> easy_install http://splyer.com/markdown2.0-alpha.tar.gz
>> easy_install elementtree
>>     
>
> That too, though if you are limited to python2.3, chances are you
> don't have easy_install pre-installed. :)
>   

Yep, forgot about it.
For Windows it'll be quite simple, there are official binary installers.
Also a lot of Linux distributions includes ElementTree in the repository.

For instance for Debian/Ubuntu it'll be:
apt-get install python-elementtree

for BSD systems, i.e FreeBSD:
cd /usr/ports/devel/py-elementtree; make install clean

Fedora Core (and I suppose Red Hat too):
yum install python-elementtree
>   
>> What about AND_SUBSTITUTE ? I use it in some places instead of "&", now
>> it's:
>> AND_SUBSTITUTE = unichr(2) + unichr(4) + unichr(3)
>> is it ok ?
>>     
>
> Just for the sake of consistency, I would make it STX+"amp"+ETX.  And
> I would call it AMPERSAND_SUBSTITUTE or AMP_SUBSTITUTE, since
> AND_SUBSTITUTE can mean too many things.
>   

Good idea, changed to

AMP_SUBSTITUTE = STX+"amp"+ETX
 

> Also, can you add more comments to the code?  (I mean especially the
> parts that you changed, though you are welcome to comment old code as
> well.)
>   

Added some more comments, and revisioned old ones, maybe later add some 
more.

> Also, we had that discussion of recursion before.  I am in principle
> all for getting rid of recursion as Waylan was suggesting, but I think
> considering the time constraints, perhaps it would be more practical
> to cap recursion by simply breaking the input into chunks.  This needs
> to be done with a little bit of thought so that we don't break lists,
> etc. into multiple chunks.  However, I think it will be much easier
> than trying to rewrite the current _processSection logic and it should
> get us the same benefits in terms of performance.
>   

If time permits, I'll try to do it extendable, if not - just get rid of 
recursion.

Re: [Python-markdown-discuss] GSoC version merged to mainline

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

On Thu, Aug 7, 2008 at 7:33 PM, Artem Yunusov <ne...@gm...> wrote:
> Yuri Takhteyev wrote:
>>
>> I tried running the new version with Python 2.5, 2.4 and 2.3.  For
>> 2.5, all the tests pass out of the box, no element tree installation
>> required.  For 2.4, I had to install element tree, after which all
>> works fine.  So, we just need to make sure to document this.  I think
>> we should include specific line-by-line instructions on the wiki,
>> rather than just sending people to element tree website, which I
>> myself found mildly confusing.  E.g., for UNIX:
>>
>>     wget http://splyer.com/markdown2.0.tar.gz
>>     wget http://splyer.com/markdown2.0-alpha.tar.gz
>>     tar xvzf markdown2.0-alpha.tar.gz
>>     cd markdown2.0-alpha/
>>     wget http://effbot.org/media/downloads/elementtree-1.2.6-20050316.tar.gz
>>     tar xvzf elementtree-1.2.6-20050316.tar.gz
>>     mv elementtree-1.2.6-20050316/elementtree .
>>     python2.4 test-markdown.py
>>
>
> Or for any platform:
> easy_install http://splyer.com/markdown2.0-alpha.tar.gz
> easy_install elementtree
>

It occurs to me that we do not have an INSTALL file in the
distribution. Perhaps we should add one and write up the install
procedure there. Then, when we release, we can just copy that over to
the wiki as well.


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

Re: [Python-markdown-discuss] GSoC version merged to mainline

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

On Thu, Aug 7, 2008 at 7:25 PM, Artem Yunusov <ne...@gm...> wrote:
> Waylan Limberg wrote:
>> On Wed, Aug 6, 2008 at 10:34 PM, Waylan Limberg <wa...@gm...> wrote:
>>
>>> On Wed, Aug 6, 2008 at 6:41 PM, Artem Yunusov <ne...@gm...> wrote:
>>>
>>>> Yep, I'll update doc strings by myself. Thanks for the link to PEP 257.
>>>> I think extension writers need to know about markdown.etree module
>>>> object, and also, that all data in <inline> tag will be processed by
>>>> inline patterns, other functions, like indentETree is useless for them.
>>>> I think we should write about all this on site in "Writing Extensions"
>>>> section.
>>>>
>>> I agree. Actually, that section needs to be completely reworked as a
>>> number of additions/changes have happened to the extension API since
>>> that page was last updated. The thing is, we don't want to update that
>>> page until after 2.0 final is released or people may expect it to
>>> apply to 1.7. I think maybe we should throw a text file in git for now
>>> and copy it over the the wiki when we release. If you write up the
>>> docs for the stuff you did Artem, I'll do the rest - unless you beat
>>> me to it..
>>>
>>
>> FYI, I just committed a rough draft. Artem, I left the section on DOM
>> manipulation for you. Any criticisms, suggestions or corrections are
>> welcome. I'll copy it to the wiki when we release 2.0 final.
>>
>
> Thanks, I'll write about it. One suggestion, I think we should not call
> ElementTree object - DOM, because it's slightly different things, as far
> as understand.
>

Go ahead and edit as you see fit. Your certainly more familiar with
that part of the code (including the terminology to use) so go for it.
I was just using the same old terms we had before.



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