that the page links to, which is just what link dependencies are
triggered on.
+[[done]]
----
### the removal problem
>>>> find changes in deleted pages. (I verified this works by experiment,
>>>> also that `created_after` is triggered by a deleted page.) --[[Joey]]
+>>>>> Oh, okie. I looked at the source, saw the `if (exists $IkiWiki::pagectime{$testpage})` and assumed it would fail.
+>>>>> Of course, having it succeed doesn't cure all the issues -- just moves them. With `created_before()` succeeding
+>>>>> for deleted files, this pagespec will be match any removal in the entire wiki with the base mechanism. Whether this is
+>>>>> better or worse than the longer indirect influence list is an empirical question. -- [[Will]]
+
* The pagespec "foo" has an empty influence list. This is because a
modification/creation/removal of foo directly changes what the pagespec
matches.
`HardFailReason() | SuccessReason(index)` =>
`SuccessReason(index)` => right
+Ok so far, but:
+
"!bugs/* and link(patch)" =>
-`HardFailReason() | SuccessReason(bugs/foo)` =>
-`HardFailReason()` => right
-
-#### 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]]
+`!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.
#### Influence types