Re: writing a moin parser

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

On 6/14/05, Thomas Waldmann <[email protected]> wrote:
> > are there any docs anywhere on writing a moin parser?  i.e. how a
> > parser fits in with the rest of moin, the interfaces, etc.
>=20
> Not really, but there is some example code in MoinMoin/parser/*.py. :)
>=20
> And it is not THAT complicated.
>=20
> A parser gets the raw page text and must generate calls to the formatter
> to produce output.
>=20
> 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.
>=20
> > our users would like to be able to use a simpler wiki markup language
> > like in jspwiki.
>=20
> Maybe it is a good idea to make a page on the moinmoin wiki about that
> topic. There might be 2 different scenarios:
>=20
> 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! :)
>=20
> 2) You just want to improve the moinmoin default markup and parser.
>=20
> 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).
>=20
> Maybe get on #moin irc channel on irc.freenode.net to talk about it, if
> you want to help with that.
>=20
>=20
>=20
> -------------------------------------------------------
> 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=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Moin-devel mailing list
> [email protected]
> 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_id=7477&alloc_id=16492&op=click