python-markdown-discuss Mailing List for Python Markdown (Page 40)

I'm pleased to announce the first public release of gizmo(qp).

Gizmo extends the QP Web Framework adding functionality to help with 
building rich and exacting web interfaces. One of the nice things is 
that templates used by the Gti Skin (mentioned below) may also be 
specified in markdown.

Key gizmo(qp) features include:

- Unburden pages from the tasks of access control, templating, and 
generation of contextual (where, who) navigational data. These are 
taken care of independently & externally from the page.

- A DHTML Information class, that is contributed to by all participants 
of a response, making complex DHTML pages easier to build and debug.

- Gizmos, that are user interface objects with client-side behaviour 
and interaction. The gizmo api is a simple pattern for encapsulating 
user interface objects that know how to cooperatively participate in 
the page generation process.

- Gizmo Form, that supports automatic generation of redundant 
client-side field validation as well as an additional json callback for 
a field (when the field's validation logic requires server-side 
business logic or data). A by-product of Gizmo Form is a simplified 
JavaScript version of the generic spec python module, included in QP.

- Skins, in particular the GTi Skin, that supports format-agnostic 
template files that may embed python expressions. GTi templates may 
also liberally pull() in bits and pieces of other templates (or content 
files, source code, or any textual source). This feature is really 
handy for technical sites, with content that makes frequent references 
to *live* code.

- Built-in Form Login, User Registration, and User Admin facilities.

- Comprehensive demo, also available live.

URL: http://gizmojo.org/

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/

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

On 4/10/07, Waylan Limberg <wa...@gm...> wrote:
[...]
> > I was thinking that _perhaps_ the pre-processors could be a dictionary
> > instead of an array, which would allow deleting by name. Presently, I
> > set all the preprocessors by copying from the class, then delete the
> > one preprocessor I don't want. This would also allow use of has_key(),
> > as the present implementation (correct me if I'm wrong) does not allow
> > listing or deleting a preprocessor directly.
>
> This seems like a good idea until we remember that dictionaries do not
> preserve order. In this case, order is very important, as certain
> pre-processors must absolutely be run before others. That's imposable
> with a dictionary. With a little searching you'll find that various
> projects have implemented their own non-standard sorted-dict to address
> this issue, but every implementation is a little different. Another
> possibility could be a list of tuples [(key, value), (key. value)], but
> that can be a pain to work with. That is why a simple list is used.
> Currently is is easy enough to refer to each item by its index, but if
> you're making multiple changes, I can see how that could be problematic.

Right, dict is not sequenced, but there are a couple ways off-hand
that might work.

def PreprocessorInsert(key, val, index=-1):
  self.preprocessors[key] = value
  self.preprocessors_order.insert(key, index)

then when running preprocessors:
   for key in self.preprocessors_order:
       pre = self.preprocessor[key]

PmWiki has a situation where markups may be added willy-nilly while
maintaining order. It would be rather radical to introduce to
Markdown(). I'll try to describe it as best I can as there are two
ways to position markups: by group and relative to other markups.
First, the basic syntax for adding markup is:

Markup('name','phase','regex','substitute')

* Name refers to the key value of the regex, which allows a standard
markup to be overridden by custom markup, and easy identification.
* Phase refers to position either by category (e.g. preprocessor,
inline, postprocessor) or relationally (e.g. '<##' would occur before
'##'; '<inline' would essentially have it occur before all other
inlines. The '##' is the name of the markup it precedes (otherwise the
phase), not the markup itself,)
* Regex is self-explanatory.
* Substitution is self-explanatory, and it can either be text or function.

The code does the shuffling before text conversion. This has the
advantage of not needing to know the sequence per se, only that you
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.

[...]
> > Perhaps the example given could be an actual
> > implementation of a simple preprocessor?
>
> Generally the footnote extension is referred to as an example as it uses
> all three methods of adding extensions (pre-precessors, patterns, and
> post-processors).

Thanks!

Hi Ben,

Ben Wilson wrote:
> I'm currently playing with a Python-based flat-file wiki that relies
> on Markdown syntax (mostly). This is more for my education as I
> understand MoinMoin is the premier wiki-engine for Python and it seems
> to support some Markdown markup.[1] So, I've made a few observations
> that I'm trying to explain here.
> 
> I would like to say the Python-Markdown class is great. I like being
> able to extend it. For example, I have a different way of handling the
> ==== and ---- headings that encourages me to short-circuit the
> headings_preprocessor. The reason for my short-circuiting is that I
> order headers differently and include ++++ and ~~~~, and the
> preprocessor presupposes that a section heading (====) should be
> <h1>.[2] I'm able to get both lines of a heading (the title and
> markup) by a regex without lookaheads, but it may not be stable.
> 
> I would also like to change the output to Tex/LaTeX format if possible.

I've thought about that as well. Currently, most of the output is stored 
in a minidom instance (the exception being raw htmlblocks). I suppose it 
could be possible to extend the minidom class to output different 
formats, but I haven't looked into it. Perhaps if python-markdown didn't 
use it's own custom minidom class, but one of the more common python dom 
modules, this would be easier (code might already exist). I don't know 
what Yuri's thought about this would be.
> 
> I was thinking that _perhaps_ the pre-processors could be a dictionary
> instead of an array, which would allow deleting by name. Presently, I
> set all the preprocessors by copying from the class, then delete the
> one preprocessor I don't want. This would also allow use of has_key(),
> as the present implementation (correct me if I'm wrong) does not allow
> listing or deleting a preprocessor directly.

This seems like a good idea until we remember that dictionaries do not 
preserve order. In this case, order is very important, as certain 
pre-processors must absolutely be run before others. That's imposable 
with a dictionary. With a little searching you'll find that various 
projects have implemented their own non-standard sorted-dict to address 
this issue, but every implementation is a little different. Another 
possibility could be a list of tuples [(key, value), (key. value)], but 
that can be a pain to work with. That is why a simple list is used. 
Currently is is easy enough to refer to each item by its index, but if 
you're making multiple changes, I can see how that could be problematic.
> 
> I'm also having a bit of a problem with the documentation. I'm used to
> an "undue experimentation" rule for documentation. This means that a
> programmer should be able to look to the documentation alone to
> explain _how_ to use the class---such as adding a preprocessor. I
> ended up having to look in the class itself to see how it added a
> preprocessor. Perhaps the example given could be an actual
> implementation of a simple preprocessor?

Generally the footnote extension is referred to as an example as it uses 
all three methods of adding extensions (pre-precessors, patterns, and 
post-processors).

> 
> FWIW, I am adding some non-Markdown syntax that is more expected in
> wiki markup (e.g. [[free links]]
> 
> Anyway, thanks for a great Markdown class. It moved my development of
> my wiki up by about three weekends.
> 

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

I'm currently playing with a Python-based flat-file wiki that relies
on Markdown syntax (mostly). This is more for my education as I
understand MoinMoin is the premier wiki-engine for Python and it seems
to support some Markdown markup.[1] So, I've made a few observations
that I'm trying to explain here.

I would like to say the Python-Markdown class is great. I like being
able to extend it. For example, I have a different way of handling the
==== and ---- headings that encourages me to short-circuit the
headings_preprocessor. The reason for my short-circuiting is that I
order headers differently and include ++++ and ~~~~, and the
preprocessor presupposes that a section heading (====) should be
<h1>.[2] I'm able to get both lines of a heading (the title and
markup) by a regex without lookaheads, but it may not be stable.

I would also like to change the output to Tex/LaTeX format if possible.

I was thinking that _perhaps_ the pre-processors could be a dictionary
instead of an array, which would allow deleting by name. Presently, I
set all the preprocessors by copying from the class, then delete the
one preprocessor I don't want. This would also allow use of has_key(),
as the present implementation (correct me if I'm wrong) does not allow
listing or deleting a preprocessor directly.

I'm also having a bit of a problem with the documentation. I'm used to
an "undue experimentation" rule for documentation. This means that a
programmer should be able to look to the documentation alone to
explain _how_ to use the class---such as adding a preprocessor. I
ended up having to look in the class itself to see how it added a
preprocessor. Perhaps the example given could be an actual
implementation of a simple preprocessor?

FWIW, I am adding some non-Markdown syntax that is more expected in
wiki markup (e.g. [[free links]]

Anyway, thanks for a great Markdown class. It moved my development of
my wiki up by about three weekends.

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

[1]: Why Python? I am already a strong Perl and PHP programmer, and
I'm trying to extend my language skills.

[2]: The only <h1> I have on the page is the page title. This means
section headings (====) are <h2>; sub-sections (----) <h3>; paragraph
headings (~~~~) is <h4> and sub-paragraph headings (++++) are <h5>. I
never use <h6>. The use of <h1> as a page is based on some older web
standard that's been around for a while that I am never able to find
when I want to cite to it.

Another thing regarding the test suite:

If any of you have written extensions that are compatible with the 1.6
extention format ("mdx_..."), please send me a link to your extension
and a test case.  I'll then drop those in my test so that I could do
my best to not break extensions with this or future releases.

  - yuri

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

There is a new version of the script in svn, fixing a few issues that
were introduced by the bug fixes, plus a few new things that came up.
I also added a test suite, and did a regression test relative to 1.6a
through many of the nasty edge cases that people have been sending to
me.  (Before that I was using the Gruber's test suite, which however
doesn't test quite as many cases.)  If you have any of your favorite
edge cases - including the ones that already work in 1.6a - send them
to me so that I could include them in the text suite.

Also, not sure if any of you are into that sort of stuff, but the
latest version now has support for bidirectional text (setting dir=rtl
on elements that need it).

  - yuri

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

Line 1523 is clearly wrong, I'll fix it.  As for BOM, can you send an
example file?  (Send it as .zip since gmail screws up text files.)
Also, any ideas on how to fix this for the general case?

  - yuri

On 3/24/07, Julio C=E9sar Carrascal Urquijo (MCTS) <jca...@gm...> w=
rote:
> I'm using the markdown.py command to generate HTML from Markdown
> documentation and I've found that if a utf-8 file starts with a BOM a
> paragraph is generated containing only the BOM and it ignores the
> header that's on the first line.
>
> I've fixed it temporarily by adding the following code to lines 1527
> of markdown.py:
>
>     BOM_UTF8 =3D unicode(codecs.BOM_UTF8, "utf-8")
>     if text.startswith(BOM_UTF8):
>         text =3D text.lstrip(BOM_UTF8)
>
> But this should be generalized for any codec. Also, I think line 1523 sho=
uld be:
>
>     input_file =3D codecs.open(input, mode=3D"r", encoding=3Dencoding)
>
> instead of:
>
>     input_file =3D codecs.open(input, mode=3D"r", encoding=3D"utf-8")
>
> I'm using markdown-1.6a.zip on Windows with Python 2.5.
>
> Thanks.
>
> --
> Julio C=E9sar Carrascal Urquijo
> Microsoft Certified Technology Specialist
> http://jcesar.3stecnoinformatica.com/
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


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

SSdtIHVzaW5nIHRoZSBtYXJrZG93bi5weSBjb21tYW5kIHRvIGdlbmVyYXRlIEhUTUwgZnJvbSBN
YXJrZG93bgpkb2N1bWVudGF0aW9uIGFuZCBJJ3ZlIGZvdW5kIHRoYXQgaWYgYSB1dGYtOCBmaWxl
IHN0YXJ0cyB3aXRoIGEgQk9NIGEKcGFyYWdyYXBoIGlzIGdlbmVyYXRlZCBjb250YWluaW5nIG9u
bHkgdGhlIEJPTSBhbmQgaXQgaWdub3JlcyB0aGUKaGVhZGVyIHRoYXQncyBvbiB0aGUgZmlyc3Qg
bGluZS4KCkkndmUgZml4ZWQgaXQgdGVtcG9yYXJpbHkgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcg
Y29kZSB0byBsaW5lcyAxNTI3Cm9mIG1hcmtkb3duLnB5OgoKICAgIEJPTV9VVEY4ID0gdW5pY29k
ZShjb2RlY3MuQk9NX1VURjgsICJ1dGYtOCIpCiAgICBpZiB0ZXh0LnN0YXJ0c3dpdGgoQk9NX1VU
RjgpOgogICAgICAgIHRleHQgPSB0ZXh0LmxzdHJpcChCT01fVVRGOCkKCkJ1dCB0aGlzIHNob3Vs
ZCBiZSBnZW5lcmFsaXplZCBmb3IgYW55IGNvZGVjLiBBbHNvLCBJIHRoaW5rIGxpbmUgMTUyMyBz
aG91bGQgYmU6CgogICAgaW5wdXRfZmlsZSA9IGNvZGVjcy5vcGVuKGlucHV0LCBtb2RlPSJyIiwg
ZW5jb2Rpbmc9ZW5jb2RpbmcpCgppbnN0ZWFkIG9mOgoKICAgIGlucHV0X2ZpbGUgPSBjb2RlY3Mu
b3BlbihpbnB1dCwgbW9kZT0iciIsIGVuY29kaW5nPSJ1dGYtOCIpCgpJJ20gdXNpbmcgbWFya2Rv
d24tMS42YS56aXAgb24gV2luZG93cyB3aXRoIFB5dGhvbiAyLjUuCgpUaGFua3MuCgotLSAKSnVs
aW8gQ8Opc2FyIENhcnJhc2NhbCBVcnF1aWpvCk1pY3Jvc29mdCBDZXJ0aWZpZWQgVGVjaG5vbG9n
eSBTcGVjaWFsaXN0Cmh0dHA6Ly9qY2VzYXIuM3N0ZWNub2luZm9ybWF0aWNhLmNvbS8K

I finally got around to merging a bunch of patches and fixing all of
the open tickets except for one, so this makes the 1.6b release
candidate.  Instead of posting it on the website immediately, I
decided to check it into SVN, in case someone finds any bugs.

I am also making one small change that the first thing towards what I
see as the new focus for 1.7:  Right now the "standard" way to use
markdown is to call markdown.markdown(text) which really just makes a
call to markdown.Markdown(text).toString().  I am changing the latter
to markdown.Markdown().convert(text) to make it clear that you can
reuse the same instance of markdown to convert multiple text strings.
I am guessing that if used properly with something like Django this
can save CPU and perhaps memory.  More generally, I want to think more
about performance rather than features for 1.7., especially in case of
web use with mod_python or FastCGI where a single instance can be used
over time.  If anyone has time to spare and wants to help out with
such performance tuning, please let me know.

  - yuri

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

Thanks for reporting this.  This appears to be a side-effect of the
header pre-processor, which inserts an extra \n after every line that
starts with a #, to make it possible to later have each header in a
block by itself.  Making the html preprocessor run first seems to fix
the problem (see the self.preprocessor array set on line 292).  I will
put a new version up after running more tests and fixing a few other
issues that have been reported.

  - yuri



On 3/18/07, Erick Tryzelaar <ida...@us...> wrote:
> Hello,
>
> I noticed that python-markdown has some problems parsing code with a '#'
> inside of a html tag:
>
>  > python -c 'import markdown; print
> [markdown.markdown("<pre>\n#!/usr/bin/python\nhello</pre>")]'
> ['\n<pre>\n#!/usr/bin/python\n\nhello</pre>\n\n\n\n']
>
> You should notice that there are some extra newline inserted after the
> line with the '#'. I would expect it to be this:
>
> ['\n<pre>\n#!/usr/bin/python\nhello</pre>\n\n\n\n']
>
> -e
>
>
> -------------------------------------------------------------------------
> 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/

Hello,

I noticed that python-markdown has some problems parsing code with a '#' 
inside of a html tag:

 > python -c 'import markdown; print 
[markdown.markdown("<pre>\n#!/usr/bin/python\nhello</pre>")]'
['\n<pre>\n#!/usr/bin/python\n\nhello</pre>\n\n\n\n']

You should notice that there are some extra newline inserted after the 
line with the '#'. I would expect it to be this:

['\n<pre>\n#!/usr/bin/python\nhello</pre>\n\n\n\n']

-e

Yes, this is a known bug.  Basically, nested tags don't work properly.
 This cannot be fixed in any easy way, because it has to do with the
combination of using regular expression and a dom tree to represent
half-processed text.  Basically, once you convert a piece of text into
a dom tree you can't runregular expressions over it.  I've been toying
with an idea of writing a hybrid tree/string structure that would
support a subset of RE, but haven't gotten around to it.  Myself, I
find nested markdown tags largely unnecessary, since once you get
there, using actual HTML tags makes it more readable.  HTML tags do
nest properly, your original example could be marked up as <b>(for all
my *cookies*, I love)</b>, i.e. leaving MD inside by using HTML for
the outside tag.

  - yuri

On 12/4/06, Moritz Angermann <mor...@gm...> wrote:
> yes that's what I guessed...
>
> Additionally I found that
>
> __\_\_init\ _\_.py__ does not work.
>
> There seem to be quite a few bugs once you get at the nested level :(
>
> I remember I had sleepless nightes when I did the xslt markdown parser ..=
.
>
> Eventually I'll take a look at the code and maybe fix it...
>
> thanks,
>  kindest regards,
>  Moritz Angermann
>
> On 12/4/06, Waylan Limberg <wa...@gm...> wrote:
> > I would consider this a known bug, although that specific example
> > doesn't fall under some of the already filed bugs exactly.
> >
> > From my study of the code (some time ago) I seem to recall that when
> > inline markup is found (strong in your case) the text wrapped inside
> > is not processed further. I would suppose it should be just for cases
> > like this and a few other bugs that have been filed. I suggest you
> > file a bug report.
> > https://sourceforge.net/tracker/?func=3Dbrowse&group_id=3D153041&atid=
=3D790198
> >
> > On 12/4/06, Moritz Angermann <mor...@gm...> wrote:
> > > Hi all,
> > >
> > > I'm having trouble to get something like
> > >
> > > __(for all my *cookies*, I love)__ to be formated correctly into
> > > <p><strong>(for all my <em>cookies</em>, I love)</strong></p>
> > >
> > > This is what I get
> > > >>> markdown('__(for all my *cookies*, I love)__')
> > > '\n<p><strong>(for all my *cookies*, I love)</strong>\n</p>\n\n\n'
> > >
> > >
> > > I guess I'm just missing a switch or someting. I'd be really glad to
> > > be enlightened ;)
> > >
> > > kindest regards,
> > >  Moritz Angermann
> > >
> > > --
> > > --------------- One Fish, Two Fish, Blowfish, Blue Fish -------------=
---
> > > Moritz Angermann \ moritz.angermann\gmail.com
> > > Barerstra=DFe 35 \ M:+49 (0) 176 24 81 59 42 / H:+49 (0) 89 12 13 83 =
56
> > > 80799 Munich \  http://www.lunatic-bumblebee.com
> > > ---------------------------------------------------------------------=
----
> > > Take Surveys. Earn Cash. Influence the Future of IT
> > > Join SourceForge.net's Techsay panel and you'll get the chance to sha=
re your
> > > opinions on IT & business topics through brief surveys - and earn cas=
h
> > > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CI=
D=3DDEVDEV
> > > _______________________________________________
> > > Python-markdown-discuss mailing list
> > > Pyt...@li...
> > > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
> > >
> >
> >
> > --
> > ----
> > Waylan Limberg
> > wa...@gm...
> >
>
>
> --
> --------------- One Fish, Two Fish, Blowfish, Blue Fish ----------------
> Moritz Angermann \ moritz.angermann\gmail.com
> Barerstra=DFe 35 \ M:+49 (0) 176 24 81 59 42 / H:+49 (0) 89 12 13 83 56
> 80799 Munich \  http://www.lunatic-bumblebee.com
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


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

eWVzIHRoYXQncyB3aGF0IEkgZ3Vlc3NlZC4uLgoKQWRkaXRpb25hbGx5IEkgZm91bmQgdGhhdAoK
X19cX1xfaW5pdFwgX1xfLnB5X18gZG9lcyBub3Qgd29yay4KClRoZXJlIHNlZW0gdG8gYmUgcXVp
dGUgYSBmZXcgYnVncyBvbmNlIHlvdSBnZXQgYXQgdGhlIG5lc3RlZCBsZXZlbCA6KAoKSSByZW1l
bWJlciBJIGhhZCBzbGVlcGxlc3MgbmlnaHRlcyB3aGVuIEkgZGlkIHRoZSB4c2x0IG1hcmtkb3du
IHBhcnNlciAuLi4KCkV2ZW50dWFsbHkgSSdsbCB0YWtlIGEgbG9vayBhdCB0aGUgY29kZSBhbmQg
bWF5YmUgZml4IGl0Li4uCgp0aGFua3MsCiBraW5kZXN0IHJlZ2FyZHMsCiBNb3JpdHogQW5nZXJt
YW5uCgpPbiAxMi80LzA2LCBXYXlsYW4gTGltYmVyZyA8d2F5bGFuQGdtYWlsLmNvbT4gd3JvdGU6
Cj4gSSB3b3VsZCBjb25zaWRlciB0aGlzIGEga25vd24gYnVnLCBhbHRob3VnaCB0aGF0IHNwZWNp
ZmljIGV4YW1wbGUKPiBkb2Vzbid0IGZhbGwgdW5kZXIgc29tZSBvZiB0aGUgYWxyZWFkeSBmaWxl
ZCBidWdzIGV4YWN0bHkuCj4KPiBGcm9tIG15IHN0dWR5IG9mIHRoZSBjb2RlIChzb21lIHRpbWUg
YWdvKSBJIHNlZW0gdG8gcmVjYWxsIHRoYXQgd2hlbgo+IGlubGluZSBtYXJrdXAgaXMgZm91bmQg
KHN0cm9uZyBpbiB5b3VyIGNhc2UpIHRoZSB0ZXh0IHdyYXBwZWQgaW5zaWRlCj4gaXMgbm90IHBy
b2Nlc3NlZCBmdXJ0aGVyLiBJIHdvdWxkIHN1cHBvc2UgaXQgc2hvdWxkIGJlIGp1c3QgZm9yIGNh
c2VzCj4gbGlrZSB0aGlzIGFuZCBhIGZldyBvdGhlciBidWdzIHRoYXQgaGF2ZSBiZWVuIGZpbGVk
LiBJIHN1Z2dlc3QgeW91Cj4gZmlsZSBhIGJ1ZyByZXBvcnQuCj4gaHR0cHM6Ly9zb3VyY2Vmb3Jn
ZS5uZXQvdHJhY2tlci8/ZnVuYz1icm93c2UmZ3JvdXBfaWQ9MTUzMDQxJmF0aWQ9NzkwMTk4Cj4K
PiBPbiAxMi80LzA2LCBNb3JpdHogQW5nZXJtYW5uIDxtb3JpdHouYW5nZXJtYW5uQGdtYWlsLmNv
bT4gd3JvdGU6Cj4gPiBIaSBhbGwsCj4gPgo+ID4gSSdtIGhhdmluZyB0cm91YmxlIHRvIGdldCBz
b21ldGhpbmcgbGlrZQo+ID4KPiA+IF9fKGZvciBhbGwgbXkgKmNvb2tpZXMqLCBJIGxvdmUpX18g
dG8gYmUgZm9ybWF0ZWQgY29ycmVjdGx5IGludG8KPiA+IDxwPjxzdHJvbmc+KGZvciBhbGwgbXkg
PGVtPmNvb2tpZXM8L2VtPiwgSSBsb3ZlKTwvc3Ryb25nPjwvcD4KPiA+Cj4gPiBUaGlzIGlzIHdo
YXQgSSBnZXQKPiA+ID4+PiBtYXJrZG93bignX18oZm9yIGFsbCBteSAqY29va2llcyosIEkgbG92
ZSlfXycpCj4gPiAnXG48cD48c3Ryb25nPihmb3IgYWxsIG15ICpjb29raWVzKiwgSSBsb3ZlKTwv
c3Ryb25nPlxuPC9wPlxuXG5cbicKPiA+Cj4gPgo+ID4gSSBndWVzcyBJJ20ganVzdCBtaXNzaW5n
IGEgc3dpdGNoIG9yIHNvbWV0aW5nLiBJJ2QgYmUgcmVhbGx5IGdsYWQgdG8KPiA+IGJlIGVubGln
aHRlbmVkIDspCj4gPgo+ID4ga2luZGVzdCByZWdhcmRzLAo+ID4gIE1vcml0eiBBbmdlcm1hbm4K
PiA+Cj4gPiAtLQo+ID4gLS0tLS0tLS0tLS0tLS0tIE9uZSBGaXNoLCBUd28gRmlzaCwgQmxvd2Zp
c2gsIEJsdWUgRmlzaCAtLS0tLS0tLS0tLS0tLS0tCj4gPiBNb3JpdHogQW5nZXJtYW5uIFwgbW9y
aXR6LmFuZ2VybWFublxnbWFpbC5jb20KPiA+IEJhcmVyc3RyYcOfZSAzNSBcIE06KzQ5ICgwKSAx
NzYgMjQgODEgNTkgNDIgLyBIOis0OSAoMCkgODkgMTIgMTMgODMgNTYKPiA+IDgwNzk5IE11bmlj
aCBcICBodHRwOi8vd3d3Lmx1bmF0aWMtYnVtYmxlYmVlLmNvbQo+ID4gLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LQo+ID4gVGFrZSBTdXJ2ZXlzLiBFYXJuIENhc2guIEluZmx1ZW5jZSB0aGUgRnV0dXJlIG9mIElU
Cj4gPiBKb2luIFNvdXJjZUZvcmdlLm5ldCdzIFRlY2hzYXkgcGFuZWwgYW5kIHlvdSdsbCBnZXQg
dGhlIGNoYW5jZSB0byBzaGFyZSB5b3VyCj4gPiBvcGluaW9ucyBvbiBJVCAmIGJ1c2luZXNzIHRv
cGljcyB0aHJvdWdoIGJyaWVmIHN1cnZleXMgLSBhbmQgZWFybiBjYXNoCj4gPiBodHRwOi8vd3d3
LnRlY2hzYXkuY29tL2RlZmF1bHQucGhwP3BhZ2U9am9pbi5waHAmcD1zb3VyY2Vmb3JnZSZDSUQ9
REVWREVWCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xwo+ID4gUHl0aG9uLW1hcmtkb3duLWRpc2N1c3MgbWFpbGluZyBsaXN0Cj4gPiBQeXRob24tbWFy
a2Rvd24tZGlzY3Vzc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQKPiA+IGh0dHBzOi8vbGlzdHMuc291
cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3B5dGhvbi1tYXJrZG93bi1kaXNjdXNzCj4gPgo+
Cj4KPiAtLQo+IC0tLS0KPiBXYXlsYW4gTGltYmVyZwo+IHdheWxhbkBnbWFpbC5jb20KPgoKCi0t
IAotLS0tLS0tLS0tLS0tLS0gT25lIEZpc2gsIFR3byBGaXNoLCBCbG93ZmlzaCwgQmx1ZSBGaXNo
IC0tLS0tLS0tLS0tLS0tLS0KTW9yaXR6IEFuZ2VybWFubiBcIG1vcml0ei5hbmdlcm1hbm5cZ21h
aWwuY29tCkJhcmVyc3RyYcOfZSAzNSBcIE06KzQ5ICgwKSAxNzYgMjQgODEgNTkgNDIgLyBIOis0
OSAoMCkgODkgMTIgMTMgODMgNTYKODA3OTkgTXVuaWNoIFwgIGh0dHA6Ly93d3cubHVuYXRpYy1i
dW1ibGViZWUuY29tCg==

SGkgYWxsLAoKSSdtIGhhdmluZyB0cm91YmxlIHRvIGdldCBzb21ldGhpbmcgbGlrZQoKX18oZm9y
IGFsbCBteSAqY29va2llcyosIEkgbG92ZSlfXyB0byBiZSBmb3JtYXRlZCBjb3JyZWN0bHkgaW50
bwo8cD48c3Ryb25nPihmb3IgYWxsIG15IDxlbT5jb29raWVzPC9lbT4sIEkgbG92ZSk8L3N0cm9u
Zz48L3A+CgpUaGlzIGlzIHdoYXQgSSBnZXQKPj4+IG1hcmtkb3duKCdfXyhmb3IgYWxsIG15ICpj
b29raWVzKiwgSSBsb3ZlKV9fJykKJ1xuPHA+PHN0cm9uZz4oZm9yIGFsbCBteSAqY29va2llcyos
IEkgbG92ZSk8L3N0cm9uZz5cbjwvcD5cblxuXG4nCgoKSSBndWVzcyBJJ20ganVzdCBtaXNzaW5n
IGEgc3dpdGNoIG9yIHNvbWV0aW5nLiBJJ2QgYmUgcmVhbGx5IGdsYWQgdG8KYmUgZW5saWdodGVu
ZWQgOykKCmtpbmRlc3QgcmVnYXJkcywKIE1vcml0eiBBbmdlcm1hbm4KCi0tIAotLS0tLS0tLS0t
LS0tLS0gT25lIEZpc2gsIFR3byBGaXNoLCBCbG93ZmlzaCwgQmx1ZSBGaXNoIC0tLS0tLS0tLS0t
LS0tLS0KTW9yaXR6IEFuZ2VybWFubiBcIG1vcml0ei5hbmdlcm1hbm5cZ21haWwuY29tCkJhcmVy
c3RyYcOfZSAzNSBcIE06KzQ5ICgwKSAxNzYgMjQgODEgNTkgNDIgLyBIOis0OSAoMCkgODkgMTIg
MTMgODMgNTYKODA3OTkgTXVuaWNoIFwgIGh0dHA6Ly93d3cubHVuYXRpYy1idW1ibGViZWUuY29t
Cg==

Ah, thanks. I see it is not assigned to anybody yet, so a fix is no  
likely to happen anytime soom. I do not promise to look at the code for  
a possible fix, but I will if I get some time.

Is there any way to imply a div without actually writing out the div?

Another thought, although not quite related to this -- is there (or  
could there be) some way, to pass a class attr value to elements  
generated by the markdown processor? E.g. What come to mind is to  
always precede the "decorated" element with the class name, something  
like:

Paragraphs:

	@note This is the paragraph text...

Lists:

	@myliststyle
	- one
	- two

Links and imgs:

	@mylinkstyle[link text](url)
	@myimgstyle![alt text](src)

mario



On Aug 28, 2006, at 4:16 PM, Waylan Limberg wrote:

> This is a known bug. See the related bug reports:
>
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1458140&group_id=153041&atid=790198
> http://sourceforge.net/tracker/index.php? 
> func=detail&aid=1458139&group_id=153041&atid=790198
>
> My comments on the second link above best show what is causing the
> problem. Unfortunetly, I have no concrete ideas for a fix.
>
> On 8/28/06, mario ruggier <ma...@ru...> wrote:
>> Hello,
>>
>> I am trying to wrap sections of content into blocks, such that I can
>> CSS each block liberally. So, in practice I expected that the HTML in
>> the following sample will give me what I want:
>>
>> <div class="one">
>>
>> a para
>>
>> another para
>>
>> </div><div class="two">
>>
>> a para two
>>
>> another para
>>
>> </div>
>>
>> However, the div tags get wrapped in <p> elements. It seems that the
>> parser does not keep track of when an inlined block level element is
>> closed, at least not beyond the first blank line encountered. If, by
>> first blank line, it is not closed, then it treats it just like
>> paragraph text and wraps  a <p> around it. Is this correct?
>>
>> Can I specify in some way to not touch "free-floating" html bits,
>> whether the parser thinks they are well-formed or not?
>>
>> Any ideas how to achieve something like the above with the current
>> version?
>>
>> Thanks for any hints...
>>
>> mario
>>
>>
>> ---------------------------------------------------------------------- 
>> ---
>> Using Tomcat but need to do more? Need to support web services,  
>> security?
>> Get stuff done quickly with pre-integrated technology to make your  
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>
> -- 
> ----
> Waylan Limberg
> wa...@gm...

Hello,

I am trying to wrap sections of content into blocks, such that I can 
CSS each block liberally. So, in practice I expected that the HTML in 
the following sample will give me what I want:

<div class="one">

a para

another para

</div><div class="two">

a para two

another para

</div>

However, the div tags get wrapped in <p> elements. It seems that the 
parser does not keep track of when an inlined block level element is 
closed, at least not beyond the first blank line encountered. If, by 
first blank line, it is not closed, then it treats it just like 
paragraph text and wraps  a <p> around it. Is this correct?

Can I specify in some way to not touch "free-floating" html bits, 
whether the parser thinks they are well-formed or not?

Any ideas how to achieve something like the above with the current 
version?

Thanks for any hints...

mario

Waylan,

Thanks.  There is actually already a link on the python markdown site
(see on the left under "Extensions"), though it points to your earlier
page.  I will change the link the next time I am updating the page.

I wonder, however, whether it is a good idea to hard-code WIKI_URL to
'/...' inside a function, where it will be hard to access.  This way,
if you are using a single script to manage several wikis
(example.com/wiki1/, example.com/wikie2) you are out of luck, right?
Also, I really want to move to a "centralized" for managing
extensions, so that someone who say runs a website that allows users
to create their own wikis could give the users an option to enable
certain extensions and to set certain parameters for them.  To enable
that, all extensions must be configurable from outside.

The best, perhaps, would be to have suggest that all extensions use a
dictionary stored in self.config to store configurations.  E.g., in
your case you would have self.config = {'LINK_URL_TEMPLATE' = '/%s/').
 Those parameters can then be accessed from outside Markdown:

md.extensions['wikilinks'].config['LINK_URL_TEMPLATE'] = "/~%s/wiki/" % username

This would allow, for instance, to control set though parameters
through a web interface or potentially through the command line
interface with something like:

markdown.py -xwikilinks/LINK_URL_TEMPLATE="/~yuri/wiki/" input.txt > output.txt

  - yuri

On 8/23/06, Waylan Limberg <wa...@gm...> wrote:
> For those interested, I have released an improved version of my
> WikiLink extention that makes using additional extentions with it much
> easier. I haven't adapted it to Yuri's latest work in that regard yet,
> but its much better than the first time around.
>
> Annoucement:
> http://achinghead.com/archives/72/markdown-wikilinks-release-02/
>
> Code:
> http://code.limberg.name/svn/projects/py-markdown-ext/wikilinks/trunk/wikimarkdown.py
>
> Project Page:
> http://achinghead.com/markdown-wikilinks/
>
> Yuri, you may want to link to my project page rather than my initial
> blog post on your site. Although, if you do, I may no longer have
> Google's *third* result for "WikiLink" :-D It was fun while it lasted!
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>


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

For those interested, I have released an improved version of my
WikiLink extention that makes using additional extentions with it much
easier. I haven't adapted it to Yuri's latest work in that regard yet,
but its much better than the first time around.

Annoucement:
http://achinghead.com/archives/72/markdown-wikilinks-release-02/

Code:
http://code.limberg.name/svn/projects/py-markdown-ext/wikilinks/trunk/wikimarkdown.py

Project Page:
http://achinghead.com/markdown-wikilinks/

Yuri, you may want to link to my project page rather than my initial
blog post on your site. Although, if you do, I may no longer have
Google's *third* result for "WikiLink" :-D It was fun while it lasted!

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

Here is a new version that I am hoping to put on the website in a few
days, once I get around to changing the documentation.  The basic
changes are:

1. A few bug fixes, including Sergej's patch for the ampersand problem
discussed on the list in July.
2. Switched to using optparse for command line processing.  This means
you need Python 2.3 or higher to use advanced command line options (or
install optparse).  However, the script _does_ work with lower
versions of python - just with very basic command line handing.
3. Proper handling of unicode
4. The extensions work a bit differently now (once they are upgraded).
 Each extension should be in a module that is prefixed with mdx_, e.g.
mdx_footnotes.py.  It should also implement a module-level function
makeExtension() which should return the extension object.  The
extension class should implement extendMarkdown as before.   The
extensions can then be loaded from the command line using the
following syntax:

markdown.py -xfootnotes mytext.txt

or, possibly

markdown.py -xfootnotes -xtoc -xmyotherext mytext.txt

Note that in this case Markdown is going to go looking for the other
extensions in the mdx_toc and mdx_myotherext modules.

The extensions can be loaded programmatically in the same way:

markdown("lorem [^1]\n\n[^1]ipsum", extensions=['footnotes'])

(If you use the Markdown class directly you will have to load the
extensions manually for now, but I will move the loading logic into
the class itself, so that there is something like
md.loadExtensions(['footnotes'].)

The code is at http://www.freewisdom.org/projects/python-markdown/python-markdown-1-6-rc1.tgz

  - yuri

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

On Jul 29, 2006, at 0:39, Yuri T. wrote:

> I don't do math documents myself at the moment, but I imagine many
> people would find this quite useful. If you provide a python module
> that converts latex math markup into MathML, I can wrap it up into a
> markdown extension, to save you the trouble of dealing with the
> interface.

OK, thanks.

I just had another look at the itex source. Not very complex, but a  
bit more extensive than I had remembered. So... If I do have a whack  
at it, it may not be for a while yet :-)

And a quick search, however, uncovered that BlahTex [1] is being  
rewritten in Python [2]. Not sure when that will be finished, though.  
It seems quite feature-rich and rather mature, so I guess it would be  
a better alternative.

[1] http://www.blahtex.org
[2] http://meta.wikimedia.org/wiki/Blahtex

--
Magnus Lie Hetland
http://hetland.org

On Jul 29, 2006, at 0:52, Yuri T. wrote:

[snip]
> In this case, I am not sure there is a reason to integrate them more
> tightly, e.g., by making an extension.

I agree. Using the two separately would be fine :)

--
Magnus Lie Hetland
http://hetland.org

Apart from the backticks, which conflict with Markdown syntax, I would
imagine that one should be able to simply pass the output of markdown
into this implementation of smartypants to get the necessary result.
In this case, I am not sure there is a reason to integrate them more
tightly, e.g., by making an extension.  On the other hand, people do
ask about it occasionally.

  - yuri

On 7/27/06, Magnus Lie Hetland <ma...@he...> wrote:
>
> On Jul 27, 2006, at 15:28, Sergej Chodarev wrote:
>
> > There is Python implementation of SmartyPants ported by Chad Miller
> > http://web.chad.org/projects/smartypants.py/
>
> Oh, thanks. Sorry I missed that :)
>
> --
> Magnus Lie Hetland
> http://hetland.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
>


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

I don't do math documents myself at the moment, but I imagine many
people would find this quite useful.  If you provide a python module
that converts latex math markup into MathML, I can wrap it up into a
markdown extension, to save you the trouble of dealing with the
interface.  (BTW, I am introducing some small changes to the extension
interface in the next version to allow markdown.py to load extension
modules rather than the other way around.)

On 7/27/06, Magnus Lie Hetland <ma...@he...> wrote:
> Hi!
>
> In my (now dormant, and possibly moribund ;) project Atox [1], I had
> plans to add a filter using Tralics [2], effectively allowing an
> arbitrary mix of plain-text markup, XML and TeX/LaTeX. After some
> reflection, I've found that this (although doable) is probably
> overkill...
>
> Now, in Markdown, I still have support for plain-text markup and XML
> (that is, XHTML), and I don't really need the full TeX handling of
> Tralics -- but it would be nice to have support for basic math.
>
> So, I was thinking, perhaps a simple post- (or pre-?) processor
> extension, using dollar signs as inline tags (as in TeX) to mark
> math, and then either ship things out to a true TeX (as in the
> Wikimedia solution), to Tralics, or simply implement a basic LaTeX-to-
> MathML-translator.
>
> I've been thinking about re-implementing the iTeX processor [3], for
> example, which isn't very complicated, but which covers quite a bit
> of math. (One could simply use MathML directly in Markdown, of
> course, but it would be quite a bit more verbose...) There are other
> solutions as well, of course [E.g., 4]. For rendering, there are even
> solutions for browsers that don't support MathML (although that
> doesn't have much to do with Markdown, I guess). [5]
>
> [1] http://atox.sf.net
> [2] http://www-sop.inria.fr/miaou/tralics
> [3] http://pear.math.pitt.edu/mathzilla/itex2mml.html
> [4] http://www1.chapman.edu/~jipsen/mathml/asciimath.html
> [5] http://www.math.union.edu/~dpvc/jsMath
>
> --
> Magnus Lie Hetland
> http://hetland.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
>


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