My immediate goal is to make the moin markup simpler, not to replicate
jspwiki syntax per se, just to make it simple enough to migrate from
jspwiki w/o resistance from our userbase.
I got a bit lost when working with the big ugly re, especially when it
came to it referencing the unicode character map. I'm going to have
to read up a bit on how unicode works in Python.
Also, the standard wiki.py parser does some things with string
substitution I had never seen before (substituting named placeholders
with values from a dictionary, rather than substituting generic
placeholders linearly from a tuple), which kind of confused me at
first, but now that I understand it . . . I see it's a really cool way
to do a large number of substitutions.
I'll dig around some more and hopefully find a way out to freenode
from our network.
Thanks for all the info!!!
-j
Post by Thomas WaldmannPost by jacob martinsonare there any docs anywhere on writing a moin parser? i.e. how a
parser fits in with the rest of moin, the interfaces, etc.
Not really, but there is some example code in MoinMoin/parser/*.py. :)
And it is not THAT complicated.
A parser gets the raw page text and must generate calls to the formatter
to produce output.
The existing wiki parser does this by parsing the raw page line-per-line
with that big ugly regular expression and doing formatter calls
depending on what matched. It keeps some state in variables like in_pre
or in_table.
Post by jacob martinsonour users would like to be able to use a simpler wiki markup language
like in jspwiki.
Maybe it is a good idea to make a page on the moinmoin wiki about that
1) You want to make a jspwiki compatible parser as an additional parser
for moin (because your users are used to that and you have data in that
markup). Good luck in that case! :)
2) You just want to improve the moinmoin default markup and parser.
We also want that, but there definitely needs to be some very concrete
and common plan to make this work. E.g. we want to simplify the link
markup, which is currently too complicated and too irregular. Same thing
applies to "include" long-term. We also want to generate xhtml at some
time, but with that line-by-line parser it won't be possible. We also
want to use DOM to make include work better. attachments shall be
unified (in storage as well as in linking / including).
Maybe get on #moin irc channel on irc.freenode.net to talk about it, if
you want to help with that.
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Moin-devel mailing list
https://lists.sourceforge.net/lists/listinfo/moin-devel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click