]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/bugs/conditional_preprocess_during_scan.mdwn
Added a comment
[git.ikiwiki.info.git] / doc / bugs / conditional_preprocess_during_scan.mdwn
index 896998bf8226fecee343faab3f1cdd58ac181584..254ebac22dc9c97a06d3e212c0c706c10c7a0656 100644 (file)
@@ -8,3 +8,30 @@ I've written a simple [[patch]] to fix the issue, currently hosted on the
 scanif branch of my repository. The patch also passes the preview option
 back to the Ikiwiki::preprocess call, making sure that whatever is being
 reprocessed is done so in the same conditions as the original call.
 scanif branch of my repository. The patch also passes the preview option
 back to the Ikiwiki::preprocess call, making sure that whatever is being
 reprocessed is done so in the same conditions as the original call.
+
+> One problem with this is that it has the same dependency-ordering problems
+> as inline-based or pagespec-based trails with my [[plugins/contrib/trail]]
+> plugin: `if` takes a pagespec, but pagespecs aren't guaranteed to match
+> correctly until everything has been scanned (for instance, `link()` might
+> give the wrong results because a page that added or deleted a link hasn't
+> 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. 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.