I've observed people just seem to get into a dead end whilst reading my ikiwiki instances.

They don't want to back out of post to an index. They want an easy button to click next or previous post, like what you find on Wordpress sites.

http://codex.wordpress.org/Next_and_Previous_Links

Jekyll's implementation looks rather neat:

This is a perfect use for wikitrails, of which my ?trail plugin is an implementation. Code review on that plugin would be welcome; it might even get merged one day.

The trail plugin is very likely to be merged soon, and is already available. So, closing this bug report done --Joey

Unfortunately, IkiWiki blogs use a PageSpec to define the set of "posts" in the blog (through which the next/prev trail should range), and the current implementation of ?trail in terms of typed links would have a circular dependency if used with a PageSpec: typed links have to be added before PageSpecs are evaluated, because "A links to B" is something that can be in a PageSpec; but if you want to add typed links ("A is part of trail B" in this case) based on a PageSpec, then the PageSpec must be evaluated before the typed links can be added. Chicken/egg.

One solution would be to make the trail plugin use its own data structure, like album used to do, instead of typed links: at scan time, the trail plugin would just record what the PageSpec was, and delay actually evaluating the PageSpec until the beginning of the render stage (after all pages have been scanned). This reduces the generic usefulness of typed links, though - in particular you can no longer use "is part of trail A" in a PageSpec. --smcv

Version 3 of ?trail now does this. For traillink and trailitem it additionally adds a typed link, which it does not itself consume; for trailinline and trail it doesn't. --smcv

Indeed, I know the problem; I ran into the same kind of thing with my report plugin and its trail concept. I simply had to declare that one couldn't use "trail" and "maketrail" options within the same report. That way, "maketrail" will add links in the "scan" pass, and "trail" will test for links in the "build" pass. That usually works. --KathrynAndersen

I'm not sure that even that is quite right: if your trail takes pagespecs as arguments, then it's potentially evaluating those pagespecs before all pages have been scanned, which could mean it lists pages which matched the spec before a recent change, or doesn't list pages which didn't previously match the spec but do now.

In version 3 of ?trail I ended up storing uninterpreted pagespecs and links at scan time, and evaluating them the first time a page is built. I think that's sufficiently lazy to give the right answer... --smcv

Do you have an example? --hendry

Now linked on the plugin's page - it doesn't pretend to be a blog, but the second demo is a trailinline, so you could do that with blog posts just as well. Making album require trail v3, and trying it out on my blog, are next on the list. --smcv

Sorry thank link http://demo.hosted.pseudorandom.co.uk/trail2/ doesn't work. I get a forbidden. --hendry

wishlist