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

Yuri Takhteyev wrote:
>> This makes sense. Should postprocessors be done in this fashion? That
>> requires a DomPostprocessor and TextPostprocessor. Since they all
>> roughly have the same syntax, we could just collapse them into
>> TextProcessor, LineProcessor, and DomProcessor.
>
> Interesting.  Note thought that DomProcessor is only makes sense in
> the end when there is a dom script.  Also, mixing DomProcessors and
> TextProcessors would probably carry a lot more of a performance
> penalty, plus parsing the output into NanoDom would create tons of
> additional problems.

Thats true. I do personally like the different phases of processors. I 
think makes sense to not mix them. I thought thats just what you wanted.

>> Why use this instead of just doing "isinstance(processor,
>> TextProcessor)" and etc?
>
> That's probably better.  I just wrote the first thing that came to mind.
>
>> Or even better, just call a "process_lines",
>> "process_text", or "process_dom"? With these functions, we don't even
>> have to complicate the core markdown pipeline. Just have:
>>
>> class LineProcessor(TextProcessor):
>>   def process_text(self, text):
>>     return '\n'.join(self.process_lines(text.split('\n')))
>
> I was just trying to avoid converting text back and forth.

You can still use duck typing without doing all this string conversion 
all the time. Also, since I've only found 5 or 6 markdown plugins, it 
shouldn't be too difficult to port them around, if we wanted to change 
the api. Probably would have to bump a version number though.

>> Also, are you familiar with setuptools? It's a pretty close to drop-in
>> replacement for distutils, and it has some nice things like plugin
>> support. I've hacked up support for it in markdown, but it's not really
>> in a great condition yet. Would this be interesting for you?
>
> Yes.  But it's low priority.  Which is to say, if someone wanted to
> offer help with this, I would appreciate it, but I don't have the time
> at the moment to dive into it.

I've already offered :) It's pretty small change. The setup.py file becomes:

############################################################
from setuptools import setup, find_packages

import markdown

setup(
    name = 'markdown',
    version = markdown.__version__,
    url = "http://www.freewisdom.org/projects/python-markdown",
    author = "Manfred Stienstra and Yuri takhteyev",
    maintainer = "Yuri Takhteyev",
    maintainer_email = "yuri [at] freewisdom.org",
    description = "Python implementation of Markdown.",
    packages = find_packages(),
    py_modules = ["mdx_footnotes", "mdx_rss"],
    platforms = 'any',
    zip_safe = True,
    include_package_data = True,
)
############################################################

Then to use it, you have this in the plugin setup. The important thing 
is the entry_points:

############################################################
from setuptools import setup, find_packages

import markdown

setup(
    name='markdown-pygments',
    version='0.1',
    description="pygments extension for markdown.",
    platforms='any',
    zip_safe=True,
    packages=['markdown_pygments'],
    entry_points={
        'markdown': [
            'pygments = markdown_pygments:PygmentsExtension'
        ],
    },
)
############################################################



And to load plugins, just do this:

############################################################
try:
    import pkg_resources
except ImportError:
    pkg_resources = None

ENTRY_POINT = 'markdown'

def find_plugins():
    if pkg_resources is None:
        return
    for entrypoint in pkg_resources.iter_entry_points(ENTRY_POINT):
        yield entrypoint.load()

plugin_classes = find_plugins()
for ext in extensions:
    config = extension_configs.get(ext, {})
    for cls in plugin_classes:
        if cls.name == ext:
            e = cls(config)
            e.extendMarkdown(self, globals())
############################################################

> This makes sense. Should postprocessors be done in this fashion? That
> requires a DomPostprocessor and TextPostprocessor. Since they all
> roughly have the same syntax, we could just collapse them into
> TextProcessor, LineProcessor, and DomProcessor.

Interesting.  Note thought that DomProcessor is only makes sense in
the end when there is a dom script.  Also, mixing DomProcessors and
TextProcessors would probably carry a lot more of a performance
penalty, plus parsing the output into NanoDom would create tons of
additional problems.

> Why use this instead of just doing "isinstance(processor,
> TextProcessor)" and etc?

That's probably better.  I just wrote the first thing that came to mind.

> Or even better, just call a "process_lines",
> "process_text", or "process_dom"? With these functions, we don't even
> have to complicate the core markdown pipeline. Just have:
>
> class LineProcessor(TextProcessor):
>   def process_text(self, text):
>     return '\n'.join(self.process_lines(text.split('\n')))

I was just trying to avoid converting text back and forth.

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

> Also, are you familiar with setuptools? It's a pretty close to drop-in
> replacement for distutils, and it has some nice things like plugin
> support. I've hacked up support for it in markdown, but it's not really
> in a great condition yet. Would this be interesting for you?

Yes.  But it's low priority.  Which is to say, if someone wanted to
offer help with this, I would appreciate it, but I don't have the time
at the moment to dive into it.

 - yuri

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

I try to not add to the core script features that aren't part of
Markdown.  If you want, you can bring this up on the main markdown
list.  If they like the idea, I would add it to python-markdown too.

I don't know of anyone who did this as an extension, but this should
be hard to do.  It would be a great exercise for learning how to write
extensions! :)

  - yuri

On 5/24/07, Sam's Lists <sam...@gm...> wrote:
> I've been experimenting with python-markdown and it seems neat.  This is the
> first time I've used markdown.
>
> I am surprised, especially coming from textile, that markdown won't
> automatically turn a text url into an actual clickable url.
>
> Has anyone written an extension that I can use to make url's clickable?
>
> Thanks!
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> 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/

I've been experimenting with python-markdown and it seems neat.  This is the
first time I've used markdown.

I am surprised, especially coming from textile, that markdown won't
automatically turn a text url into an actual clickable url.

Has anyone written an extension that I can use to make url's clickable?

Thanks!

Whoops, I forgot the link. Sorry.

http://www.michelf.com/projects/php-markdown/extra/#header-id

---------- Forwarded message ----------
From: Waylan Limberg <wa...@gm...>
Date: May 23, 2007 9:15 AM
Subject: Re: [Python-markdown-discuss] Page internal links
To: pyt...@li...


I appreciate your work on this, but Markdown already has a commonly
accepted syntax for this. See PHP-Markdown Extra [1] for a nice
description. Additionally, as the official syntax (from JG) mentions
nothing of this behavior, it should be an optional addon, like it is
in PHP.  Of course, Yuri will make the final call on that.

I started working on an extension for this some time ago, but ran into
some weirdness with the regex and haven't had the time to play with it
since. Perhaps I'll post what I had when I get home (assuming I still
have it and can find it).

On 5/23/07, glin <gl...@se...> wrote:
> Hi, I'm sending patch, that adds possibility to create links to headings
> (so it is possible to create links using #rel appended to url) - just
> like in trac wiki.
>



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


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

I appreciate your work on this, but Markdown already has a commonly
accepted syntax for this. See PHP-Markdown Extra [1] for a nice
description. Additionally, as the official syntax (from JG) mentions
nothing of this behavior, it should be an optional addon, like it is
in PHP.  Of course, Yuri will make the final call on that.

I started working on an extension for this some time ago, but ran into
some weirdness with the regex and haven't had the time to play with it
since. Perhaps I'll post what I had when I get home (assuming I still
have it and can find it).

On 5/23/07, glin <gl...@se...> wrote:
> Hi, I'm sending patch, that adds possibility to create links to headings
> (so it is possible to create links using #rel appended to url) - just
> like in trac wiki.
>



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

glin wrote:
> Value of 'id' attribute is set to text of heading without spaces.
I reconsider this, and just "without spaces" is not enough. Some 
function, which would convert heading text to identificator would be 
much better (special characters like (){}[]/#%&? etc. etc. must be 
replaced and characters with accents should be replaced, too.
Do you have idea where to get such a function?

Hi, I'm sending patch, that adds possibility to create links to headings 
(so it is possible to create links using #rel appended to url) - just 
like in trac wiki.

Just added 2 lines of code, and I think it is quite useful.

It adds attribute 'id' to h1-h6 elements created from heading. Value of 
'id' attribute is set to text of heading without spaces.

Example:

# Heading One

......some text here.... and finally comes [link to heading 
one](#HeadingOne)


Output:
<h1 id="HeadingOne">Heading One</h1>
<p>......some text here.... and finally comes <a href="#HeadingOne">link 
to heading one</a>
</p>

 > We can add two subclasses of Preprocessor: TextPreprocessor and
 > LinePreprocessor. (For now LinePreprocessor would behave as
 > Preprocessor but we can deprecate it later).

This makes sense. Should postprocessors be done in this fashion? That 
requires a DomPostprocessor and TextPostprocessor. Since they all 
roughly have the same syntax, we could just collapse them into 
TextProcessor, LineProcessor, and DomProcessor.

 > Each will have a
 > get_input_type() method which would return "lines" or "text" which
 > will signify what input it expects. Either would be allowed to return
 > a list of lines _or_ text. Markdown will check type and do the
 > conversion if adjacent preprocessors want different formats.

Why use this instead of just doing "isinstance(processor, 
TextProcessor)" and etc? Or even better, just call a "process_lines", 
"process_text", or "process_dom"? With these functions, we don't even 
have to complicate the core markdown pipeline. Just have:

class LineProcessor(TextProcessor):
  def process_text(self, text):
    return '\n'.join(self.process_lines(text.split('\n')))


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.

Also, are you familiar with setuptools? It's a pretty close to drop-in 
replacement for distutils, and it has some nice things like plugin 
support. I've hacked up support for it in markdown, but it's not really 
in a great condition yet. Would this be interesting for you?

-e

It seems that you are loading your file as if it was ASCII (i.e., with
just plain open()) even thought it's not (because of the smart quotes
saved as UTF8).  When you do this, the non-ascii characters sometimes
do not cause problems and sometimes they do.  So, I am not sure why
this disabling removeBOM makes this problem go away and wouldn't rely
on this.

Instead, you should open your file with using:

input_file = codecs.open(input, mode="r", encoding="utf8")

(Or make it ASCII-compliant.)

  - yuri

On 5/15/07, Aaron Gyes <fl...@sh...> wrote:
> It seems to be "all of them". It oddly enough doesn't happen when I
> give them to it running ./markdown.py at a CLI.
>
> One such file would be http://aarongyes.com/pages/home.txt, another
> http://aarongyes.com/pages/resume.txt. Those files should be
> completely identical, they are in the exact same location as they
> really are being used at, not even copied.
>
> I have wedged it into a home-made templating system, and am calling
> it with .convert(string).
>
> You can look at my code here:
> http://aarongyes.com/sitestruc.py_
> http://aarongyes.com/site.py_
>
> (the latter being relevant).
>
> Temporarily making removeBOM do nothing but return text has it
> hobbling along.
>
> On May 15, 2007, at 7:18 PM, Yuri Takhteyev wrote:
>
> > Can you send a file that causes the error?  Also, how are you
> > calling it?
> >
> >  - yuri
> >
> > On 5/15/07, Aaron Gyes <fl...@sh...> wrote:
> >> Not entirely sure what is going on, it was just fine with 1.6a.
> >>
> >> File "/www/htdocs/floam.sh.nu/html/markdown.py", line 1611, in
> >> convert
> >> \n    self.source = removeBOM(self.source, self.encoding)
> >> File "/www/htdocs/floam.sh.nu/html/markdown.py", line 74, in
> >> removeBOM
> >> \n    if text.startswith(bom):
> >> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
> >> 253: ordinal not in range(128)
> >>
> >> Aaron Gyes
> >
> >
> > --
> > Yuri Takhteyev
> > UC Berkeley School of Information
> > http://www.freewisdom.org/
>


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

It seems to be "all of them". It oddly enough doesn't happen when I  
give them to it running ./markdown.py at a CLI.

One such file would be http://aarongyes.com/pages/home.txt, another  
http://aarongyes.com/pages/resume.txt. Those files should be  
completely identical, they are in the exact same location as they  
really are being used at, not even copied.

I have wedged it into a home-made templating system, and am calling  
it with .convert(string).

You can look at my code here:
http://aarongyes.com/sitestruc.py_
http://aarongyes.com/site.py_

(the latter being relevant).

Temporarily making removeBOM do nothing but return text has it  
hobbling along.

On May 15, 2007, at 7:18 PM, Yuri Takhteyev wrote:

> Can you send a file that causes the error?  Also, how are you  
> calling it?
>
>  - yuri
>
> On 5/15/07, Aaron Gyes <fl...@sh...> wrote:
>> Not entirely sure what is going on, it was just fine with 1.6a.
>>
>> File "/www/htdocs/floam.sh.nu/html/markdown.py", line 1611, in  
>> convert
>> \n    self.source = removeBOM(self.source, self.encoding)
>> File "/www/htdocs/floam.sh.nu/html/markdown.py", line 74, in  
>> removeBOM
>> \n    if text.startswith(bom):
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
>> 253: ordinal not in range(128)
>>
>> Aaron Gyes
>
>
> -- 
> Yuri Takhteyev
> UC Berkeley School of Information
> http://www.freewisdom.org/

Can you send a file that causes the error?  Also, how are you calling it?

  - yuri

On 5/15/07, Aaron Gyes <fl...@sh...> wrote:
> Not entirely sure what is going on, it was just fine with 1.6a.
>
> File "/www/htdocs/floam.sh.nu/html/markdown.py", line 1611, in convert
> \n    self.source = removeBOM(self.source, self.encoding)
> File "/www/htdocs/floam.sh.nu/html/markdown.py", line 74, in removeBOM
> \n    if text.startswith(bom):
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position
> 253: ordinal not in range(128)
>
> Aaron Gyes


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

Not entirely sure what is going on, it was just fine with 1.6a.

File "/www/htdocs/floam.sh.nu/html/markdown.py", line 1611, in convert 
\n    self.source = removeBOM(self.source, self.encoding)
File "/www/htdocs/floam.sh.nu/html/markdown.py", line 74, in removeBOM 
\n    if text.startswith(bom):
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position  
253: ordinal not in range(128)

Aaron Gyes

Actually, how about this:

We can add two subclasses of Preprocessor: TextPreprocessor and
LinePreprocessor.  (For now LinePreprocessor would behave as
Preprocessor but we can deprecate it later).  Each will have a
get_input_type() method which would return "lines" or "text" which
will signify what input it expects.  Either would be allowed to return
a list of lines _or_ text.  Markdown will check type and do the
conversion if adjacent preprocessors want different formats.

So, you would be able to do this:

     class FooPreprocessor (TextPreprocessor) :
         def run(self, text)
              return foo(text)  # foo could return a single string
_or_ a list of lines

     class BarPreprocessor (LinesPreprocessor) :
         def run(self, lines)
              return bar(lines)  # bar could return a single string
_or_ a list of lines


You could then insert the BarPreprocessor and the FooPreprocessor into
the queue in any order.  If you put Foo after Bar and Foo.run returns
a string, it will be split into lines before being fed to Bar.run.  If
Foo.run returns a list, it will be fed into Bar.run as is.

  - yuri

On 5/15/07, Erick Tryzelaar <ida...@us...> wrote:
> Yuri Takhteyev wrote:
> > Yes, but how much performance do you gain compared to doing a
> > "\n".join, storing the string, doing whatever you want to it, then
> > returning s.split("\n")?
> >
> > I mean it as a serious empirical question.  If it makes a substantial
> > difference, it would be worth making the API a bit more complicated.
> > If it gains something like 1% in performance, I am not so it makes
> > sense to introduce a new type of post processor.
>
> You're right, I don't see any performance benefits. I do find it
> semantically easier to work directly with regexes, but I guess I can do
> that in my extensions.
>


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

Yuri Takhteyev wrote:
> Yes, but how much performance do you gain compared to doing a
> "\n".join, storing the string, doing whatever you want to it, then
> returning s.split("\n")?
>
> I mean it as a serious empirical question.  If it makes a substantial
> difference, it would be worth making the API a bit more complicated.
> If it gains something like 1% in performance, I am not so it makes
> sense to introduce a new type of post processor.

You're right, I don't see any performance benefits. I do find it 
semantically easier to work directly with regexes, but I guess I can do 
that in my extensions.

Yes, but how much performance do you gain compared to doing a
"\n".join, storing the string, doing whatever you want to it, then
returning s.split("\n")?

I mean it as a serious empirical question.  If it makes a substantial
difference, it would be worth making the API a bit more complicated.
If it gains something like 1% in performance, I am not so it makes
sense to introduce a new type of post processor.

I applied your patch and then changed HTML_PREPROCESSOR to work as a
"text" preprocessor, but this gave me no performance improvement on
the "markdown-test".  I am attaching the output of test-markdown.py
with repeat set to 100 times (i.e., 10x the default value.  (The gray
numbers are values for pre-patch version.)

I do understand that this may not be a fair test.  Can you send me one
that shows more of a difference.

test-markdown.py by default runs all the files in a directory without
any extensions.  However, if the directory name starts with "ext-x-"
then whatever follows "-x-" is taken as a "-"-delimited llist of
extensions.  So, if you write an extention "foo" which uses text
preprocessors, the test cases this extension should go under
"ext-x-foo"

(The reason there are no "ext-x" test directories in SVN is that I
started making them, discovered that the wikilinks extension is broken
in the new version and haven't had time to fix it since March.)

  - yuri

On 5/15/07, Erick Tryzelaar <ida...@us...> wrote:
> With the whole text preprocessor, I can use re.finditer to find all the
> matches in a string, instead of having to test a regex against each line
> and maintain state between lines, so it can be a little easier to use. I
> haven't done too many performance tests, but on a large string, it ought
> to be faster since the string searching should remain in the c kernel.
>
> -e
>
>
> Yuri Takhteyev wrote:
> > Thanks for this patch.  About the preprocessors: did you actually get
> > a noticeable performance improvement with this?  If so, I will be
> > happy to put it in.
> >
> >  - yuri
> >
> > On 5/15/07, Erick Tryzelaar <ida...@us...> wrote:
> >> I noticed that the code for markdown.py isn't consistent in how it does
> >> spaces. I've tried to normalize it to the python coding standard,
> >> from here:
> >>
> >> http://www.python.org/dev/peps/pep-0008/
> >>
> >> I've also made the objects subclass from object, if that's alright. This
> >> also assumes that my previous patch has been applied, so if you don't
> >> want the text preprocessors, we'll have to edit this patch.
> >>
> >> I uploaded the patch here, since it's kind of big:
> >>
> >> http://sourceforge.net/tracker/index.php?func=detail&aid=1719072&group_id=153041&atid=790200
> >>
> >>
> >> -e
> >>
> >> -------------------------------------------------------------------------
> >>
> >> This SF.net email is sponsored by DB2 Express
> >> Download DB2 Express C - the FREE version of DB2 express and take
> >> control of your XML. No limits. Just data. Click to get it now.
> >> http://sourceforge.net/powerbar/db2/
> >> _______________________________________________
> >> 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/

With the whole text preprocessor, I can use re.finditer to find all the 
matches in a string, instead of having to test a regex against each line 
and maintain state between lines, so it can be a little easier to use. I 
haven't done too many performance tests, but on a large string, it ought 
to be faster since the string searching should remain in the c kernel.

-e


Yuri Takhteyev wrote:
> Thanks for this patch.  About the preprocessors: did you actually get
> a noticeable performance improvement with this?  If so, I will be
> happy to put it in.
>
>  - yuri
>
> On 5/15/07, Erick Tryzelaar <ida...@us...> wrote:
>> I noticed that the code for markdown.py isn't consistent in how it does
>> spaces. I've tried to normalize it to the python coding standard, 
>> from here:
>>
>> http://www.python.org/dev/peps/pep-0008/
>>
>> I've also made the objects subclass from object, if that's alright. This
>> also assumes that my previous patch has been applied, so if you don't
>> want the text preprocessors, we'll have to edit this patch.
>>
>> I uploaded the patch here, since it's kind of big:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=1719072&group_id=153041&atid=790200 
>>
>>
>> -e
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by DB2 Express
>> Download DB2 Express C - the FREE version of DB2 express and take
>> control of your XML. No limits. Just data. Click to get it now.
>> http://sourceforge.net/powerbar/db2/
>> _______________________________________________
>> Python-markdown-discuss mailing list
>> Pyt...@li...
>> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>>
>
>

Thanks for this patch.  About the preprocessors: did you actually get
a noticeable performance improvement with this?  If so, I will be
happy to put it in.

  - yuri

On 5/15/07, Erick Tryzelaar <ida...@us...> wrote:
> I noticed that the code for markdown.py isn't consistent in how it does
> spaces. I've tried to normalize it to the python coding standard, from here:
>
> http://www.python.org/dev/peps/pep-0008/
>
> I've also made the objects subclass from object, if that's alright. This
> also assumes that my previous patch has been applied, so if you don't
> want the text preprocessors, we'll have to edit this patch.
>
> I uploaded the patch here, since it's kind of big:
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=1719072&group_id=153041&atid=790200
>
> -e
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> 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/

I noticed that the code for markdown.py isn't consistent in how it does 
spaces. I've tried to normalize it to the python coding standard, from here:

http://www.python.org/dev/peps/pep-0008/

I've also made the objects subclass from object, if that's alright. This 
also assumes that my previous patch has been applied, so if you don't 
want the text preprocessors, we'll have to edit this patch.

I uploaded the patch here, since it's kind of big:

http://sourceforge.net/tracker/index.php?func=detail&aid=1719072&group_id=153041&atid=790200

-e

I had a case where it would be faster to preprocess the text before it 
was split into lines. This simple patch copies the textPostprocessors to 
add textPreprocessors. Think it could be added?

-e

Index: markdown.py
===================================================================
--- markdown.py (revision 32)
+++ markdown.py (working copy)
@@ -1063,6 +1063,8 @@
         self.stripTopLevelTags = 1
         self.docType = ""
 
+        self.textPreprocessors = []
+
         self.preprocessors = [ HTML_BLOCK_PREPROCESSOR,
                                HEADER_PREPROCESSOR,
                                LINE_PREPROCESSOR,
@@ -1610,6 +1612,8 @@
 
         self.source = removeBOM(self.source, self.encoding)
 
+        for pp in self.textPreprocessors:
+            self.source = pp.run(self.source)
        
         doc = self._transform()
         xml = doc.toxml()

Well, if I were using a wiki that is not written in Python, I would
probably just use my own Lua wiki.  Nothing against PmWiki (and thanks
for making MD work with it), but it's just easier for me to use my own
system.  The only reason I haven't installed it is that I've been
thinking it would be nice to "self-host".

MoinMoin would definitely be something to consider, though I was
hoping for something simpler.  Or, for something written in Django,
since I am already running it.

  - yuri

On 5/9/07, Ben Wilson <da...@gm...> wrote:
> Although not Python-based, I use PmWiki and have authored a "recipe"
> (PmWiki-ese for plug-in) that allows for Markdown syntax by using PHP
> Markdown, which delivers results but I don't remember it delivering
> all of Markdown syntax. Hmm. I'm also working on a Python-based
> Markdown wiki, but it is not ready for prime time. :-)
>
> http://PmWiki.org
> http://PmWiki.org/wiki/Cookbook/Markdown
>
> Ben Wilson
>
> On 5/9/07, Yuri Takhteyev <qar...@gm...> wrote:
> > Hi,
> >
> > As someone have pointed out, the website is really in need of fixing.
> > I've been thinking of simplifying the management of the site by
> > turning it into a wiki.  However, I am not sure which one to use.  I
> > am currently working on a wiki[1] using Markdown and which I could
> > use, but it's written in Lua and uses a Lua implementation of MD.  So,
> > using it may be a bit strange.  So, I would prefer to use a simple
> > wiki that uses python-markdown.  Does anyone have any suggestions?
> > Part of what defines "simple" for me is not having to use a database.
> >
> >   - yuri
> >
> > [1]: http://www.freewisdom.org/projects/sputnik/
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > 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/

On 5/9/07, Yuri Takhteyev <qar...@gm...> wrote:
> Hi,
>
> As someone have pointed out, the website is really in need of fixing.
> I've been thinking of simplifying the management of the site by
> turning it into a wiki.  However, I am not sure which one to use.
> [snip]
>  Does anyone have any suggestions?
> Part of what defines "simple" for me is not having to use a database.

MoinMoin looks like a good one.

http://moinmoin.wikiwikiweb.de/
http://moinmoin.wikiwikiweb.de/ParserMarket?highlight=%28markdown%29#head-0528d17cfa26b070e377fa5c4fa9177175b6f98b
http://wiki.vja2.net/MyMoinPlugins

---John

Although not Python-based, I use PmWiki and have authored a "recipe"
(PmWiki-ese for plug-in) that allows for Markdown syntax by using PHP
Markdown, which delivers results but I don't remember it delivering
all of Markdown syntax. Hmm. I'm also working on a Python-based
Markdown wiki, but it is not ready for prime time. :-)

http://PmWiki.org
http://PmWiki.org/wiki/Cookbook/Markdown

Ben Wilson

On 5/9/07, Yuri Takhteyev <qar...@gm...> wrote:
> Hi,
>
> As someone have pointed out, the website is really in need of fixing.
> I've been thinking of simplifying the management of the site by
> turning it into a wiki.  However, I am not sure which one to use.  I
> am currently working on a wiki[1] using Markdown and which I could
> use, but it's written in Lua and uses a Lua implementation of MD.  So,
> using it may be a bit strange.  So, I would prefer to use a simple
> wiki that uses python-markdown.  Does anyone have any suggestions?
> Part of what defines "simple" for me is not having to use a database.
>
>   - yuri
>
> [1]: http://www.freewisdom.org/projects/sputnik/
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> 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

Hi,

As someone have pointed out, the website is really in need of fixing.
I've been thinking of simplifying the management of the site by
turning it into a wiki.  However, I am not sure which one to use.  I
am currently working on a wiki[1] using Markdown and which I could
use, but it's written in Lua and uses a Lua implementation of MD.  So,
using it may be a bit strange.  So, I would prefer to use a simple
wiki that uses python-markdown.  Does anyone have any suggestions?
Part of what defines "simple" for me is not having to use a database.

  - yuri

[1]: http://www.freewisdom.org/projects/sputnik/

On the main Python Markdown page
(http://www.freewisdom.org/projects/python-markdown/), I noticed 4
links that seem to be broken:

Under "Extensions" (on the left):

* "Table of Contents"
* "Wiki Links"
* "Python Code Highlighting"

And under "Related Projects":

* mkdn2latex

---John