2011-04-11 23:49:45 +02:00
|
|
|
mkdir -p ikiwiki-tag-test/raw/a_dir/ ikiwiki-tag-test/rendered/
|
2012-04-09 16:46:58 +02:00
|
|
|
echo '\[[!taglink a_tag]]' > ikiwiki-tag-test/raw/a_dir/a_page.mdwn
|
2011-04-11 23:49:45 +02:00
|
|
|
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?
|
2012-04-09 16:46:58 +02:00
|
|
|
|
2014-07-04 10:28:17 +02:00
|
|
|
[[!tag patch users/smcv/ready]]
|
2014-07-04 10:27:37 +02:00
|
|
|
[[!template id=gitbranch branch=smcv/ready/autoindex author=smcv
|
|
|
|
browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex]]
|
|
|
|
[[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv
|
|
|
|
browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex-more-often]]
|
2012-04-09 16:46:58 +02:00
|
|
|
|
|
|
|
> 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
|
|
|
|
> [[!debbug 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]]
|
2014-07-05 16:42:32 +02:00
|
|
|
|
|
|
|
>> 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.
|
|
|
|
>>
|
2014-07-06 14:25:14 +02:00
|
|
|
>> *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?)
|
|
|
|
>>
|
2014-07-05 16:42:32 +02:00
|
|
|
>> --[[chrysn]]
|
2014-07-06 23:35:18 +02:00
|
|
|
|
|
|
|
>>> 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
|
2014-07-06 23:47:06 +02:00
|
|
|
|
|
|
|
>>>> 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]]
|