doc/todo/nested_preprocessor_directives.mdwn

   1 Ikiwiki's preprocessor parser cannot deal with arbitrary nested preprocesor
   2 directives. It's possible to nest a directive with single quoted values
   3 inside a triple-quoted value of a directive, but that's all.
   4
   5 It's not possible to unambiguously parse nested quotes, so to support
   6 nesting, a new syntax would be needed. Maybe something xml-like?
   7
   8 > You can, however, unambiguously parse nested square brackets, and I think
   9 > that would solve the problem, as long as you never allow the contents of a
  10 > directive to contain a *partial* directive, which seems reasonable to me.
  11 >
  12 > For example, I *think* you can unambiguously parse the following:
  13 >
  14 >     \[[!if test="enabled(template) and templates/foo" then="""
  15 >     [[!template id=foo content="""Flying Purple People Eater"""]]
  16 >     """]]
  17 >
  18 > --[[JoshTriplett]]
  19
  20 >> Yes it's definitely possible to do something like that. I'm not 100%
  21 >> sure if it can be done in perl regexp or needs a real recursive descent
  22 >> parser though.
  23 >>
  24 >> In the meantime, this is an interesting approach:
  25 >> <https://github.com/timo/ikiwiki/commit/a73837a8f26147e42a0bb2dde38b4890b27822b3>
  26 >>
  27 >>      \[[!directive text=\<\<FOO
  28 >>      ...
  29 >>      FOO]]
  30 >>
  31 >> Since that's implemented, I will probably just merge it,
  32 >> once I satisfy myself it doesn't blow up in any edge cases.
  33 >> (It also adds triple single quotes as a third, distinct type of quotes,
  34 >> which feels a bit redundant given the here docs.) --[[Joey]]
  35 >>
  36 >> Hmm, that patch changes a `m///sgx` to a `m///msgx`. Meaning
  37 >> that any '^' or '$' inside the regexp will change behavior from matching
  38 >> the start/end of string to matching the start/end of individual lines
  39 >> within the string. And there is one legacy '$' which must then
  40 >> change behavior; the "delimiter to next param".
  41 >>
  42 >> So, I'm not sure what behavior that will cause, but I suspect it will
  43 >> be a bug. Unless the `\s+|$' already stops matching at a newline within
  44 >> the string like it's whitespace. That needs more alalysis.
  45 >> Update: seems it does, I'm fairly satisfied that is not a bug.
  46 >>
  47 >> Also, the patch seems incomplete, only patching the first regexp
  48 >> but not the other two in the same function, which also are quoting-aware. --[[Joey]]
  49 >>
  50 >> Yes, I'm terribly sorry. I actually did edit the other two regexps, but
  51 >> I apparently missed copying it over as well. Should have been doing this
  52 >> in a git repo all along. Look at the new commit I put atop it that has
  53 >> the rest as well:
  54 >> <https://github.com/timo/ikiwiki/commit/a4e33d9654404acff71344cd5d3672bcdf3f3ce5>
  55 >> Also: I'm not sure any more, why I added the m modifier. It was very
  56 >> late at night and I was getting a bit desperate (turned out, the next
  57 >> morning, I put my extra regexes after the "unquoted value" one. heh.)
  58 >> So, feel free to fix that. --Timo