From: smcv Date: Sun, 6 Jul 2014 21:35:18 +0000 (-0400) Subject: (no commit message) X-Git-Tag: debian/3.20140815~28^2~9 X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/commitdiff_plain/7bf7f2c442a9a5d89bed2d65a7a32b2af1f76157 --- diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn index 1fc80804e..887d3387f 100644 --- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn +++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn @@ -47,3 +47,23 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te >> 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