img: Bugfix to width/height tags for scaled down image when only one dimension was...

[ikiwiki.git] / 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 896998bf8226fecee343faab3f1cdd58ac181584..23b9fd2ccc3435ae143deb5aaaa9a28c01daa901 100644 (file)
--- a/doc/bugs/conditional_preprocess_during_scan.mdwn
+++ b/doc/bugs/conditional_preprocess_during_scan.mdwn
@@ -8,3 +8,50 @@ 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.
+
+>>> 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.