mkdir -p ikiwiki-tag-test/raw/a_dir/ ikiwiki-tag-test/rendered/
echo '[[!taglink  a_tag]]' > ikiwiki-tag-test/raw/a_dir/a_page.mdwn
ikiwiki --verbose --plugin tag --plugin autoindex --plugin mdwn --set autoindex_commit=0 --set tagbase=tag --set tag_autocreate=1 --set tag_autocreate_commit=0 ikiwiki-tag-test/raw/ ikiwiki-tag-test/rendered/
ls -al ikiwiki-tag-test/raw/.ikiwiki/transient/
ls -al ikiwiki-tag-test/rendered/tag/

Shouldn't ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn and ikiwiki-tag-test/rendered/tag/index.html exist?

To have a starting point to (maybe) change this, my ready/autoindex branch adds a regression test for the current behaviour, both with and without autoindex_commit enabled. It also fixes an unnecessary and potentially harmful special case for the transient directory.

The fact that files in underlays (including transient files) don't trigger autoindexing is deliberate. However, this is the second request to change this behaviour: the first was Debian bug #611068, which has a patch from Tuomas Jormola. On that bug report, Joey explains why it's undesirable for the original behaviour of autoindex (when the index isn't transient).

I'm not sure whether the same reasoning still applies when the index is transient, though (autoindex_commit => 0), because the index pages won't be cluttering up people's git repositories any more? My autoindex-more branch changes the logic so it will do what you want in the autoindex_commit => 0 case, and amends the appropriate regression test. --smcv

the autoindex-more-often branch looks good to me in general.

i do have doubts about the 3ba2ef1a patch ("remove unnecessary special case for transient underlay"): now that we consider the complete transient directory as well, the sequence in which the refresh hooks are called starts to matter, and pages created by other plugins in a similar fashion as by autoindex will only be included the next time refresh gets called.

addendum: i just found where i discussed the issue of fighting transient pages last, it was on alias directive. the example cited there (conflicts with autotag) would probably work here as well. (imagine a tags/project/completed and a tags/project/inprogress exist, and a page is tagge tags/project. will that be an autoindex or an autotag?)

--chrysn

That's a fair point. I think what happens is down to commit vs. refresh timing.

If pages tagged t/p/c, t/p/i and t/p are all created between one refresh and the next, with none of those tag pages existing, I think the answer is that they would all be autotags, because until t/p/c and t/p/i are created, there's no reason to need t/p as an autoindex.

If there were already pages tagged t/p/c and t/p/i at the previous refresh, then t/p would already be an autoindex, and that's a valid page, so autotagging wouldn't touch it.

I can't see much reason to prefer one over the other; the ideal answer is probably to have a tag-cloud and a list of child pages, but this seems a weird enough thing to do that I'd be OK with a wiki user having to disambiguate it themselves. "Whichever automatic process happens first, happens" is at least easy to explain, and I consider both autoindices and autotags to be time-saving conveniences rather than something fundamental. --s

i think a behavior that does the right thing when there is a right thing and something when there is ambiguity is ok for now; especially, it's not up to the autoindex branch to come up with a solution to the general problem. --chrysn

Merged --smcv