Wow, this plugin does a lot... it seems to be `inline` (but without the feeds
or the ability to not have `archive="yes"`), plus part of
[[plugins/contrib/trail]], plus some sorting, plus an ingenious workaround
for template evaluation being relatively stateless.

A large part of this plugin would just fall off if one of the versions of
"[[todo/allow_plugins_to_add_sorting_methods]]" was merged, which was a
large part of the idea of that feature request :-) To make use of that
you'd have to use `pagespec_match_list` in the trail case too, but that's
easy enough - just add `list => [@the_trail_pages]` to the arguments.

Another large part would fall off if this plugin required, and internally
invoked, `inline` (like my `comments` plugin does) - `inline` runs
`pagetemplate` hooks, and in particular, it'll run the `field` hook.
Alternatively, this plugin could invoke `pagetemplate` hooks itself,
removing the special case for `field`.

Perhaps the `headers` thing could migrate into inline somehow? That might
lead to making inline too big, though.

> I think inline is *already* too big, honestly. --[[KathrynAndersen]]

>> A fair point; perhaps my complaint should be that *inline* does
>> too many orthogonal things. I suppose the headers feature wouldn't
>> really make sense in an inline that didn't have `archive="yes"`,
>> so it'd make sense to recommend this plugin as a replacement
>> for inlining with archive=yes (for which I now realise "inline"
>> is the wrong verb anyway :-) ) --s

Is the intention that the `trail` part is a performance hack, or a way
to select pages? How does it relate to [[todo/wikitrails]] or
[[plugins/contrib/trail]]? --[[smcv]]

> The `trail` part is *both* a performance hack, and a way to select pages.  I have over 5000 pages on my site, I need all the performance hacks I can get.
> For the performance hack, it is a way of reducing the need to iterate through every single page in the wiki in order to find matching pages.
> For the way-to-select-pages, yes, it is intended to be similar to [[todo/wikitrails]] and [[plugins/contrib/trail]] (and will be more similar with the new release which will be happening soon; it will add prev_* and next_* variables).
> The idea is that, rather than having to add special "trail" links on PageA to indicate that a page is part of the trail,
> it takes advantage of the `%links` hash, which already contains, for each page, an array of the links from that page to other pages.  No need for special markup, just use what's there; a trail is defined as "all the pages linked to from page X", and since it's an array, it has an order already.
> But to avoid that being too limiting, one can use a `pages=...` pagespec to filter that list to a subset; only the pages one is interested in.
> And one can also sort it, if one so desires.
> --[[KathrynAndersen]] 

>> That's an interesting approach to trails; I'd missed the fact that
>> links are already ordered.
>>
>> This does have the same problems as tags, though: see
>> [[bugs/tagged()_matching_wikilinks]] and
>> [[todo/matching_different_kinds_of_links]]. I suppose the question
>> now is whether new code should be consistent with `tag` (and
>> potentially be fixed at the same time as tag itself), or try to
>> avoid those problems?
>>
>> The combination of `trail` with another pagespec in this plugin
>> does provide a neat way for it to work around having unwanted
>> pages in the report, by limiting by a suitable tag or subdirectory
>> or something. --s