]> sipb.mit.edu Git - ikiwiki.git/commitdiff
summarize IRC discussion
authorhttp://smcv.pseudorandom.co.uk/ <smcv@web>
Mon, 14 Nov 2011 10:50:37 +0000 (06:50 -0400)
committeradmin <admin@branchable.com>
Mon, 14 Nov 2011 10:50:37 +0000 (06:50 -0400)
doc/bugs/conditional_preprocess_during_scan.mdwn

index 254ebac22dc9c97a06d3e212c0c706c10c7a0656..23b9fd2ccc3435ae143deb5aaaa9a28c01daa901 100644 (file)
@@ -28,7 +28,27 @@ reprocessed is done so in the same conditions as the original call.
 >> upstream.
 
 >> For what it's worth, I think that my post_scan hook mechanism would work
 >> upstream.
 
 >> For what it's worth, I think that my post_scan hook mechanism would work
->> rather fine with your trail plugin. However, the case of the if
+>> 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
 >> 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