1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
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.
>>
>> 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]]
|