I agree this is unexpected after playing around with it. See http://pmwiki.org/wiki/Test/IfNested and http://pmwiki.org/wiki/PmWiki/ConditionalMarkup
It is worth noting though that PmWiki does not do a lot of recursive descent parsing of expressions, hence the need to 'name' DIVs when nesting them. It looks to me like the ELSE is being associated (incorrectly) with the first IF rather than the second one as your examples and tests show. I am puzzled why we can't name IFs (as we can DIVs) to get the effect you want. To solve your problem I suggest you look at multiple condition IFs Simon 2009/6/20 DaveG <pmw...@solidgone.com> > After 4 hours debugging I discovered what I think is a bug if the > conditional logic. Or perhaps nested conditions work differently to how > I'd expect -- if so, how do I accomplish . > > (this was tested on pmwiki.org) > > This markup: > (:if equal 1 2:)111(:if equal 2 3:)222(:else:)333(:if:)444(:if:) > > produces: 333444 > expected: no output > odd: 444 is shown, but 111 is not > > This case: > (:if equal 1 2:)111(:if equal 2 > 3:)222(:else:)333(:if:)444(:else:)555(:if:) > > produces: 333444(:else:)555 > expected: 555 > odd: 444 is shown, but 111 is not > > Which seems to indicate nested else conditional markup is simply > ignored, or that the 444 is throwing things off. However this also > doesn't work: > (:if equal 1 2:)111(:if equal 2 > 3:)222(:else:)333(:endif:)(:else:)555(:endif:) > > produces: 333(:endif:) > expected: 555 > > ~ ~ Dave > > _______________________________________________ >
_______________________________________________ pmwiki-devel mailing list pmwiki-devel@pmichaud.com http://www.pmichaud.com/mailman/listinfo/pmwiki-devel