summaryrefslogtreecommitdiff
path: root/doc/todo/nested_preprocessor_directives.mdwn
blob: 3094e0899c919018dd752a2780119776890850ce (plain)

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: https://github.com/timo/ikiwiki/commit/a73837a8f26147e42a0bb2dde38b4890b27822b3

[[!directive text=<<FOO ... 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. Update: seems it does, I'm fairly satisfied that is not a bug.

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]]