[pmwiki-users] recipes on core elements

Joachim Durchholz jo at durchholz.org
Thu Sep 1 17:44:12 CDT 2005

Radu schrieb:
> At 04:04 PM 9/1/2005, Joachim Durchholz wrote:
>> The best way out is to make the extension non-core if at all possible, 
>> e.g. by rewriting it as a new markup,
> I have this aversion of creating new markups or using large numbers of 
> them; the order has to be checked and rechecked for a myriad 
> combinations,

That's not *that* difficult. Just make sure that the markup doesn't 
"look like" parts of another markup.

 > recipes can collide,

That's independent of whether you make it a markup or anything else.

 > the markup table is processed almost
> entirely each time a new markup is declared...

AFAIK it isn't. Markup table creation is a two-step process: first, 
PmWiki collects all the rules, and only when the first MarkupToHTML call 
is done it actually creates the sorted markup table.

Otherwise, PmWiki would have been swamped with markup table creation 
already - reprocessing the entire table with each new rule is an O(N*N) 
process, and at roughly 100 markups, adding yet another markup would add 
a significant factor. (The two-step process is O(N log N) AFAICT.)

> And from the point of view of the authors (the ones I deal with at 
> least), the less markup they have to remember, and the closer it fits 
> their goals with fewer keystrokes, the better :)

Well, adding yet another markup certainly isn't the best route for every 

>>  or by installing a markup in place of an existing one (that's more 
>> potential for conflicts, of course),
> That's the method I'm currently using. Why do you say it's more 
> conflicting than adding new markup?

Because you have to make sure that the original purpose of the markup is 
still met by your code, and such things are notoriously tricky.
Been there, tried that, then found a better way to do what I wanted :-)

IOW markup shouldn't be used unless it's the least evil ;-)


More information about the pmwiki-users mailing list