-#### High-level Calculation and Storage
-
-Naively calculating the full influence list for a pagespec requires trying
-to match it against every page in the wiki. I'd like to avoid doing such
-expensive matching redundantly.
-
-It may be possible, for some types of pagespecs, to just try matching a
-single, arbitrary page against it, and know the full influence list has
-been obtained. It seems to be that case that if a pagespec has any
-influences, matching any page will return at least one. So if none are
-returned, we can skip trying other pages.
-
-If the influence list does not include the page that was tried, we know
-that the pagespec does not things like `link()` and `title()`, that are
-influenced by the page's own content. So it *might* be safe to not try
-matching any more pages in this case too. I think it would work for all
-current pagespec terms. There might be a hypothetical term where this
-optimisation doesn't work. We could add a special case to ensure it can
-work: If a term declares it is unfluenced by "", then it means it is
-always influenced by the matching page.
-
-Anyway, this seems worth doing: Add a `pagespec_match_all`, which returns a
-list of all pages in the whole wiki that match the pagespec, and also adds
-the pagespec as a dependency, and while it's at it, calculates and stores
-the influence list.
-
-It could have an optional sort parameter, and limit parameter, to control
-how many items to return and the sort order. So when inline wants to
-display the 10 newest, only the influence lists for those ten are added.
-
-If `pagespec_match_depends` can be used by all plugins, then great,
-influences are automatically calculated, no extra work needs to be done.
-
-If not, and some plugins still need to use `pagespec_match_list` or
-`pagespec_match`, and `add_depends`, then I guess that `add_depends` can do
-a slightly more expensive influence calculation.
-
-Bonus: If `add_depends` is doing an influence calculation, then I can remove
-the nasty hack it currently uses to decide if a given pagespec is safe to use
-with an existence or links dependency.
-
-Where to store the influence list? Well, it appears that we can just add
-(content) dependencies for each item on the list, to the page's
-regular list of simple dependencies. So, the data stored ends up looking
-just like what is stored today by the explicit dependency hacks. Except,
-it's calculated more smartly, and is added automatically.
-
-> I've implemented influence calculation in `add_depends`. As expected,
-> it means rather a lot more work, and makes some things much slower.
-> Optimisations next.. --[[Joey]]
+----
+
+Here is a case where this approach has some false positives.
+
+"bugs/* and link(patch)"
+
+This finds as influences all pages that link to patch, even
+if they are not under bugs/, and so can never match.
+
+To fix this, the influence calculation would need to consider boolean
+operators. Currently, this turns into roughly:
+
+`FailReason() & SuccessReason(patch)`
+
+Let's say that the glob instead returns a HardFailReason, which when
+ANDed with another object, drops their influences. (But when ORed, combines
+them.) Fixes the above, but does it always work?
+
+"(bugs/* or link(patch)) and backlink(index)" =>
+`( HardFailReason() | SuccessReason(page) ) & SuccessReason(index)`` =>
+`SuccessReason(page & SuccessReason(index)` =>
+SuccessReason(page, index) => right
+
+"(bugs/* and link(patch)) or backlink(index)" =>
+`( HardFailReason() & SuccessReason(page) ) | SuccessReason(index)`` =>
+`HardFailReason() | SuccessReason(index)` =>
+`SuccessReason(index)` => right
+
+Ok so far, but:
+
+"!bugs/* and link(patch)" =>
+`!SuccessReason() | SuccessReason(bugs/foo)` =>
+'FailReason() | SuccessReason(bugs/foo)
+`FailReason(bugs/foo)` => wrong!
+
+This could be fixed by adding a HardSuccessReason that glob also returns.
+Maybe just a field of the object that is set if it is "hard" is a better
+approach though.