> That is only acceptable if such parser were maintained as part > of the official moin distribution, and kept up-to-date with the > the rest of the features of a classical parser.
Yes, that would be better. It would also be better if we had more developers. :) > I had enough bad experience with unmaintained third-party macros > and themes, that I would not dare to venture into a third-party > parser without some firm statement that I won't be left high-and-dry > with the next release of moin. Yes, that's a general problem. Stuff needs maintenance. It doesn't get any different by including it into moin, you just expect the work done by the moin devs then. :) > Perhaps adding an option to "#format wiki" or some other pragma, > which could tell the official parser whether to recognize > camel case or not. The problem is not as easy as it maybe sounds. Aside from the help pages requiring camelcase currently, there is also the GUI editor expecting camelcase link behaviour from the "wiki" parser. Therefore that will also require changes if the wiki parser just gets a new param. Last but not least, we currently work on parsers / formatters working in a completely different way internally (using a dom tree). You see, doing that nocamelcase thing is much more work than just a quick hack. ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Moin-user mailing list Moin-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/moin-user
