X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/2c2c537dd521bbc659f0499af72ca70078d97d50..81aa58e7ca0118fbb6e1b7f53e47f01d260cdbff:/doc/bugs/conditional_preprocess_during_scan.mdwn diff --git a/doc/bugs/conditional_preprocess_during_scan.mdwn b/doc/bugs/conditional_preprocess_during_scan.mdwn index baa430e19..1ba142331 100644 --- a/doc/bugs/conditional_preprocess_during_scan.mdwn +++ b/doc/bugs/conditional_preprocess_during_scan.mdwn @@ -1,4 +1,4 @@ -[[!template id=gitbranch branch=GiuseppeBilotta/scanif author="Giuseppe Bilotta"]] +[[!template id=gitbranch branch=GiuseppeBilotta/scanif author="[[GiuseppeBilotta]]"]] When a directive that should be run during scan preprocessing is inside an if directive, it doesn't get called because the if preprocessing does @@ -17,3 +17,41 @@ reprocessed is done so in the same conditions as the original call. > been scanned yet). If you have a clever idea for how to fix this, I'd love > to hear it - being able to specify a [[plugins/contrib/trail]] in terms > of a sorted pagespec would be useful. --[[smcv]] + +>> I have a solution to the dependency-ordering problem in a different +>> branch of my repository, with a post_scan hook mechanism which I use to +>> be able to sort outer inline pages according to the last modification +>> date of their nested inline pages. The way I implemented it currently, +>> though, doesn't use the existing hooks mechanism of ikiwiki (because +>> it's something which I believe to be more efficiently done the way I +>> implemented it) so I don't know how likely it is to be included +>> upstream. + +>> For what it's worth, I think that my post_scan hook mechanism would work +>> rather fine with your trail plugin. + +>>> We discussed this on IRC, and I think it's actually more complicated +>>> than that: the branch to sort by newest inlined entry wants a +>>> "pagespecs now work" hook, whereas for trail I want a "sorting now +>>> works" hook: +>>> +>>> * scan +>>> * pagespecs now work (post-scan) +>>> * Giuseppe's version of inline can decide what each inline +>>> contains, and thus decide where they go in `inline(mtime)` +>>> order +>>> * pagespecs and sorting now work (pre-render) +>>> * my trail plugin can decide what each trail contains, and +>>> also sort them in the right order (which might be +>>> `inline(mtime)`, so might be undefined until pagespecs work) +>>> * render +>>> +>>> --[[smcv]] + +>> However, the case of the if +>> directive is considerably more complicated, because the conditional +>> can introduce a much stronger feedback effect in the pre/post scanning +>> dependency. In fact, it's probably possible to build a couple of pages +>> with vicious conditional dependency circles that would break/unbreak +>> depending on which pass we are in. And I believe this is an intrinsic +>> limitation of the system, which cannot be solved at all.