Welcome to 2019
[ikiwiki.git] / 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 >> [[!template id=gitbranch branch=timonator/heredoc_triplequote author="\[[timonator]]"]]
25 >>
26 >> In the meantime, this is an interesting approach:
27 >> <https://github.com/timo/ikiwiki/commit/410bbaf141036164f92009599ae12790b1530886>
28 >> (the link has since been fixed twice)
29 >> 
30 >>     \[[!directive text=<<FOO 
31 >>     ...
32 >>     FOO]]
33 >> 
34 >> Since that's implemented, I will probably just merge it,
35 >> once I satisfy myself it doesn't blow up in any edge cases.
36 >> (It also adds triple single quotes as a third, distinct type of quotes,
37 >> which feels a bit redundant given the here docs.) --[[Joey]] 
38 >>
39 >> Hmm, that patch changes a `m///sgx` to a `m///msgx`. Meaning
40 >> that any '^' or '$' inside the regexp will change behavior from matching
41 >> the start/end of string to matching the start/end of individual lines 
42 >> within the string. And there is one legacy '$' which must then 
43 >> change behavior; the "delimiter to next param".
44 >>
45 >> So, I'm not sure what behavior that will cause, but I suspect it will
46 >> be a bug. Unless the `\s+|$' already stops matching at a newline within
47 >> the string like it's whitespace. That needs more alalysis. 
48 >> Update: seems it does, I'm fairly satisfied that is not a bug.
49 >>
50 >> Also, the patch seems incomplete, only patching the first regexp
51 >> but not the other two in the same function, which also are quoting-aware. --[[Joey]] 
52 >>
53 >> Yes, I'm terribly sorry. I actually did edit the other two regexps, but
54 >> I apparently missed copying it over as well. Should have been doing this
55 >> in a git repo all along. Look at the new commit I put atop it that has
56 >> the rest as well:
57 >> (redacted: is now part of the commit linked to from above)
58 >> Also: I'm not sure any more, why I added the m modifier. It was very
59 >> late at night and I was getting a bit desperate (turned out, the next
60 >> morning, I put my extra regexes after the "unquoted value" one. heh.)
61 >> So, feel free to fix that. --Timo
62 >>
63 >> I've fixed the patch by rebasing, fixed the link above. I'm still not
64 >> sure if the m modifier for the regex is still needed (apparently I
65 >> didn't put it in the other regexes. Not completely sure about the
66 >> implications.) Am now trying to wrap my head around a test case to
67 >> test the new formats for a bit. --Timo
68
69 [[done]]!!! --[[Joey]]