Ikiwiki's preprocessor parser cannot deal with arbitrary nested preprocesor directives. It's possible to nest a directive with single quoted values inside a triple-quoted value of a directive, but that's all. It's not possible to unambiguously parse nested quotes, so to support nesting, a new syntax would be needed. Maybe something xml-like? > You can, however, unambiguously parse nested square brackets, and I think > that would solve the problem, as long as you never allow the contents of a > directive to contain a *partial* directive, which seems reasonable to me. > > For example, I *think* you can unambiguously parse the following: > > \[[!if test="enabled(template) and templates/foo" then=""" > [[!template id=foo content="""Flying Purple People Eater"""]] > """]] > > --[[JoshTriplett]] >> Yes it's definitely possible to do something like that. I'm not 100% >> sure if it can be done in perl regexp or needs a real recursive descent >> parser though. >> >> In the meantime, this is an interesting approach: >> >> >> \[[!directive text=\<\> ... >> FOO]] >> >> Since that's implemented, I will probably just merge it, >> once I satisfy myself it doesn't blow up in any edge cases. >> (It also adds triple single quotes as a third, distinct type of quotes, >> which feels a bit redundant given the here docs.) --[[Joey]] >> >> Hmm, that patch changes a `m///sgx` to a `m///msgx`. Meaning >> that any '^' or '$' inside the regexp will change behavior from matching >> the start/end of string to matching the start/end of individual lines >> within the string. And there is one legacy '$' which must then >> change behavior; the "delimiter to next param". >> >> So, I'm not sure what behavior that will cause, but I suspect it will >> be a bug. Unless the `\s+|$' already stops matching at a newline within >> the string like it's whitespace. That needs more alalysis. >> >> Also, the patch seems incomplete, only patching the first regexp >> but not the other two in the same function, which also are quoting-aware. --[[Joey]]