[pmwiki-users] Questions and cookbooks proposals

PyG pyg_listes at exiup.com
Mon Aug 22 04:28:55 CDT 2005


Hi John
To be short, I think you're right about the issues that could generate 
integration of widely used cookbook markup into core markup.

>If they join the core, could we do this
>in a way that minimises impact on dependent code?

I have no idea of what happen in PmWiki if a markup is declared twice : 
once in the core, and once in cookbooks (for what I know markup() just push 
an array item, so last declaration should replace old ones).
So maybe it's possible to include them in the core and still say to the 
wikipublisher users that they need extendedmarkup's cookbook (even if it 
replace some core markup)? Complex question, and I have no answer.
But if wikipublisher "installator" (= the wiki admin) is warned in 
documentation ("be carefull : extendmarkup replace footnotes core markup by 
his own footnotes markup, so there is a risk that existing footnotes won't 
work anymore as expected"), it shouldn't raise lots of problems (just some 
testing).

>These might be pre-loaded in the cookbook/ or skin/ directories,
>but disabled by default.
Hum, I think it's too close of the "bundle" concept to be accepted by Pm?

In fact, PmWiki is a very extensible tool, and I understand that Pm wants 
to Keep It Stupid Simple, and force admins to add/reject cookbooks to meet 
users' need, even if it's not easy for non experienced PmWiki admins.
But I still think that footnotes and (:toc:) meet PmWiki Philosophy n°1 
("Favor writers over readers ") : it's just seem weird to mee that we have 
some core advanced writing markups like "->" or "Q:", and no way to add 
footnotes or Table of contents (for me it's not "creeping featurism" : 
those markups are as essentials as "!" or "%center%" to *any* writer).

Maybe the problem is not "what to include and let disabled by default?" but 
"how to achieve PmWiki Philosophy n°5 (Be easy to install, configure, and 
maintain) more completly?" with a simplier way to install/enable/disable 
cookbooks (special page with a cookbook list, and just clicking a link to 
download/install/remove and ticking checkboxes to enable/disable) ? (that's 
a cool idea, but it seems quite complicated to achieve, huh ? ;) )

Thanks again for your answer and your great work ont PmWiki ;)
Pierre-Yves




At 00:21 22/08/2005, you wrote:
>On Saturday, 20 August 2005 7:24 AM, PYG <pyg_listes at exiup.com> wrote:
> >Hello world
> >3. Maybe footnotes ability (from jr's extendedmarkup [^ ^]) and Table of
> >contents (:toc:) should be added to core markups ?
> >I manage about 6 wiki's on very different subjects and there was
> >*always* a good reason to add them as cookbooks. It's not the time it
> >takes, but maybe new users should be happy to use them witout wondering
> >how to install them. I use many other custom (or jr) markups, but thoses
> >  seems quite essential for me (and my authors).
>
>I'm glad you find these useful. A comment about adding them to the core:
>The wikipublisher library, which typesets page collections into printable
>pdf, needs to be aware of these and other extensions, so it can do the
>right thing when processing them. If they join the core, could we do this
>in a way that minimises impact on dependent code?
>
>I am happy for both to be added 'as is' to the core -- they work to
>specification and are stable. They can always be improved, of course.
>It may be worth considering something between 'core' and 'cookbook' --
>third party recipes that are distributed with PmWiki, do not conflict
>with one another, but for which PmWiki is not responsible.
>
>These might be pre-loaded in the cookbook/ or skin/ directories,
>but disabled by default.
>
>The biggest problem I see with such an approach is that changes to
>the PmWiki core may break the add-ons. It's not reasonable to expect
>PmWiki to take responsibility for testing this, so we would need a
>disciplined approach to distributed testing of non-core modules.
>
>--
>JR
>--
>John Rankin





More information about the pmwiki-users mailing list