changes, then the dependent page is rebuilt. At the moment the implementation uses the same hack used by map and inline -
just add all the pages that currently exist as traditional content dependencies.
+ > As I note below, a problem with this approach is that it has to try
+ > matching the pagespec against every page, redundantly with the work done
+ > by the plugin. (But there are ways to avoid that redundant matching.)
+ > --[[Joey]]
+
Getting back to commenting on your proposal:
Just talking about the definition of a "presence dependency" for the moment, and ignoring implementation. Is a
`new_page` will match the spec, and yet `new_page` itself hasn't changed. Nor has its 'presence' - it was present
before and it is present now. Should this cause a re-build of any page that has a 'presence' dependency on the spec?
+ > Yes, a presence dep will trigger when a page is added, or removed.
+
+ > Your example is valid.. but it's also not handled right by normal,
+ > (content) dependencies, for the same reasons. --[[Joey]]
+
I think that is another version of the problem you encountered with meta-data.
In the longer term I was thinking we'd have to introduce a concept of 'internal pagespec dependencies'. Note that I'm
-- [[Will]]
+ > I have also been thinking about some sort of analysis pass over pagespecs
+ > to determine what metadata, pages, etc they depend on. It is indeed
+ > tricky to do. Even if it's just limited to returning a list of pages
+ > as you suggest.
+ >
+ > Consider: For a `*` glob, it has to return a list of all pages
+ > in the wiki. Which is expensive. And what if the pagespec is
+ > something like `* and backlink(index)`? Without analyising the
+ > boolean relationship between terms, the returned list
+ > will have many more items in it than it should. Or do we not make
+ > globs return their matches? (If so we have to deal with those
+ > with one of the other methods disucssed.) --[[Joey]]
+
----
### Link dependencies
* `add_depends($page, $spec, links => 1, presence => 1)`
adds a links + presence dependency.
-* `refresh` only rebuilds a page with a links dependency if
- pages matched by the pagespec gain or lose links. (What the link
- actually points to may change independent of this, due to changes
- elsewhere, without it firing.)
+* Use backlinks change code to detect changes to link dependencies too.
* So, brokenlinks can fire whenever any links in any of the
pages it's tracking change, or when pages are added or
removed.
that the page links to, which is just what link dependencies are
triggered on.
+[[done]]
----
### the removal problem
One way to fix this is to include with each dependency, a list of pages
that currently match it. If the list changes, the dependency is triggered.
- Should be doable, but seems to involve a more work than
+ Should be doable, but may involve more work than
currently. Consider that a dependency on "bugs/*" currently
is triggered by just checking until *one* page is found to match it.
But to store the list, *every* page would have to be tried against it.
Unless the list can somehow be intelligently updated, looking at only the
- changed pages.
+ changed pages.
+
+ ----
+
+ What if there were a function that added a dependency, and at the same time
+ returned a list of pages matching the pagespec? Plugins that use this would
+ be exactly the ones, like inline and map, for which this is a problem, and
+ which already do a match pass over all pages.
+
+ Adding explicit dependencies during this pass would thus be nearly free.
+ Not 100% free since it would add explicit deps for things that are not
+ shown on an inline that limits its display to the first sorted N items.
+ I suppose we could reach 100% free by making the function also handle
+ sorting and limiting, though that could be overkill.