python-markdown-discuss — A general purpose discussion list

[Python-markdown-discuss] differance between svn and 1.6b

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

I recently noticed that some of the changes in 1.6b never made it to
the svn repo. A few were simple, like the HRs and BRs being stripped
in safemode and the whitespace issues affecting a codeblock on the
first line. I've since committed patches to those issues.

However, the big differance is the addition of textPreprocessors with
the HTML_BLOCK_PREPROCESSOR being moved there from the preprocessors.

Is there any reason this never made it to the repo? Would you like me
to merge it in?

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

Re: [Python-markdown-discuss] CorePatterns Refactor?

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

Sorry for not responding earlier.  It's been a hectic month.  (Or,
should I say a hectic year...)

> For as long as I can remember the following comment has been in the
> CorePatterns class:
>
>     """This class is scheduled for removal as part of a refactoring effort."""
>
> My question is; what would that refactor entail? Is there any help I
> can provide?

I believe I put this comment there when I was refactoring Markdown to
put much of processing into the instances of the Pattern class
(SimpleTextPatter, BacktickPattern, etc.)  After I did this there were
some regular expressions that were left over.  I must have had some
plan on what to do with them eventually, but if I did, I no longer
remember what it was.

So, "scheduled for removal" is too strong of a word.  It would be
better to say: it would be nice to get rid of this collection of
"leftover" patterns I figure out how.

> I'm not posting this to complain. I'd just like to see that refactor
> move forward if that's still the plan. If I can help, even better. The
> problem is, I don't know what the plan is, so its a little difficult
> to help. At the same time I realize this is complex stuff.

There is no plan.  If you can help with further refactoring, I would
much appreciate it.  Email me your sourceforge ID and I will add you
to the project.

In particular, your patch looks good.  If it doesn't break any tests,
let's commit it.

Thanks for the help!

  - yuri

-- 
http://www.freewisdom.org/

Re: [Python-markdown-discuss] Announcing the Meta-Data Extension

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

On 10/3/07, Waylan Limberg <wa...@gm...> wrote:
>
> [1]: http://achinghead.com/markdown/meta/

Sorry, that link should be http://achinghead.com/markdown/meta-data/


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

[Python-markdown-discuss] Announcing the Meta-Data Extension

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

I've just released a Meta-Data Extension[1] for Python-Markdown.  I've
also updated the WikiLink[2] and Abbreviation[3] extensions to support
it.

I should note that the extension does *not* do anything with the
meta-data, but simply extracts the data from the document and makes it
available for use by other code.

Read the full announcment [4] and the docs [1] for more details, or
view the code [5]. Any and all feedback is welcome.

[1]: http://achinghead.com/markdown/meta/
[2]: http://achinghead.com/markdown/wikilink/
[3]: http://achinghead.com/markdown/abbr/
[4]: http://achinghead.com/archive/78/announcing-meta-data-extension-python-markdown/
[5]: https://code.achinghead.com/browser/mdx/meta/trunk/mdx_meta.py

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

Re: [Python-markdown-discuss] Trouble with wiki (creating account)

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

Thanks for pointing this out.  I will look into this.

  - yuri

On 9/28/07, Brian Jaress <bri...@gn...> wrote:
> I didn't know where else to send this, but I'm having trouble with the
> wiki at http://www.freewisdom.org/projects/python-markdown/.
>
> When I try to create an account, I get:
>
> ...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:103: Cosmo: the iterator
> for dofields failed: ...08-15-install-markdown/share/lua/5.1/wikistorage.lua:110:
> bad argument #1 to 'pairs' (table expected, got nil)
> stack traceback:
>   [C]: in function 'error'
>   ...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:103: in function
> <...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:91>
>   (tail call): ?
>   [C]: in function 'gsub'
>   ...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:51: in function
> <...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:48>
>   (tail call): ?
>   (tail call): ?
>   ...08-15-install-markdown/share/lua/5.1/wikistorage.lua:138: in function
> <...08-15-install-markdown/share/lua/5.1/wikistorage.lua:131>
>   (tail call): ?
>   sputnik.lua:51: in function 'save'
>   sputnik.lua:61: in function 'check_password'
>   sputnik.lua:618: in function 'get_params'
>   sputnik.lua:643: in function 'main'
>   sputnik.lua:663: in main chunk
>   (tail call): ?
>   (tail call): ?
>   (tail call): ?
>   [C]: in function 'xpcall'
>   ...2007-08-15-install-markdown/share/lua/5.1/cgilua.lua:426: in function
> '_xpcall'
>   ...2007-08-15-install-markdown/share/lua/5.1/cgilua.lua:533: in function
> <...2007-08-15-install-markdown/share/lua/5.1/cgilua.lua:508>
>   (tail call): ?
>
>
>
> --
> Brian Jaress
> bri...@gn...
> http://brian-jaress.livejournal.com
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


-- 
Yuri Takhteyev
Ph.D. Candidate, UC Berkeley School of Information
http://takhteyev.org/, http://www.freewisdom.org/

[Python-markdown-discuss] Trouble with wiki (creating account)

[Brian J. <bri...@gn...>]

I didn't know where else to send this, but I'm having trouble with the
wiki at http://www.freewisdom.org/projects/python-markdown/.

When I try to create an account, I get:

...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:103: Cosmo: the iterator
for dofields failed: ...08-15-install-markdown/share/lua/5.1/wikistorage.lua:110:
bad argument #1 to 'pairs' (table expected, got nil)
stack traceback:
  [C]: in function 'error'
  ...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:103: in function
<...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:91>
  (tail call): ?
  [C]: in function 'gsub'
  ...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:51: in function
<...-2007-08-15-install-markdown/share/lua/5.1/cosmo.lua:48>
  (tail call): ?
  (tail call): ?
  ...08-15-install-markdown/share/lua/5.1/wikistorage.lua:138: in function
<...08-15-install-markdown/share/lua/5.1/wikistorage.lua:131>
  (tail call): ?
  sputnik.lua:51: in function 'save'
  sputnik.lua:61: in function 'check_password'
  sputnik.lua:618: in function 'get_params'
  sputnik.lua:643: in function 'main'
  sputnik.lua:663: in main chunk
  (tail call): ?
  (tail call): ?
  (tail call): ?
  [C]: in function 'xpcall'
  ...2007-08-15-install-markdown/share/lua/5.1/cgilua.lua:426: in function
'_xpcall'
  ...2007-08-15-install-markdown/share/lua/5.1/cgilua.lua:533: in function
<...2007-08-15-install-markdown/share/lua/5.1/cgilua.lua:508>
  (tail call): ?



-- 
Brian Jaress
bri...@gn...
http://brian-jaress.livejournal.com

[Python-markdown-discuss] CorePatterns Refactor?

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

For as long as I can remember the following comment has been in the
CorePatterns class:

    """This class is scheduled for removal as part of a refactoring effort."""

My question is; what would that refactor entail? Is there any help I
can provide?

The reason I ask is highlighted in ticket #1793419 [1]. I'm sure the
quick fix I provide there isn't anywhere near the goal of the
refactor. The way I see it. the problem is that while one could
override the patterns within CorePatterns, is is currently very
difficult to override the code that uses those patterns. It is even
more difficult to add your own patterns.

As the comments suggest just above the CorePatterns class, we should
try to use preprocessors, inlinepatterns or postprocessors if
possible. While understandable, when working with block level markup,
preprocessors don't output to the dom, inlinepatterns will get wrapped
in blocklevel elements defined in CorePatterns (block level elements
would get inappropriately wrapped in <p> tags, for example) and, by
the time we get to postprocessors, it's a little late.

The example I give in the ticket is adding header ids as php markdown
extra does [2]. I could use a preproccesor to extract the id, but now
I need to store it in some way that I know which header it goes with.
Then, how would I add that id to the header? A postprocessor would be
ugly here. The best would be to override the code that puts the header
into the dom. But that is buried in the core. If I'm doing that, I
might as well override the header corepattern.

I'm not posting this to complain. I'd just like to see that refactor
move forward if that's still the plan. If I can help, even better. The
problem is, I don't know what the plan is, so its a little difficult
to help. At the same time I realize this is complex stuff.

PS: As a side note, python-markdown eats php markdown extra's header
id syntax. The header is completely stripped from the output. At the
very least, I would have expected it to be wrapped in a <p> tag. At
best I would have expected the header without the id. Initially, I was
surprised no one implemented this extension yet. Now I know why. It's
currently too hard.

[1]: https://sourceforge.net/tracker/?func=detail&atid=790198&aid=1793419&group_id=153041
[2]: http://michelf.com/projects/php-markdown/extra/#header-id
-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Markdown encoding

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

Thanks for reporting this.   I will look into it.

  - yuri

On 9/12/07, Kent Johnson <ke...@td...> wrote:
> Hi,
>
> Markdown 1.6b doesn't work with UTF-8-encoded text. It fails with a
> UnicodeDecodeError in removeBOM():
>
> In [3]: import markdown
> In [4]: text =3D u'\xe2'.encode('utf-8')
> In [6]: print text
> =E2
> In [7]: print markdown.markdown(text)
> ------------------------------------------------------------
> Traceback (most recent call last):
>    File "<ipython console>", line 1, in <module>
>    File
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac=
kages/markdown.py",
> line 1722, in markdown
>      return md.convert(text)
>    File
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac=
kages/markdown.py",
> line 1614, in convert
>      self.source =3D removeBOM(self.source, self.encoding)
>    File
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac=
kages/markdown.py",
> line 74, in removeBOM
>      if text.startswith(bom):
> <type 'exceptions.UnicodeDecodeError'>: 'ascii' codec can't decode byte
> 0xc3 in position 0: ordinal not in range(128)
>
> The problem is that the BOM being tested is unicode so to execute
>    text.startswith(bom)
> Python tries to convert text to Unicode using the default encoding
> (ascii). This fails because the text is not ascii.
>
> I'm trying to understand what the encoding parameter is for; it doesn't
> seem to do much. There also seems to be some confusion with the use of
> encoding in markdownFromFile() vs markdown(); the file is converted to
> Unicode on input so I don't understand why the same encoding parameter
> is passed to markdown()?
>
> ISTM the encoding passed to markdown should match the encoding of the
> text passed to markdown, and the values in the BOMS table should be in
> the encoding of the key, not in unicode. Then the __unicode__() method
> should actually decode. Or is the intent that the text passed to
> markdown() should always be ascii or unicode?
>
> I can put together a patch if you like but I wanted to make sure that I
> am not missing some grand plan...
>
> Kent
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


--=20
Yuri Takhteyev
Ph.D. Candidate, UC Berkeley School of Information
http://takhteyev.org/, http://www.freewisdom.org/

[Python-markdown-discuss] Markdown encoding

[Kent J. <ke...@td...>]

Hi,

Markdown 1.6b doesn't work with UTF-8-encoded text. It fails with a 
UnicodeDecodeError in removeBOM():

In [3]: import markdown
In [4]: text = u'\xe2'.encode('utf-8')
In [6]: print text
â
In [7]: print markdown.markdown(text)
------------------------------------------------------------
Traceback (most recent call last):
   File "<ipython console>", line 1, in <module>
   File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/markdown.py", 
line 1722, in markdown
     return md.convert(text)
   File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/markdown.py", 
line 1614, in convert
     self.source = removeBOM(self.source, self.encoding)
   File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/markdown.py", 
line 74, in removeBOM
     if text.startswith(bom):
<type 'exceptions.UnicodeDecodeError'>: 'ascii' codec can't decode byte 
0xc3 in position 0: ordinal not in range(128)

The problem is that the BOM being tested is unicode so to execute
   text.startswith(bom)
Python tries to convert text to Unicode using the default encoding 
(ascii). This fails because the text is not ascii.

I'm trying to understand what the encoding parameter is for; it doesn't 
seem to do much. There also seems to be some confusion with the use of 
encoding in markdownFromFile() vs markdown(); the file is converted to 
Unicode on input so I don't understand why the same encoding parameter 
is passed to markdown()?

ISTM the encoding passed to markdown should match the encoding of the 
text passed to markdown, and the values in the BOMS table should be in 
the encoding of the key, not in unicode. Then the __unicode__() method 
should actually decode. Or is the intent that the text passed to 
markdown() should always be ascii or unicode?

I can put together a patch if you like but I wanted to make sure that I 
am not missing some grand plan...

Kent

Re: [Python-markdown-discuss] unordered list with id

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

I am not sure there is a solution.  Attributes attach to the parent of
the text node with which they are entered, and since the ul element
doesn't have any text associated with it there wouldn't be any way to
attach an attribute to a ul.  You might want to try to wrap your list
in a div:

<div id=3D"...">
  * one
  * two
</div>

Another possibility would be to ask on the markdown list what the
solution is for other implementations and if they have a good solution
it might make sense to change python markdown to do the same.

- yuri

On 8/29/07, Jan Erik Mostr=F6m <li...@mo...> wrote:
> Werner Hartnagel <no...@li...> 07-08-29 12:30
>
> >The <p> Tag ist closed before the List instead after,
> >i removed the empty newline:
>
> I can't help you with your problem but
>
> <p class=3D"xxx">
> <ul>
>     <li>....
> </ul>
> </p>
>
> is not valid HTML (lists can't be a part of paragraphs) so you
> either need to find a way to create the first list you wrote or
> perhaps change the CSS definitions (if possible) so no class
> info is needed.
>
>                 jem
> --
> Jan Erik Mostr=F6m, www.mostrom.pp.se
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


--=20
Yuri Takhteyev
Ph.D. Candidate, UC Berkeley School of Information
http://takhteyev.org/, http://www.freewisdom.org/

Re: [Python-markdown-discuss] unordered list with id

[<li...@mo...>]

Werner Hartnagel <no...@li...> 07-08-29 12:30

>The <p> Tag ist closed before the List instead after,
>i removed the empty newline:

I can't help you with your problem but

<p class=3D"xxx">
<ul>
     <li>....
</ul>
</p>

is not valid HTML (lists can't be a part of paragraphs) so you=20
either need to find a way to create the first list you wrote or=20
perhaps change the CSS definitions (if possible) so no class=20
info is needed.

                 jem
--=20
Jan Erik Mostr=F6m, www.mostrom.pp.se

[Python-markdown-discuss] unordered list with id

[Werner H. <no...@li...>]

Hello,

i like to get the following HTML Code with Markdown:

<ul class="features">
	<li>Item 1</li>
	<li>Item 2</li>
</ul>

thats what i tried:

{@class=features}

* Item 1
* Item 2

But its not working and produce:

<p class="features">
</p>
<ul>
 <li>
     Item 1
 </li>

 <li>
     Item 2
 </li>
</ul>


The <p> Tag ist closed before the List instead after,
i removed the empty newline:

{@class=features}
* Item 1
* Item 2

and now:

<p class="features">
   <em> Item 1
</em> Item 2
</p>

I could life with the surrounding <p> tag, i just like to apply
css to the unordered list.

Any idea?

Regards,
Werner Hartnagel

-- 
       .-.________
  ----/ \_)_______)   Werner Hartnagel
     (    ()___)      Dotmagic Internet Solutions
          ()__)       Tel: +49-1801-5557774981
  ----\___()_)        Web: http://www.dotmagic.de

Re: [Python-markdown-discuss] Announcing the Abbreviation Extension

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

> Yuri,
> I tried to add this to the list on your site
> (http://www.freewisdom.org/projects/python-markdown/Available_Extensions),
> but get an ugly raw error message when I try logging in.

Yeah, I installed a buggy version and then took off to India.  So,
this might have to stay broken for a couple of weeks, since I can't
fix it from an Internet cafe...  The good news: there won't be any
wiki spam in my absence...

  - yuri

-- 
Yuri Takhteyev
http://www.freewisdom.org/

[Python-markdown-discuss] Announcing the Abbreviation Extension

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

I'm proud to announce the Abbreviation Extension for Python-Markdown
with some help by Seemant Kulleen. Any and all feedback is welcome.

Full announcement:
http://achinghead.com/archive/77/announcing-abbreviation-extension-python-markdown/
Project Page: http://achinghead.com/markdown/abbr/
Code: https://code.achinghead.com/browser/mdx/abbr/trunk/mdx_abbr.py

Yuri,
I tried to add this to the list on your site
(http://www.freewisdom.org/projects/python-markdown/Available_Extensions),
but get an ugly raw error message when I try logging in.

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

Re: [Python-markdown-discuss] Unicode errors with 1.6b rc2.

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

1.6b rc2 expects to get actual Unicode strings as arguments.  So, you
should get rid of .econde('utf-8') in your example:

    text = u'\r\n\u0c24\u0c46\u0c32\u0c41\u0c17\u0c41'
    print markdown.markdown(text)

If you read UTF8-encoded text from a file manually, you will need to
decode it.  Alternatively, there is a function markdownFromFile() that
accepts an input file path and the encoding, which will decode the
file for you.

BTW, for languages written right-to-left 1.6b rc2 now inserts
dir="rtl" attributes where necessary.

  - yuri

-- 
Yuri Takhteyev
UC Berkeley School of Information
http://www.freewisdom.org/

[Python-markdown-discuss] Unicode errors with 1.6b rc2.

[Anand <ana...@gm...>]

Markdown 1.6b rc2 doesn't seem to like unicode strings.

The following code works fine in 1.5, but doesn't work with 1.6b rc2.

import markdown
text = u'\r\n\u0c24\u0c46\u0c32\u0c41\u0c17\u0c41'
print markdown.markdown(text.encode('utf-8'))

Re: [Python-markdown-discuss] Overriding Functions, etc.

[Ben W. <da...@gm...>]

On 6/12/07, Yuri Takhteyev <qar...@gm...> wrote:
> This looks good.  It is however, tied to the question of how the
> processors work, so those two issues need to be discussed together.
> This implementation assumes that everything is text-in-text-out.

The assumption you cite is based on my implementation of that class.
What I offer is the core premise, of casually linking processor order
and heaping a final order. I realize the TITO is not how Markdown does
things and anticipate that you would make the relevant changes. I'm
familiar enough with how you wrote your implementation, but not enough
to presume to offer a turnkey solution. I snipped out later comments
where you tried to reconcile the difference. That is beyond my scope.
:-) However, based on your later commentary, I've decided to re-tool
what I offered so the resultant tool would be more universally
applicable.

> [...]
> Another thing: Part of your code seems to implement a general
> register-deregister-sort logic which would potentially be useful for
> things other than markdown.  Have you thought of wrapping it up into a
> separate module?

Actually, I have. After I posted the example to you, I noticed it
would be preferable to abstract it out. However, my abstraction was
still coupled to text manipulation. I believe I would remove the
"parse" function.

  This way inside python-markdown one would simply
> use:
>
>     import treeregistry  ## just making up a name for now
>
>     r = treeregistry.Registry()
>     r.register('fulltext','>_begin')
>     r.register('split','>fulltext')
>     ...
>     r.register('[[', 'links', r'(\[\[\s*(.*?)\]\])(s?)', make_link)
>     load_extension(r)
>     processors = r.get_sorted()
>
> Then from here on we just use a list of pre-sorted processors.

FWIW, I would suggest keeping with 'sorted' as the function name as it
is similar to the Python function of the same name. You know what I
mean, but to make sure I'm making my point, I'll explain. Using
.sort(), the list is sorted in place with None returned. Using
.sorted() returns a copy of the list, sorted. The original list
remains unsorted. So, to a Python programmer, r.sorted() should be
self-documenting without the 'get_' prefix.

But, your general point is valid. More importantly, you can get rid of
the regex reference altogether. The code bit below should be close to
how Python Markdown could use it.

    link_processor = (r'\[\[(.*?)\]\]', make_link)
    r.register('[[','links',link_procssor)

Then, the register is absolutely agnostic. Your local use would
extract the ordered list of tuples. Perhaps I could have a local use
that extracted an ordered list of objects. Oh, crap; this just solved
a sort issue I gave up on last Fall!

I'll re-tool the code to be agnostic and post it later today or tomorrow.

-- 
Ben Wilson
"Words are the only thing which will last forever" Churchill

Re: [Python-markdown-discuss] Overriding Functions, etc.

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

This looks good.  It is however, tied to the question of how the
processors work, so those two issues need to be discussed together.
This implementation assumes that everything is text-in-text-out.
While it is possible to do it this way (that's how Markdown.pl works,
if I remember correctly), I think it will get pretty ugly if we try to
do structural markup this way.  But looking at your code I am starting
to wonder if perhaps the thing to do is to strike a compromise and
work with a tree at the structural level, while using regexp
substitution for the low-level markup.  This way, some handlers can
return text but others can return a tree node:

    "__...__" -> returns "<em>...</em>"
    "## Title" -> returns a tree node for "H2", having applied the remaining
            handlers recursively to the text node of the child.

I will try to think about this more next weekend.

Another thing: Part of your code seems to implement a general
register-deregister-sort logic which would potentially be useful for
things other than markdown.  Have you thought of wrapping it up into a
separate module?  This way inside python-markdown one would simply
use:

    import treeregistry  ## just making up a name for now

    r = treeregistry.Registry()
    r.register('fulltext','>_begin')
    r.register('split','>fulltext')
    ...
    r.register('[[', 'links', r'(\[\[\s*(.*?)\]\])(s?)', make_link)
    load_extension(r)
    processors = r.get_sorted()

Then from here on we just use a list of pre-sorted processors.

  - yuri

On 6/10/07, Ben Wilson <da...@gm...> wrote:
> Yuri,
>
> Here is code demonstrating what I am referring to. I created a file
> called 'src' which contained a snippet of marked up text, which was
> converted into HTML. Perhaps the merits are clearer, and you'll be
> able to adjust Markdown to use this processor organizer. Both are the
> same, but I believe the latter is optimized.
>
> http://dausha.net/parse.py.txt
> http://dausha.net/heap.py.txt
>
> Ben Wilson
>
>
> On 6/9/07, Yuri Takhteyev <qar...@gm...> wrote:
> > I am sorry I didn't follow up on this thread it.  It came at a time
> > when I was super busy and I then didn't get around to going back to
> > it, though it's been on the back of my mind.
> >
> > I am willing to discuss the question of how post and pre-processing is
> > organized, even if some of the solutions are not going to be backwards
> > compatible.  I wouldn't want to make such changes on a whim, but we
> > can start thinking of version "2.0", which could potentially be quite
> > different.  I am not sure I will attempt to do a radical redesign on
> > my own, but if there are other people interested, we could do it as a
> > community project.
> >
> > Ben, can you send us a more detailed explanation of your proposal?
> >
> > However, if we start talking about a radical change ("2.0"), then i
> > think we also need to talk about a more serious architectural problem,
> > which is the uncomfortable mix of regular expressions and dom trees.
> > The current parser is based on regular expressions, once a regular
> > expression is applied we typically break the string in half, which
> > prevents us from matching later regular expressions.  E.g.: we start
> > with "**[foo](x.html)**", and match the link pattern.  This gives us a
> > list ["**", DOM_FRAGMENT, "**"].  We now can't match the "**...**"
> > now.
> >
> > I've thought of a few possible solutions for it:
> >
> > 1. Ditch the DOM and just do a bunch of strings-to-strings
> > transformation.  This might be the most straigh-forward solution, but
> > very un-pythonic and not something I would be interested in doing
> > personally.
> >
> > 2. Write a special data structure that can behave as a list or tree of
> > DOM fragments while also fitting with the current RE library.  One way
> > to do that would be to represent the half-parsed document as a string
> > and a list of DOM nodes, where the string would have placeholders for
> > the DOM nodes.  In this case, instead of ["**", DOM_FRAGMENT, "**"] we
> > would have an object with fields str = "**\x0**", doms =
> > [DOM_FRAGMENT].  We could then run doc.str through regular expression,
> > check if any part of the match contains the placeholders, then work
> > out the details.
> >
> > 3. Switch to some other method of parsing.  Maybe something from this
> > list: http://nedbatchelder.com/text/python-parsers.html
> >
> > Note that if we go for #3, then the whole preprocessors/postprocessors
> > thing would end up looking very different.
> >
> >   - yuri
> >
> > On 6/8/07, Ben Wilson <da...@gm...> wrote:
> > > It's been a while since we discussed this (April), but I thought I'd
> > > come back. I've looked at how PmWiki organizes the various markups as
> > > compared to Markdown.
> > >
> > > In response to my statement that PmWiki had an elegant, ad-hoc method
> > > for adding new markup, Waylan said: "And not very pythonic. I remember
> > > the first time I realized how PmWiki did some very OO like things
> > > without OO code. For PHP it was amazing -
> > > and a pleasure to work with. Especially considering PHP's OO sytax. Uhg!"
> > >
> > > I've since taken the time to analyze how Patrick Michaud accomplished
> > > this. Quite simply, he uses a hash-of-hashes to organize markup
> > > relative to other markup (e.g., Strong before Emphasis). At
> > > parse-time, he then passes this H-o-H through a custom heap algorithm
> > > to divine the absolute parse order. I re-implemented his solution in
> > > Python. It is very Pythonic since his custom heap exists in Python's
> > > heapq library. This means the sorting is likely optimized in C. I
> > > think Waylan "failed to see the forest for all of the trees" because
> > > he allowed the confines of PHP to conceal the simple elegance of the
> > > solution.
> > >
> > > He also focused on the big-picture, which was PmWiki, and did not see
> > > the small facet I was focusing on, which was markup management. What
> > > Patrick solved was how to allow a developer simply to insert new
> > > markup into a markup tree. Rather than extend the class, or mess with
> > > the internals of class Markdown, Patrick's solution allows flexibility
> > > in the class. The way Markdown is now, in order for me to add some
> > > behavior I wanted, I had to tinker with Markdown class' internals.
> > > Now, to add markup, all I need to do is tell my parser that I want it
> > > to occur during inline, or even that it must occur before Emphasis.
> > > Thus, for a wiki engine that allows developers to insert/change markup
> > > by plug-in, the process is very OO. There's a reason Patrick is a PhD.
> > > While PHP is inelegant, and Patrick's code is sometimes confusing, I
> > > am constantly amazed at how he solves problems.
> > >
> > > I invite you to consider PmWiki's Markup engine (specifically function
> > > Markup(); and BuildMarkupRules();) The former instructs on how to
> > > extend markup ad-hoc. The latter instructs how to take the resulting
> > > heap and build a parse tree.
> > >
> > > The only problem would be implementing this would not be backward
> > > compatible. But, this is Pythonic as well, as the BDFL willingly
> > > disregards tradition when warranted. It is not backward compatible
> > > because it totally dismisses the present mechanism for ordering
> > > markup. However, I think the gains are worth the cost.
> > >
> > > Warm Regards,
> > > Ben Wilson
> > >
> > > On 4/10/07, Yuri Takhteyev <qar...@gm...> wrote:
> > > > Just wanted to let you guys know that I am reading this, but don't
> > > > have time to think about it seriously and respond this week.  However,
> > > > from what I see so far, I think Ben identified a real problem and I
> > > > would love it if you guys could come up with a solution that addresses
> > > > most of the points that have been brought up so far.
> > > >
> > > > Ideally, this solution would maintain backwards compatibility with
> > > > existing extensions.  If not, we can still put it in, but we'll have
> > > > to think more carefully of when to release it and whether there should
> > > > be a more general upgrade of how the extension mechanism works.
> > > > (I.e., I think it's ok to change the extension framework once, but not
> > > > every day.)
> > > >
> > > >   - yuri
> > > >
> > > > On 4/10/07, Waylan Limberg <wa...@gm...> wrote:
> > > > >
> > > > >
> > > > > Ben Wilson wrote:
> > > > > [snip]
> > > > > > PmWiki has a situation where markups may be added willy-nilly while
> > > > > > maintaining order. It would be rather radical to introduce to
> > > > > > Markdown().
> > > > >
> > > > > And not very pythonic. I remember the first time I realized how PmWiki
> > > > > did some very OO like things without OO code. For PHP it was amazing -
> > > > > and a pleasure to work with. Especially considering PHP's OO sytax. Uhg!
> > > > >
> > > > > But if one tried to use PmWiki's approach in python, it would probably
> > > > > be more work than it's worth. A subclass of dict which maintains order
> > > > > or a class wrapping a list of tuples would be much less effort -- and
> > > > > more pythonic. For that matter, it wouldn't all that difficult to build
> > > > > a class from scratch for such a purpose.
> > > > >
> > > > > [snip]
> > > > > > want the conversion to occur before/after/during another item. I
> > > > > > mention PmWiki only because I'm very familiar with its approach and
> > > > > > know its author seeks ease-of-customization. Markdown() generally does
> > > > > > not mean to be as customizable as it follows the Markdown standard
> > > > > > format.
> > > > >
> > > > > Ahh, now I know why your name seemed so familiar. Although I've been out
> > > > > of the (PmWIki) loop for about a year now. It is true that Markdown does not
> > > > > come close to PmWiki. If you're looking for more power, perhaps you
> > > > > should look at reStructuredText [1]. It seems to be the python default
> > > > > for markup, is easily extendable [2], and will output LaTex [3].
> > > > > Personally, I prefer Markdown for its simplicity, but you seem to want
> > > > > power which brings more complexity. Imo, using an establish markup
> > > > > language (rest) is better than building your own custom creation.
> > > > >
> > > > > [1]: http://docutils.sourceforge.net/rst.html
> > > > > [2]: http://docutils.sourceforge.net/docs/howto/rst-directives.html
> > > > > [3]: http://docutils.sourceforge.net/docs/user/latex.html
> > > > >
> > > > > --
> > > > > Waylan Limberg
> > > > > wa...@gm...
> > > > >
> > > > > -------------------------------------------------------------------------
> > > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > > > > opinions on IT & business topics through brief surveys-and earn cash
> > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > > _______________________________________________
> > > > > Python-markdown-discuss mailing list
> > > > > Pyt...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> > > > >
> > > >
> > > >
> > > > --
> > > > Yuri Takhteyev
> > > > UC Berkeley School of Information
> > > > http://www.freewisdom.org/
> > > >
> > > > -------------------------------------------------------------------------
> > > > Take Surveys. Earn Cash. Influence the Future of IT
> > > > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > > > opinions on IT & business topics through brief surveys-and earn cash
> > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > > _______________________________________________
> > > > Python-markdown-discuss mailing list
> > > > Pyt...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> > > >
> > >
> > >
> > > --
> > > Ben Wilson
> > > "Words are the only thing which will last forever" Churchill
> > >
> >
> >
> > --
> > Yuri Takhteyev
> > UC Berkeley School of Information
> > http://www.freewisdom.org/
> >
>
>
> --
> Ben Wilson
> "Words are the only thing which will last forever" Churchill
>


-- 
Yuri Takhteyev
UC Berkeley School of Information
http://www.freewisdom.org/

Re: [Python-markdown-discuss] Escaping HTML instead of removing it ?

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

You should be able to do this with a preprocessor by simply
pre-escaping all HTML, no?  Alternatively, if you want a quick and
dirty hack, look for the line that says:

    if self.safeMode and html != "<hr />" and html != "<br />":
                    html = HTML_REMOVED_TEXT

I do agree though that perhaps escaping html would be a better
default.  (Please do file a bug on sourceforge so that I don't forget
to make this change later.)  In the long term, perhaps, the new and
more flexible way of managing pre-post-etc-processors would solve this
problem as well.

> implementation removes HTML . (like why HTML is escaped in code blocks
> and not fully removed) ..

An oversight on my part...

> P.S.: @Yuri Takhteyev: i guess you don't really care any more since
> you've already put up a wiki .. but anyway .. http://sct.sphene.net/
> is my wiki based on python-markdown (and django)

I will stick with what I installed, but I do _care_ - it's good to
have a Wiki based this module.   Please add your project to the wiki
under "Related Projects".

  - yuri

-- 
http://www.freewisdom.org/

[Python-markdown-discuss] Escaping HTML instead of removing it ?

[Herbert P. <her...@gm...>]

Hi,

Is it somehow possible to not remove HTML but instead escape it with
html entities ? this seems to be a much more user friendly way for
wikis to deal with HTML.

i tried to simply put in a pre processor, but had no luck yet..
basically because i'm not sure if i fully understand how the current
implementation removes HTML . (like why HTML is escaped in code blocks
and not fully removed) ..

is there an easy way to do this ?


thanks & cu,
  herbert


P.S.: @Yuri Takhteyev: i guess you don't really care any more since
you've already put up a wiki .. but anyway .. http://sct.sphene.net/
is my wiki based on python-markdown (and django)

Re: [Python-markdown-discuss] Overriding Functions, etc.

[Ben W. <da...@gm...>]

I need to modify something I said. There is no need to use Python's
hashq I managed to reduce the sort to a nested array assignment.

On 6/9/07, Yuri Takhteyev <qar...@gm...> wrote:

> Ben, can you send us a more detailed explanation of your proposal?

I propose a different, flexible method for prioritizing markup
processing. This method has no effect on pattern matching/substitution
(i.e., processors); so the DOM method you're using remains intact.
While I personally prefer the string-to-string substitution, what is
proposed is agnostic to how markup is processed. So, what I propose is
a new organizer for the processors, not a new way to process.

For example, preprocessors are ordered in an array: self.preprocessor.
Postprocessors are likewise ordered. There are other similar
"buckets." If I wanted to insert a preprocessor between two standard
preprocessors (e.g. HTML_BLOCK, and LINE_BREAKS), then I have to
manipulate the array.

PmWiki's organizer is flexible. Each processor is named (dictionary or
associative array-based). Each processor announces when it should be
processed: before another processor, after another processor, or
generally within a processor group. For example, if STRONG must occur
before EMPHASIS, then we have:

    p.register('strong','<emphasis,...)

If, alternatively, STRONG must occur _after_ EMPHASIS, then we have:

    p.register('strong','>emphasis,...)

Finally, if we only want STRONG to occur at the same time as other
inline processors, then we have:

    p.register('strong','inline',...)

Replacing a processor is as easy as re-registering it. You can also
deregister a processor.

As we all know, dictionary elements are not ordered. The problem of
order would exist even if dictionaries were ordered. This is because
it is possible to register a new processor at any time before parsing
begins and properly ordering in any language's associative array would
be a royal pain. Patrick provides a solution in his code: have each
processor register its relative order via a heap algorithm. When the
heap is sorted at parse-time, the relationships between various
markups resolves to the final process order.

I believe this organizer is more OO than the current Markdown
implementation. Mind you, I come from a couple decades of functional
programming so my understanding of OO is hard-earned. I believe a
proper class avoids having to manipulate its internal structure.
Having to play with self.preprocessor to add

You would add another class to the Markdown suite: "Parser." This
class would have the following methods: register, deregister, sorted,
and parse. The first two should be self-descriptive. Sorted() would
build an array which properly orders the keys for the registered
processors. Parse would receive the markdowned text and convert that
text into HTML.

None Parser.register(key, where, pattern, replacement, constants(e.g. re.M))

None Parser.deregister(key or [keys])

List Parser.sorted()

html_text Parser.parse(markdown_text)

-- 
Ben Wilson
"Words are the only thing which will last forever" Churchill

Re: [Python-markdown-discuss] Overriding Functions, etc.

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

I am sorry I didn't follow up on this thread it.  It came at a time
when I was super busy and I then didn't get around to going back to
it, though it's been on the back of my mind.

I am willing to discuss the question of how post and pre-processing is
organized, even if some of the solutions are not going to be backwards
compatible.  I wouldn't want to make such changes on a whim, but we
can start thinking of version "2.0", which could potentially be quite
different.  I am not sure I will attempt to do a radical redesign on
my own, but if there are other people interested, we could do it as a
community project.

Ben, can you send us a more detailed explanation of your proposal?

However, if we start talking about a radical change ("2.0"), then i
think we also need to talk about a more serious architectural problem,
which is the uncomfortable mix of regular expressions and dom trees.
The current parser is based on regular expressions, once a regular
expression is applied we typically break the string in half, which
prevents us from matching later regular expressions.  E.g.: we start
with "**[foo](x.html)**", and match the link pattern.  This gives us a
list ["**", DOM_FRAGMENT, "**"].  We now can't match the "**...**"
now.

I've thought of a few possible solutions for it:

1. Ditch the DOM and just do a bunch of strings-to-strings
transformation.  This might be the most straigh-forward solution, but
very un-pythonic and not something I would be interested in doing
personally.

2. Write a special data structure that can behave as a list or tree of
DOM fragments while also fitting with the current RE library.  One way
to do that would be to represent the half-parsed document as a string
and a list of DOM nodes, where the string would have placeholders for
the DOM nodes.  In this case, instead of ["**", DOM_FRAGMENT, "**"] we
would have an object with fields str = "**\x0**", doms =
[DOM_FRAGMENT].  We could then run doc.str through regular expression,
check if any part of the match contains the placeholders, then work
out the details.

3. Switch to some other method of parsing.  Maybe something from this
list: http://nedbatchelder.com/text/python-parsers.html

Note that if we go for #3, then the whole preprocessors/postprocessors
thing would end up looking very different.

  - yuri

On 6/8/07, Ben Wilson <da...@gm...> wrote:
> It's been a while since we discussed this (April), but I thought I'd
> come back. I've looked at how PmWiki organizes the various markups as
> compared to Markdown.
>
> In response to my statement that PmWiki had an elegant, ad-hoc method
> for adding new markup, Waylan said: "And not very pythonic. I remember
> the first time I realized how PmWiki did some very OO like things
> without OO code. For PHP it was amazing -
> and a pleasure to work with. Especially considering PHP's OO sytax. Uhg!"
>
> I've since taken the time to analyze how Patrick Michaud accomplished
> this. Quite simply, he uses a hash-of-hashes to organize markup
> relative to other markup (e.g., Strong before Emphasis). At
> parse-time, he then passes this H-o-H through a custom heap algorithm
> to divine the absolute parse order. I re-implemented his solution in
> Python. It is very Pythonic since his custom heap exists in Python's
> heapq library. This means the sorting is likely optimized in C. I
> think Waylan "failed to see the forest for all of the trees" because
> he allowed the confines of PHP to conceal the simple elegance of the
> solution.
>
> He also focused on the big-picture, which was PmWiki, and did not see
> the small facet I was focusing on, which was markup management. What
> Patrick solved was how to allow a developer simply to insert new
> markup into a markup tree. Rather than extend the class, or mess with
> the internals of class Markdown, Patrick's solution allows flexibility
> in the class. The way Markdown is now, in order for me to add some
> behavior I wanted, I had to tinker with Markdown class' internals.
> Now, to add markup, all I need to do is tell my parser that I want it
> to occur during inline, or even that it must occur before Emphasis.
> Thus, for a wiki engine that allows developers to insert/change markup
> by plug-in, the process is very OO. There's a reason Patrick is a PhD.
> While PHP is inelegant, and Patrick's code is sometimes confusing, I
> am constantly amazed at how he solves problems.
>
> I invite you to consider PmWiki's Markup engine (specifically function
> Markup(); and BuildMarkupRules();) The former instructs on how to
> extend markup ad-hoc. The latter instructs how to take the resulting
> heap and build a parse tree.
>
> The only problem would be implementing this would not be backward
> compatible. But, this is Pythonic as well, as the BDFL willingly
> disregards tradition when warranted. It is not backward compatible
> because it totally dismisses the present mechanism for ordering
> markup. However, I think the gains are worth the cost.
>
> Warm Regards,
> Ben Wilson
>
> On 4/10/07, Yuri Takhteyev <qar...@gm...> wrote:
> > Just wanted to let you guys know that I am reading this, but don't
> > have time to think about it seriously and respond this week.  However,
> > from what I see so far, I think Ben identified a real problem and I
> > would love it if you guys could come up with a solution that addresses
> > most of the points that have been brought up so far.
> >
> > Ideally, this solution would maintain backwards compatibility with
> > existing extensions.  If not, we can still put it in, but we'll have
> > to think more carefully of when to release it and whether there should
> > be a more general upgrade of how the extension mechanism works.
> > (I.e., I think it's ok to change the extension framework once, but not
> > every day.)
> >
> >   - yuri
> >
> > On 4/10/07, Waylan Limberg <wa...@gm...> wrote:
> > >
> > >
> > > Ben Wilson wrote:
> > > [snip]
> > > > PmWiki has a situation where markups may be added willy-nilly while
> > > > maintaining order. It would be rather radical to introduce to
> > > > Markdown().
> > >
> > > And not very pythonic. I remember the first time I realized how PmWiki
> > > did some very OO like things without OO code. For PHP it was amazing -
> > > and a pleasure to work with. Especially considering PHP's OO sytax. Uhg!
> > >
> > > But if one tried to use PmWiki's approach in python, it would probably
> > > be more work than it's worth. A subclass of dict which maintains order
> > > or a class wrapping a list of tuples would be much less effort -- and
> > > more pythonic. For that matter, it wouldn't all that difficult to build
> > > a class from scratch for such a purpose.
> > >
> > > [snip]
> > > > want the conversion to occur before/after/during another item. I
> > > > mention PmWiki only because I'm very familiar with its approach and
> > > > know its author seeks ease-of-customization. Markdown() generally does
> > > > not mean to be as customizable as it follows the Markdown standard
> > > > format.
> > >
> > > Ahh, now I know why your name seemed so familiar. Although I've been out
> > > of the (PmWIki) loop for about a year now. It is true that Markdown does not
> > > come close to PmWiki. If you're looking for more power, perhaps you
> > > should look at reStructuredText [1]. It seems to be the python default
> > > for markup, is easily extendable [2], and will output LaTex [3].
> > > Personally, I prefer Markdown for its simplicity, but you seem to want
> > > power which brings more complexity. Imo, using an establish markup
> > > language (rest) is better than building your own custom creation.
> > >
> > > [1]: http://docutils.sourceforge.net/rst.html
> > > [2]: http://docutils.sourceforge.net/docs/howto/rst-directives.html
> > > [3]: http://docutils.sourceforge.net/docs/user/latex.html
> > >
> > > --
> > > Waylan Limberg
> > > wa...@gm...
> > >
> > > -------------------------------------------------------------------------
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > > opinions on IT & business topics through brief surveys-and earn cash
> > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > > _______________________________________________
> > > Python-markdown-discuss mailing list
> > > Pyt...@li...
> > > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> > >
> >
> >
> > --
> > Yuri Takhteyev
> > UC Berkeley School of Information
> > http://www.freewisdom.org/
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Python-markdown-discuss mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> >
>
>
> --
> Ben Wilson
> "Words are the only thing which will last forever" Churchill
>


-- 
Yuri Takhteyev
UC Berkeley School of Information
http://www.freewisdom.org/

Re: [Python-markdown-discuss] Overriding Functions, etc.

[Ben W. <da...@gm...>]

It's been a while since we discussed this (April), but I thought I'd
come back. I've looked at how PmWiki organizes the various markups as
compared to Markdown.

In response to my statement that PmWiki had an elegant, ad-hoc method
for adding new markup, Waylan said: "And not very pythonic. I remember
the first time I realized how PmWiki did some very OO like things
without OO code. For PHP it was amazing -
and a pleasure to work with. Especially considering PHP's OO sytax. Uhg!"

I've since taken the time to analyze how Patrick Michaud accomplished
this. Quite simply, he uses a hash-of-hashes to organize markup
relative to other markup (e.g., Strong before Emphasis). At
parse-time, he then passes this H-o-H through a custom heap algorithm
to divine the absolute parse order. I re-implemented his solution in
Python. It is very Pythonic since his custom heap exists in Python's
heapq library. This means the sorting is likely optimized in C. I
think Waylan "failed to see the forest for all of the trees" because
he allowed the confines of PHP to conceal the simple elegance of the
solution.

He also focused on the big-picture, which was PmWiki, and did not see
the small facet I was focusing on, which was markup management. What
Patrick solved was how to allow a developer simply to insert new
markup into a markup tree. Rather than extend the class, or mess with
the internals of class Markdown, Patrick's solution allows flexibility
in the class. The way Markdown is now, in order for me to add some
behavior I wanted, I had to tinker with Markdown class' internals.
Now, to add markup, all I need to do is tell my parser that I want it
to occur during inline, or even that it must occur before Emphasis.
Thus, for a wiki engine that allows developers to insert/change markup
by plug-in, the process is very OO. There's a reason Patrick is a PhD.
While PHP is inelegant, and Patrick's code is sometimes confusing, I
am constantly amazed at how he solves problems.

I invite you to consider PmWiki's Markup engine (specifically function
Markup(); and BuildMarkupRules();) The former instructs on how to
extend markup ad-hoc. The latter instructs how to take the resulting
heap and build a parse tree.

The only problem would be implementing this would not be backward
compatible. But, this is Pythonic as well, as the BDFL willingly
disregards tradition when warranted. It is not backward compatible
because it totally dismisses the present mechanism for ordering
markup. However, I think the gains are worth the cost.

Warm Regards,
Ben Wilson

On 4/10/07, Yuri Takhteyev <qar...@gm...> wrote:
> Just wanted to let you guys know that I am reading this, but don't
> have time to think about it seriously and respond this week.  However,
> from what I see so far, I think Ben identified a real problem and I
> would love it if you guys could come up with a solution that addresses
> most of the points that have been brought up so far.
>
> Ideally, this solution would maintain backwards compatibility with
> existing extensions.  If not, we can still put it in, but we'll have
> to think more carefully of when to release it and whether there should
> be a more general upgrade of how the extension mechanism works.
> (I.e., I think it's ok to change the extension framework once, but not
> every day.)
>
>   - yuri
>
> On 4/10/07, Waylan Limberg <wa...@gm...> wrote:
> >
> >
> > Ben Wilson wrote:
> > [snip]
> > > PmWiki has a situation where markups may be added willy-nilly while
> > > maintaining order. It would be rather radical to introduce to
> > > Markdown().
> >
> > And not very pythonic. I remember the first time I realized how PmWiki
> > did some very OO like things without OO code. For PHP it was amazing -
> > and a pleasure to work with. Especially considering PHP's OO sytax. Uhg!
> >
> > But if one tried to use PmWiki's approach in python, it would probably
> > be more work than it's worth. A subclass of dict which maintains order
> > or a class wrapping a list of tuples would be much less effort -- and
> > more pythonic. For that matter, it wouldn't all that difficult to build
> > a class from scratch for such a purpose.
> >
> > [snip]
> > > want the conversion to occur before/after/during another item. I
> > > mention PmWiki only because I'm very familiar with its approach and
> > > know its author seeks ease-of-customization. Markdown() generally does
> > > not mean to be as customizable as it follows the Markdown standard
> > > format.
> >
> > Ahh, now I know why your name seemed so familiar. Although I've been out
> > of the (PmWIki) loop for about a year now. It is true that Markdown does not
> > come close to PmWiki. If you're looking for more power, perhaps you
> > should look at reStructuredText [1]. It seems to be the python default
> > for markup, is easily extendable [2], and will output LaTex [3].
> > Personally, I prefer Markdown for its simplicity, but you seem to want
> > power which brings more complexity. Imo, using an establish markup
> > language (rest) is better than building your own custom creation.
> >
> > [1]: http://docutils.sourceforge.net/rst.html
> > [2]: http://docutils.sourceforge.net/docs/howto/rst-directives.html
> > [3]: http://docutils.sourceforge.net/docs/user/latex.html
> >
> > --
> > Waylan Limberg
> > wa...@gm...
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys-and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Python-markdown-discuss mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> >
>
>
> --
> Yuri Takhteyev
> UC Berkeley School of Information
> http://www.freewisdom.org/
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


-- 
Ben Wilson
"Words are the only thing which will last forever" Churchill

Re: [Python-markdown-discuss] future changes for markdown

[Sam's L. <sam...@gm...>]

>
>
> > On a side note, what version of python are you targeting? It'd be nice
> > if it were 2.3 and above. We could replace some amount of code with some
> > standard libraries, such as logging.
>
> I've been trying to keep it running with earlier versions too, but
> maybe it's time to abandon them.  What do others think?



Personally, I think it would be fine to only support Python 2.4 and above.
:)

[Python-markdown-discuss] a wiki for the project

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

I set up a wiki for the project, at the same URL where the old site
was (http://www.freewisdom.org/projects/python-markdown/)  Feel free
to contribute.

I ended up using a wiki I've been working on lately (which is part of
the reason there has been little work on this script), which uses
Markdown, but is in Lua rather than Python, so it uses somebody else's
markdown library.

  - yuri

-- 
Yuri Takhteyev
UC Berkeley School of Information
http://www.freewisdom.org/