X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/6eb89492f7b98003227fddeea6bb03d0f36b5d88..a1614ba8c5397a7342cc72cbd104db00122662e5:/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn?ds=sidebyside

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 225a60141..0673aa674 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -40,4 +40,35 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te
 >> 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 [[todo/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]]