propose a branch which uses non-numeric `show` for this purpose

[git.ikiwiki.info.git] / doc / todo / nested_preprocessor_directives.mdwn

diff --git a/doc/todo/nested_preprocessor_directives.mdwn b/doc/todo/nested_preprocessor_directives.mdwn
index 0fb624bcf34a2fcfc4838548bf56bcc97d33433b..433fc6f37bc2cdf50f16b1c6fcbbeb6ae419f226 100644 (file)
--- a/doc/todo/nested_preprocessor_directives.mdwn
+++ b/doc/todo/nested_preprocessor_directives.mdwn
@@ -20,13 +20,16 @@ nesting, a new syntax would be needed. Maybe something xml-like?
 >> 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.
 >> 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.

+>> 
+>> [[!template id=gitbranch branch=timonator/heredoc_triplequote author="\[[timonator]]"]]

 >>
 >> In the meantime, this is an interesting approach:
 >>
 >> In the meantime, this is an interesting approach:

->> <https://github.com/timo/ikiwiki/commit/a73837a8f26147e42a0bb2dde38b4890b27822b3>
+>> <https://github.com/timo/ikiwiki/commit/410bbaf141036164f92009599ae12790b1530886>
+>> (the link has since been fixed twice)

 >> 
 >> 

->>     \[[!directive text=\<\<FOO
->>     ...
->>     FOO]]
+>>     \[[!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.
 >> 
 >> Since that's implemented, I will probably just merge it,
 >> once I satisfy myself it doesn't blow up in any edge cases.


@@ -42,6 +45,25 @@ nesting, a new syntax would be needed. Maybe something xml-like?
 >> 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. 
 >> 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]] 
 >>
 >> 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]] 

+>>
+>> Yes, I'm terribly sorry. I actually did edit the other two regexps, but
+>> I apparently missed copying it over as well. Should have been doing this
+>> in a git repo all along. Look at the new commit I put atop it that has
+>> the rest as well:
+>> (redacted: is now part of the commit linked to from above)
+>> Also: I'm not sure any more, why I added the m modifier. It was very
+>> late at night and I was getting a bit desperate (turned out, the next
+>> morning, I put my extra regexes after the "unquoted value" one. heh.)
+>> So, feel free to fix that. --Timo
+>>
+>> I've fixed the patch by rebasing, fixed the link above. I'm still not
+>> sure if the m modifier for the regex is still needed (apparently I
+>> didn't put it in the other regexes. Not completely sure about the
+>> implications.) Am now trying to wrap my head around a test case to
+>> test the new formats for a bit. --Timo
+
+[[done]]!!! --[[Joey]]