sjstoelting/evolution — pull request #12 by TimGS (2012-05-01 00:05:54+00:00)
Title: Changed regex at the start of evalSnippets().

Previously, of the following combinations:

[[AA? ¶m=`[[BB]]`]]
[!AA? ¶m=`[!BB!]`!]
[!AA? ¶m=`[[BB]]`!]
[[AA? ¶m=`[!BB!]`]]

...two would never work, one would sometimes work, and only one (the third) would always (I think) work.

The problem was that the regex at the start of evalSnippets ignored the possibility of nesting. Nested snippets could only happen by virtue of evalSnippets being called twice via parseDocumentSource - once for cached snippets and once for uncached snippets.

This change ensures that nested snippets output as intended, regardless of the use of [[...]] or [!...!]. All the above combinations produce the correct output.

Caching or otherwise of snippets works except in the fourth case when an 'outer' snippet is intended to be cached and an inner is uncached. Currently the outer snippet will be executed uncached, regardless of whether [[...]] or [!...!] is used. It will however be executed, unlike the current situation where the code would sometimes not work.

I have only tested briefly with more than three levels of nesting, but as long as nesting does not exceed $maxParserPasses (highly unlikely) I expect the above principles to still apply. As above, snippets outer to an uncached snippet i.e. executing using the uncached snippet's results, will be run uncached regardless of the use of [[...]] or [!...!].

I intend looking into this remaining caching issue with the fourth case above, though I'm not really sure if this combination actually makes sense anyway. It may be best just leaving as is.