From cf7d03ec80e168ad18d65a90842773da353ee060 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sat, 9 Jan 2010 22:57:11 +0100 Subject: fixed bug in my po branch, please pull --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index ae59e14c2..55968e3d7 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -2,3 +2,5 @@ Using the po plugin, a link to /bla is present in the sidebar. When viewing /bla in the default language, this link is detected as a selflink. When viewing a translation of /bla, it isn't. --[[intrigeri]] + +Fixed in my po branch => [[!tag patch]]. --[[intrigeri]] -- cgit v1.2.3 From 62a67e161bccba431b8b8a501967ba7acf6e197a Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sat, 9 Jan 2010 22:59:46 +0100 Subject: wiki syntax fix --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index 55968e3d7..87fa38911 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -3,4 +3,6 @@ When viewing /bla in the default language, this link is detected as a selflink. When viewing a translation of /bla, it isn't. --[[intrigeri]] -Fixed in my po branch => [[!tag patch]]. --[[intrigeri]] +Fixed in my po branch. --[[intrigeri]] + +[[!tag patch]] -- cgit v1.2.3 From 1ddef7da7b170bb4bd7c816cba03e3e6338a50b2 Mon Sep 17 00:00:00 2001 From: "http://edrex.myopenid.com/" Date: Sun, 17 Jan 2010 07:22:03 +0000 Subject: --- doc/todo/svg.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'doc/todo') diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn index 0a15af4cd..f264f4107 100644 --- a/doc/todo/svg.mdwn +++ b/doc/todo/svg.mdwn @@ -3,6 +3,7 @@ We should support SVG. In particular: * We could support rendering SVGs to PNGs when compiling the wiki. Not all browsers support SVG yet. * We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup. + * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated --[EricDrechsel]] --[[JoshTriplett]] -- cgit v1.2.3 From 5588abc2befbde83e43cf79f9717e323aa69da11 Mon Sep 17 00:00:00 2001 From: "http://edrex.myopenid.com/" Date: Sun, 17 Jan 2010 07:22:54 +0000 Subject: --- doc/todo/svg.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn index f264f4107..89b183db6 100644 --- a/doc/todo/svg.mdwn +++ b/doc/todo/svg.mdwn @@ -3,7 +3,7 @@ We should support SVG. In particular: * We could support rendering SVGs to PNGs when compiling the wiki. Not all browsers support SVG yet. * We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup. - * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated --[EricDrechsel]] + * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated -- [[EricDrechsel]] --[[JoshTriplett]] -- cgit v1.2.3 From deb0bc8bd57bc74709ecb12de36a9cb96c684a93 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 2 Feb 2010 02:56:06 -0800 Subject: New todo item for wrapperuser configuration option --- doc/todo/wrapperuser.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/todo/wrapperuser.mdwn (limited to 'doc/todo') diff --git a/doc/todo/wrapperuser.mdwn b/doc/todo/wrapperuser.mdwn new file mode 100644 index 000000000..4c42b046f --- /dev/null +++ b/doc/todo/wrapperuser.mdwn @@ -0,0 +1,7 @@ +ikiwiki's .setup file can specify wrappergroup, and ikiwiki will set the group +of the wrappers accordingly. Having had people encounter difficulty before +when trying to do the same thing with users (for instance, making all wrappers +6755 ikiwiki:ikiwiki), I think it would help to have "wrapperuser". This could +only actually take effect if building the wrappers as root (not really the best +plan), but ikiwiki could at least warn if wrapperuser does not match the user +the wrapper will end up with. -- cgit v1.2.3 From 05b99e3cfa8c9044d18d5b07aec24fff555f2889 Mon Sep 17 00:00:00 2001 From: David Riebenbauer Date: Tue, 2 Feb 2010 13:54:51 +0100 Subject: Document git branch for automatically creating tag pages. --- ...o-create_tag_pages_according_to_a_template.mdwn | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index f1d33114f..95710ced0 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -123,3 +123,40 @@ On the second extra pass, it doesn't notice that it has to update the "?"-link. } is not satisfied for the newly created tag page. I shall put debug msgs into Render.pm to find out better how it works. --Ivan Z. + +--- + +I've made another attempt at fixiing this + +The current progress can be found at my [git repository][gitweb] on branch +`autotag`: + + git://git.liegesta.at/git/ikiwiki + +[gitweb]: http://git.liegesta.at/?p=ikiwiki.git;a=shortlog;h=refs/heads/autotag (gitweb for branch autotag) + +It's not entirely finished yet, but already quite usable. Testing and comments +on code quality, implementation details, as well as other patches would be +appreciated. + +Here's what it does right now: + +* enabled by setting `tag_autocreate=1` in the configuration. +* Tag pages will be created in `tagbase` from the template `autotag.tmpl`. +* Will correctly render all links, and dependencies. Well, AFAIK. +* When a tag page is deleted it will automatically recreated from template. (I +consider this a feature, not a bug) +* Requires a rebuild on first use. +* Adds a function `add_autofile()` to the plugin API, to do all this. + +Todo/Bugs: + +* Will still create a page even if there's a page other than `$tag` under +`tagbase` satisfying the tag link. +* Call from `IkiWiki.pm` to `Render.pm`, which adds a module dependency in the +wrong direction. +* Add files to RCS. +* Unit tests. +* Proper documentation. + +--[[David_Riebenbauer]] -- cgit v1.2.3 From 1febfda911d29a52b4c4aa1bb286f4c9e1862c5c Mon Sep 17 00:00:00 2001 From: David Riebenbauer Date: Tue, 2 Feb 2010 14:50:01 +0100 Subject: also tag 'patch/core', considering that over half of the changes are there --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 95710ced0..8c586d706 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -4,7 +4,7 @@ Tags are mainly specific to the object to which they’re stuck. However, I ofte Also see: and -[[!tag wishlist plugins/tag patch]] +[[!tag wishlist plugins/tag patch patch/core]] I would love to see this as well. -- dato -- cgit v1.2.3 From 6b98269aa310abc121875753ded37042f3a95988 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 2 Feb 2010 13:31:07 -0500 Subject: partial review --- ...o-create_tag_pages_according_to_a_template.mdwn | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 8c586d706..a0e76fd48 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -160,3 +160,35 @@ wrong direction. * Proper documentation. --[[David_Riebenbauer]] + +> Starting review of this. Some of your commits are to very delicate, +> optimised, and security-sensitive ground, so I have to look at them very +> carefully. --[[Joey]] +> +> * In the refactoring in f3abeac919c4736429bd3362af6edf51ede8e7fe, +> you introduced at least 2 bugs, one a possible security hole. +> Now one part of the code tests `if ($file)` and the other +> caller tests `if ($f)`. These two tests both tested `if (! defined $f)` +> before. Notice that the variable needs to be the untainted variable +> for both. Also notice that `if ($f)` fails if `$f` contains `0`, +> which is a very common perl gotcha. +> * Your refactored code changes `-l $_ || -d _` to `-l $file || -d $file`. +> The latter makes one more stat system call; note the use of a +> bare `_` in the first to make perl reuse the stat buffer. +> * (As a matter of style, could you put a space after the commas in your +> perl?) +> +> I'd like to cherry-pick the above commit, once it's in shape, before +> looking at the rest in detail. So just a few other things that stood out. +> +> * Commit 4af4d26582f0c2b915d7102fb4a604b176385748 seems unnecessary. +> `srcfile($file, 1)` already is documented to return undef if the +> file does not exist. (But without the second parameter, it throws +> an error.) +> +> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 adds a line +> that is intented by a space, not a tab. +> +> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 says that auto-added +> files will be recreated if the user deletes them. That seems bad. +> `autoindex` goes to some trouble to not recreate deleted files. -- cgit v1.2.3 From fb6e73b3698089f47ae63d1569225938699d84e1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 8 Feb 2010 13:46:49 -0500 Subject: move to correct location --- doc/todo/http_bl_support.mdwn | 61 +++++++++++++++++++++++++++++++++++++++ doc/wishlist/http_bl_support.mdwn | 61 --------------------------------------- 2 files changed, 61 insertions(+), 61 deletions(-) create mode 100644 doc/todo/http_bl_support.mdwn delete mode 100644 doc/wishlist/http_bl_support.mdwn (limited to 'doc/todo') diff --git a/doc/todo/http_bl_support.mdwn b/doc/todo/http_bl_support.mdwn new file mode 100644 index 000000000..024c770d8 --- /dev/null +++ b/doc/todo/http_bl_support.mdwn @@ -0,0 +1,61 @@ +[Project Honeypot](http://projecthoneypot.org/) has an HTTP:BL API available to subscribed (it's free, accept donations) people/orgs. There's a basic perl package someone wrote, I'm including a copy here. + +[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112) + +
+package Honeypot;
+
+use Socket qw/inet_ntoa/;
+
+my $dns = 'dnsbl.httpbl.org';
+my %types = (
+0	=> 'Search Engine',
+1	=> 'Suspicious',
+2	=> 'Harvester',
+4	=> 'Comment Spammer'
+);
+sub query {
+my $key = shift || die 'You need a key for this, you get one at http://www.projecthoneypot.org';
+my $ip = shift || do {
+warn 'no IP for request in Honeypot::query().';
+return;
+};
+
+my @parts = reverse split /\./, $ip;
+my $lookup_name = join'.', $key, @parts, $dns;
+
+my $answer = gethostbyname ($lookup_name);
+return unless $answer;
+$answer = inet_ntoa($answer);
+my(undef, $days, $threat, $type) = split /\./, $answer;
+my @types;
+while(my($bit, $typename) = each %types) {
+push @types, $typename if $bit & $type;
+}
+return {
+days => $days,
+threat => $threat,
+type => join ',', @types
+};
+
+}
+1;
+
+ +From the page: + +> The usage is simple: + +> use Honeypot; +> my $key = 'XXXXXXX'; # your key +> my $ip = '....'; the IP you want to check +> my $q = Honeypot::query($key, $ip); + +> use Data::Dumper; +> print Dumper $q; + +Any chance of having this as a plugin? + +I could give it a go, too. Would be fun to try my hand at Perl. --[[simonraven]] + +[[!tag wishlist]] diff --git a/doc/wishlist/http_bl_support.mdwn b/doc/wishlist/http_bl_support.mdwn deleted file mode 100644 index 024c770d8..000000000 --- a/doc/wishlist/http_bl_support.mdwn +++ /dev/null @@ -1,61 +0,0 @@ -[Project Honeypot](http://projecthoneypot.org/) has an HTTP:BL API available to subscribed (it's free, accept donations) people/orgs. There's a basic perl package someone wrote, I'm including a copy here. - -[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112) - -
-package Honeypot;
-
-use Socket qw/inet_ntoa/;
-
-my $dns = 'dnsbl.httpbl.org';
-my %types = (
-0	=> 'Search Engine',
-1	=> 'Suspicious',
-2	=> 'Harvester',
-4	=> 'Comment Spammer'
-);
-sub query {
-my $key = shift || die 'You need a key for this, you get one at http://www.projecthoneypot.org';
-my $ip = shift || do {
-warn 'no IP for request in Honeypot::query().';
-return;
-};
-
-my @parts = reverse split /\./, $ip;
-my $lookup_name = join'.', $key, @parts, $dns;
-
-my $answer = gethostbyname ($lookup_name);
-return unless $answer;
-$answer = inet_ntoa($answer);
-my(undef, $days, $threat, $type) = split /\./, $answer;
-my @types;
-while(my($bit, $typename) = each %types) {
-push @types, $typename if $bit & $type;
-}
-return {
-days => $days,
-threat => $threat,
-type => join ',', @types
-};
-
-}
-1;
-
- -From the page: - -> The usage is simple: - -> use Honeypot; -> my $key = 'XXXXXXX'; # your key -> my $ip = '....'; the IP you want to check -> my $q = Honeypot::query($key, $ip); - -> use Data::Dumper; -> print Dumper $q; - -Any chance of having this as a plugin? - -I could give it a go, too. Would be fun to try my hand at Perl. --[[simonraven]] - -[[!tag wishlist]] -- cgit v1.2.3 From 4ce14aa621be4c6b8551555395b80b68fbcc1ffe Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 8 Feb 2010 13:49:34 -0500 Subject: nte blogspam --- doc/todo/http_bl_support.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/http_bl_support.mdwn b/doc/todo/http_bl_support.mdwn index 024c770d8..f7a46ee6c 100644 --- a/doc/todo/http_bl_support.mdwn +++ b/doc/todo/http_bl_support.mdwn @@ -2,6 +2,12 @@ [from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112) +> The [[plugins/blogspam]] service already checks urls against +> the surbl, and has its own IP blacklist. The best way to +> support the HTTP:BL may be to add a plugin +> [there](http://blogspam.repository.steve.org.uk/file/cc858e497cae/server/plugins/). +> --[[Joey]] + 
 package Honeypot;
 
-- 
cgit v1.2.3


From 172dfa9f64b5a248042af7c4b741fdd4c71813ec Mon Sep 17 00:00:00 2001
From: "http://seeitcoming.myopenid.com/"
 
Date: Sat, 13 Feb 2010 15:16:09 +0000
Subject: Added information about python implementation for reference

---
 doc/todo/abbreviation.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/abbreviation.mdwn b/doc/todo/abbreviation.mdwn
index d24166710..f2880091c 100644
--- a/doc/todo/abbreviation.mdwn
+++ b/doc/todo/abbreviation.mdwn
@@ -2,4 +2,6 @@ We might want some kind of abbreviation and acronym plugin. --[[JoshTriplett]]
 
  * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page).  -- [[AdamShand]]
 
+ * The python-markdown-extras package has support for [abbreviations](http://www.freewisdom.org/projects/python-markdown/Abbreviations), with the syntax that you just use the abbreviation in text (e.g. HTML) and then define the abbreviations at the end (like "footnote-style" links). For consistency, it might be good to use the same syntax, which apparently derives from [PHP-markdown-extra](http://michelf.com/projects/php-markdown/extra/#abbr).
+
 [[wishlist]]
-- 
cgit v1.2.3


From a38418a8a3652bad60c83a0dd7502f7afb991512 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Feb 2010 14:07:56 -0500
Subject: close

---
 doc/todo/openid_user_filtering.mdwn | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/openid_user_filtering.mdwn b/doc/todo/openid_user_filtering.mdwn
index 8b2d0082e..7f8b2a55e 100644
--- a/doc/todo/openid_user_filtering.mdwn
+++ b/doc/todo/openid_user_filtering.mdwn
@@ -7,3 +7,7 @@ So I suggest an ikiwiki configuration like:
      users => ["*.webvm.net"],
 
 Would only allow edits from openIDs of that form.
+
+> This kind of thing can be [[done]] now: --[[Joey]] 
+> 
+>	locked_pages => "user(http://*.webvm.net/)"
-- 
cgit v1.2.3


From 6fc25c8df79c4ce9afde256be5d377ee82562c31 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Feb 2010 14:13:30 -0500
Subject: clarify

---
 doc/todo/openid_user_filtering.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/openid_user_filtering.mdwn b/doc/todo/openid_user_filtering.mdwn
index 7f8b2a55e..6a318c4c0 100644
--- a/doc/todo/openid_user_filtering.mdwn
+++ b/doc/todo/openid_user_filtering.mdwn
@@ -10,4 +10,4 @@ Would only allow edits from openIDs of that form.
 
 > This kind of thing can be [[done]] now: --[[Joey]] 
 > 
->	locked_pages => "user(http://*.webvm.net/)"
+>	locked_pages => "* and !user(http://*.webvm.net/)"
-- 
cgit v1.2.3


From ce8bb219586332032110da8835fde8dd5f0ed91f Mon Sep 17 00:00:00 2001
From: nil 
Date: Tue, 16 Feb 2010 18:42:11 +0000
Subject: whishlist

---
 doc/todo/cdate_and_mdate_available_for_templates.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 doc/todo/cdate_and_mdate_available_for_templates.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/cdate_and_mdate_available_for_templates.mdwn b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
new file mode 100644
index 000000000..29c36b9f7
--- /dev/null
+++ b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
@@ -0,0 +1,15 @@
+[[!tag whishlist]]
+
+`CDATE_3339`, `CDATE_822`, `MDATE_3339` and `MDATE_822` template variables would be useful for evey page, at least for my templates with Dublin Core metadata.
+
+I tried to pick the relevant lines of the [[inline|plugins/inline]] plugin and hack it into a custom plugin, but it failed miserably because of my obvious lack of perl litteracy...
+
+Anyway, I'm sure this is almost nothing...
+
+* `sub date_822 ($) {}`
+* `sub date_3339 ($) {}`
+* and something like `$template->param('cdate_822' => date_822($IkiWiki::pagectime{$page}));`
+
+Anyone can fill the missing lines?
+
+-- [[nil]]
-- 
cgit v1.2.3


From d4bc6e25e43f0cb2f12d7e9d954cbfc227c1686d Mon Sep 17 00:00:00 2001
From: nil 
Date: Tue, 16 Feb 2010 18:43:10 +0000
Subject: typo

---
 doc/todo/cdate_and_mdate_available_for_templates.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/cdate_and_mdate_available_for_templates.mdwn b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
index 29c36b9f7..70d8fc8c9 100644
--- a/doc/todo/cdate_and_mdate_available_for_templates.mdwn
+++ b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
@@ -1,4 +1,4 @@
-[[!tag whishlist]]
+[[!tag wishlist]]
 
 `CDATE_3339`, `CDATE_822`, `MDATE_3339` and `MDATE_822` template variables would be useful for evey page, at least for my templates with Dublin Core metadata.
 
-- 
cgit v1.2.3


From 34d6403a4b12c9578e7b0ea3fb765e1c5e72520f Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/" 
Date: Wed, 17 Feb 2010 11:54:26 +0000
Subject: new feature request: identifying trivial edits

---
 ...trivial__44___identify__47__filter_on_trivial_changes.mdwn | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn b/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
new file mode 100644
index 000000000..2b2b0242e
--- /dev/null
+++ b/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
@@ -0,0 +1,11 @@
+One feature of mediawiki which I quite like is the ability to mark a change as 'minor', or 'trivial'. This can then be used to filter the 'recentchanges' page, to only show substantial edits.
+
+The utility of this depends entirely on whether the editors use it properly.
+
+I currently use an inline on the front page of my personal homepage to show the most recent pages (by creation date) within a subsection of my site (a blog). Blog posts are rarely modified much after they are 'created' (or published - I bodge the creation time via meta when I publish a post. It might sit in draft form indefinitely), so this effectively shows only non-trivial changes.
+
+I would like to have a short list of the most recent modifications to the site on the front page. I therefore want to sort by modified time rather than creation time, but exclude edits that I self-identify as minor. I also only want to take a short number of items, the top 5, and display only their titles (which may be derived from filename, or set via meta again).
+
+I'm still thinking through how this might be achieved in an ikiwiki-suitable fashion, but I think I need a scheme to identify certain edits as trivial. This would have to work via web edits (easier: could add a check box to the edit form) and plain changes in the VCS (harder: scan for keywords in a commit message? in a VCS-agnostic fashion?)
+
+[[!tag wishlist]]
-- 
cgit v1.2.3


From d1137697a80ca5e90bfc9d1c1f00b455871b99c5 Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/" 
Date: Fri, 19 Feb 2010 14:00:52 +0000
Subject: fix 'done' link

---
 doc/todo/conflict_free_comment_merges.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn
index 2cef0ee8c..e84400c17 100644
--- a/doc/todo/conflict_free_comment_merges.mdwn
+++ b/doc/todo/conflict_free_comment_merges.mdwn
@@ -20,4 +20,4 @@ What do you think [[smcv]]? --[[Joey]]
 > are quite low since it modifies the input text and adds a date stamp to
 > it.
 >
-> Anyway, I think it's good, [[[done]] --[[Joey]] 
+> Anyway, I think it's good, [[done]] --[[Joey]] 
-- 
cgit v1.2.3


From 59017c6ae19f661761d0ae3f143fbda643ca1e8d Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/" 
Date: Fri, 19 Feb 2010 14:02:29 +0000
Subject: prevent keyboard mashing

---
 doc/todo/double-click_protection_for_form_buttons.mdwn | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 doc/todo/double-click_protection_for_form_buttons.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/double-click_protection_for_form_buttons.mdwn b/doc/todo/double-click_protection_for_form_buttons.mdwn
new file mode 100644
index 000000000..4c0d95bd6
--- /dev/null
+++ b/doc/todo/double-click_protection_for_form_buttons.mdwn
@@ -0,0 +1 @@
+A small piece of JS to prevent double-submitting forms would be quite nice. I seem to have developed a habit of doing this and having to resolve a merge conflict for two initial commits. -- [[Jon]]
-- 
cgit v1.2.3


From ef537ed3553c590abbc302a97299ae5082471fea Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 19 Feb 2010 13:38:37 -0500
Subject: response

---
 doc/todo/double-click_protection_for_form_buttons.mdwn | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/double-click_protection_for_form_buttons.mdwn b/doc/todo/double-click_protection_for_form_buttons.mdwn
index 4c0d95bd6..501be4498 100644
--- a/doc/todo/double-click_protection_for_form_buttons.mdwn
+++ b/doc/todo/double-click_protection_for_form_buttons.mdwn
@@ -1 +1,5 @@
 A small piece of JS to prevent double-submitting forms would be quite nice. I seem to have developed a habit of doing this and having to resolve a merge conflict for two initial commits. -- [[Jon]]
+
+> By the time you see that merge conflict, the first commit has
+> already successfully happened, so you can just hit cancel
+> and throw away the second submit. --[[Joey]] 
-- 
cgit v1.2.3


From f0b0bb5894e056eeb67c50cf096f950f1fbc718a Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 19 Feb 2010 14:27:42 -0500
Subject: ctime idea

---
 doc/todo/auto_getctime_on_fresh_build.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 doc/todo/auto_getctime_on_fresh_build.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/auto_getctime_on_fresh_build.mdwn b/doc/todo/auto_getctime_on_fresh_build.mdwn
new file mode 100644
index 000000000..ea95fb8c9
--- /dev/null
+++ b/doc/todo/auto_getctime_on_fresh_build.mdwn
@@ -0,0 +1,9 @@
+[[!tag wishlist]]
+
+It might be a good idea to enable --getctime when `.ikiwiki` does not
+exist. This way a new checkout of a `srcdir` would automatically get
+ctimes right. (Running --getctime whenever a rebuild is done would be too
+slow.) --[[Joey]] 
+
+Could this be too annoying in some cases, eg, checking out a large wiki
+that needs to get set up right away? --[[Joey]] 
-- 
cgit v1.2.3


From 100636afa253c9808654b5db45feabc4ca1c6f8c Mon Sep 17 00:00:00 2001
From: "http://privat.myopenid.com/" 
Date: Sat, 27 Feb 2010 15:12:39 +0000
Subject: patch for multiple sidebars

---
 ..._up_sidebar_to_allow_for_multiple_sidebars.mdwn | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index fb942a495..02b83244e 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -13,5 +13,57 @@ those contents instead.
 
 > In mine I just copied sidebar out and made some extra "sidebars", but they go elsewhere. Ugly hack, but it works. --[[simonraven]]
 
+>> Here a simple [[patch]] for multiple sidebars. Not too fancy but better than having multiple copies of the sidebar plugin. --[[jeanprivat]]
+
+
+--- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
++++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
+@@ -19,12 +19,20 @@
+ 			safe => 1,
+ 			rebuild => 1,
+ 		},
++		active_sidebars => {
++			type => "string",
++			example => qw(sidebar banner footer),
++			description => "Which sidebars must be activated and processed.",
++			safe => 1,
++			rebuild => 1
++		},
+ }
+ 
+-sub sidebar_content ($) {
++sub sidebar_content ($$) {
+ 	my $page=shift;
++	my $sidebar=shift;
+ 	
+-	my $sidebar_page=bestlink($page, "sidebar") || return;
++	my $sidebar_page=bestlink($page, $sidebar) || return;
+ 	my $sidebar_file=$pagesources{$sidebar_page} || return;
+ 	my $sidebar_type=pagetype($sidebar_file);
+ 	
+@@ -49,11 +57,17 @@
+ 
+ 	my $page=$params{page};
+ 	my $template=$params{template};
+-	
+-	if ($template->query(name => "sidebar")) {
+-		my $content=sidebar_content($page);
+-		if (defined $content && length $content) {
+-		        $template->param(sidebar => $content);
++
++	my @sidebars;
++	if (defined $config{active_sidebars} && length $config{active_sidebars}) { @sidebars = @{$config{active_sidebars}}; }
++	else { @sidebars = qw(sidebar); }
++
++	foreach my $sidebar (@sidebars) {
++		if ($template->query(name => $sidebar)) {
++			my $content=sidebar_content($page, $sidebar);
++			if (defined $content && length $content) {
++				$template->param($sidebar => $content);
++			}
+ 		}
+ 	}
+ }
+

 
 [[!tag wishlist]]
-- 
cgit v1.2.3


From b849c63ce337f988fcbb08b39d197583e6fa6012 Mon Sep 17 00:00:00 2001
From: "http://dmarti.myopenid.com/" 
Date: Thu, 4 Mar 2010 00:15:00 +0000
Subject:

---
 doc/todo/salmon_protocol_for_comment_sharing.mdwn | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 doc/todo/salmon_protocol_for_comment_sharing.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/salmon_protocol_for_comment_sharing.mdwn b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
new file mode 100644
index 000000000..f4fa0c535
--- /dev/null
+++ b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
@@ -0,0 +1,3 @@
+The Salmon protocol provides for aggregating comments across sites.  If a site that syndicates a feed receives a comment on an item in that feed, it can re-post the comment to the original source.
+
+[[!tag wishlist]]
-- 
cgit v1.2.3


From d72603534e677a4fbc0547ca3e5c9273d0d502ca Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 3 Mar 2010 19:48:23 -0500
Subject: comments

---
 doc/todo/salmon_protocol_for_comment_sharing.mdwn | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/salmon_protocol_for_comment_sharing.mdwn b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
index f4fa0c535..1e56b0a8b 100644
--- a/doc/todo/salmon_protocol_for_comment_sharing.mdwn
+++ b/doc/todo/salmon_protocol_for_comment_sharing.mdwn
@@ -1,3 +1,21 @@
-The Salmon protocol provides for aggregating comments across sites.  If a site that syndicates a feed receives a comment on an item in that feed, it can re-post the comment to the original source.
+The Salmon protocol
+provides for aggregating comments across sites.  If a site that syndicates
+a feed receives a comment on an item in that feed, it can re-post the
+comment to the original source.
+
+> Ikiwiki does not allow comments to be posted on items it aggregates.
+> So salmon protocol support would only need to handle the comment
+> receiving side of the protocol.
+> 
+> The current draft protocol document confuses me when it starts talking
+> about using OAuth in the abuse prevention section, since their example
+> does not show use of OAuth, and it's not at all clear to me where the
+> OAuth relationship between aggregator and original source is supposed
+> to come from.
+> 
+> Their security model, which goes on to include Webfinger,
+> thirdparty validation services, XRD, and Magic Signatures, looks sorta
+> like they kept throwing technology,  at it, hoping something will stick. :-P
+> --[[Joey]]
 
 [[!tag wishlist]]
-- 
cgit v1.2.3


From 58a6847cfb445dbb87716e4064f8151cc44a233a Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/" 
Date: Fri, 12 Mar 2010 17:51:17 +0000
Subject: Note that, actually, SVG could be embedded into an Ikiwiki page,
 albeit in a somewhat crude manner.

---
 doc/todo/svg.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index 89b183db6..2099751e3 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -57,3 +57,11 @@ in the trunk if other people think it's useful.
 
 [htmlscrubber.pm]:http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blob;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hb=fe333c8e5b4a5f374a059596ee698dacd755182d
 [diff]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073
+
+* * *
+
+Actually, there's a way to embed SVG into MarkDown sources using the [data: URI scheme][rfc2397], [like this](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8c3ZnIHdpZHRoPSIxOTIiIGhlaWdodD0iMTkyIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KIDwhLS0gQ3JlYXRlZCB3aXRoIFNWRy1lZGl0IC0gaHR0cDovL3N2Zy1lZGl0Lmdvb2dsZWNvZGUuY29tLyAtLT4KIDx0aXRsZT5IZWxsbywgd29ybGQhPC90aXRsZT4KIDxnPgogIDx0aXRsZT5MYXllciAxPC90aXRsZT4KICA8ZyB0cmFuc2Zvcm09InJvdGF0ZSgtNDUsIDk3LjY3MTksIDk3LjY2OCkiIGlkPSJzdmdfNyI+CiAgIDxyZWN0IHN0cm9rZS13aWR0aD0iNSIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjRkYwMDAwIiBpZD0ic3ZnXzUiIGhlaWdodD0iNTYuMDAwMDAzIiB3aWR0aD0iMTc1IiB5PSI2OS42Njc5NjkiIHg9IjEwLjE3MTg3NSIvPgogICA8dGV4dCB4bWw6c3BhY2U9InByZXNlcnZlIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LWZhbWlseT0ic2VyaWYiIGZvbnQtc2l6ZT0iMjQiIHN0cm9rZS13aWR0aD0iMCIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjZmZmZjAwIiBpZD0ic3ZnXzYiIHk9IjEwNS42NjgiIHg9Ijk5LjY3MTkiPkhlbGxvLCB3b3JsZCE8L3RleHQ+CiAgPC9nPgogPC9nPgo8L3N2Zz4=).
+Of course, this way to display an image one needs to click a link, but it may be considered a feature.
+— [[Ivan_Shmakov]], 2010-03-12Z.
+
+[rfc2397]: http://tools.ietf.org/html/rfc2397
-- 
cgit v1.2.3


From 844bb8134b5ff6e3d73dc3c8b91ed516fa618c41 Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/" 
Date: Fri, 12 Mar 2010 18:33:10 +0000
Subject: Added an  wishlist item.

---
 ...er_control_over___60__object___47____62__s.mdwn | 41 ++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 doc/todo/finer_control_over___60__object___47____62__s.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
new file mode 100644
index 000000000..714f5ae50
--- /dev/null
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -0,0 +1,41 @@
+IIUC, the current version of [HTML::Scrubber][] allows for the `object` tags to be either enabled or disabled entirely.  However, while `object` can be used to add *code* (which is indeed a potential security hole) to a document, reading [Objects, Images, and Applets in HTML documents][objects-html] reveals that the “dangerous” are not all the `object`s, but rather those having the following attributes:
+
+    classid     %URI;          #IMPLIED  -- identifies an implementation --
+    codebase    %URI;          #IMPLIED  -- base URI for classid, data, archive--
+    codetype    %ContentType;  #IMPLIED  -- content type for code --
+    archive     CDATA          #IMPLIED  -- space-separated list of URIs --
+
+It seems that the following attributes are, OTOH, safe:
+
+    declare     (declare)      #IMPLIED  -- declare but don't instantiate flag --
+    data        %URI;          #IMPLIED  -- reference to object's data --
+    type        %ContentType;  #IMPLIED  -- content type for data --
+    standby     %Text;         #IMPLIED  -- message to show while loading --
+    height      %Length;       #IMPLIED  -- override height --
+    width       %Length;       #IMPLIED  -- override width --
+    usemap      %URI;          #IMPLIED  -- use client-side image map --
+    name        CDATA          #IMPLIED  -- submit as part of form --
+    tabindex    NUMBER         #IMPLIED  -- position in tabbing order --
+
+Should the former attributes be *scrubbed* while the latter left intact, the use of the `object` tag would seemingly become safe.
+
+Note also that allowing `object` (either restricted in such a way or not) automatically solves the [[/todo/svg]] issue.
+
+For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by the `data` and `usemap` attributes) to, say, relative and `data:` (as per [RFC 2397][]) ones as well, though it requires some more consideration.
+
+— [[Ivan_Shmakov]], 2010-03-12Z.
+
+[[wishlist]]
+
+## See also
+
+* [Objects, Images, and Applets in HTML documents][objects-html]
+* [[plugins/htmlscrubber|/plugins/htmlscrubber]]
+* [[todo/svg|/todo/svg]]
+* [RFC 2397: The “data” URL scheme. L. Masinter. August 1998.][RFC 2397]
+* [Uniform Resource Identifier — the free encyclopedia][URI]
+
+[HTML::Scrubber]: http://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm
+[objects-html]: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
+[RFC 2397]: http://tools.ietf.org/html/rfc2397
+[URI]: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
-- 
cgit v1.2.3


From 556181d417e3461de56c43445ec9b2b0aefc7141 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 12 Mar 2010 14:29:54 -0500
Subject: data:image/svg is a security hole as javascript can presumably be
 inserted

---
 doc/todo/svg.mdwn | 10 ++++++++++
 1 file changed, 10 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn
index 2099751e3..274ebf3e3 100644
--- a/doc/todo/svg.mdwn
+++ b/doc/todo/svg.mdwn
@@ -58,6 +58,8 @@ in the trunk if other people think it's useful.
 [htmlscrubber.pm]:http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blob;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hb=fe333c8e5b4a5f374a059596ee698dacd755182d
 [diff]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073
 
+> Unfortuantly these links are broken. --[[Joey]]
+
 * * *
 
 Actually, there's a way to embed SVG into MarkDown sources using the [data: URI scheme][rfc2397], [like this](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8c3ZnIHdpZHRoPSIxOTIiIGhlaWdodD0iMTkyIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KIDwhLS0gQ3JlYXRlZCB3aXRoIFNWRy1lZGl0IC0gaHR0cDovL3N2Zy1lZGl0Lmdvb2dsZWNvZGUuY29tLyAtLT4KIDx0aXRsZT5IZWxsbywgd29ybGQhPC90aXRsZT4KIDxnPgogIDx0aXRsZT5MYXllciAxPC90aXRsZT4KICA8ZyB0cmFuc2Zvcm09InJvdGF0ZSgtNDUsIDk3LjY3MTksIDk3LjY2OCkiIGlkPSJzdmdfNyI+CiAgIDxyZWN0IHN0cm9rZS13aWR0aD0iNSIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjRkYwMDAwIiBpZD0ic3ZnXzUiIGhlaWdodD0iNTYuMDAwMDAzIiB3aWR0aD0iMTc1IiB5PSI2OS42Njc5NjkiIHg9IjEwLjE3MTg3NSIvPgogICA8dGV4dCB4bWw6c3BhY2U9InByZXNlcnZlIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LWZhbWlseT0ic2VyaWYiIGZvbnQtc2l6ZT0iMjQiIHN0cm9rZS13aWR0aD0iMCIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjZmZmZjAwIiBpZD0ic3ZnXzYiIHk9IjEwNS42NjgiIHg9Ijk5LjY3MTkiPkhlbGxvLCB3b3JsZCE8L3RleHQ+CiAgPC9nPgogPC9nPgo8L3N2Zz4=).
@@ -65,3 +67,11 @@ Of course, this way to display an image one needs to click a link, but it may be
 — [[Ivan_Shmakov]], 2010-03-12Z.
 
 [rfc2397]: http://tools.ietf.org/html/rfc2397
+
+> You can do the same with img src actually.
+> 
+> If svg markup allows unsafe elements (ie, javascript),
+> which it appears to, 
+> then this is a security hole, and the htmlscrubber
+> needs to lock it down more. Darn, now I have to spend my afternoon making
+> security releases! --[[Joey]] 
-- 
cgit v1.2.3


From 4711076fad54ff8152f03a7e4bdd4b5c2df1916c Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 12 Mar 2010 15:00:39 -0500
Subject: clarify

---
 doc/todo/mercurial.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn
index e71c8106a..de1f148e5 100644
--- a/doc/todo/mercurial.mdwn
+++ b/doc/todo/mercurial.mdwn
@@ -119,3 +119,11 @@ I have a few notes on mercurial usage after trying it out for a while:
 >> I think the ideal solution would be to build `$destdir/recentchanges/*` directly from the output of `hg log`. --[[buo]]
 
 >>>> That would be 100 times as slow, so I chose not to do that. --[[Joey]]
+
+>>>> Since this is confusing people, allow me to clarify: Ikiwiki's
+>>>> recentchanges generation pulls log information directly out of the VCS as
+>>>> needed. It caches it in recentchanges/* in the `scrdir`. These cache
+>>>> files need not be preserved, should never be checked into VCS, and if
+>>>> you want to you can configure your VCSignore file to ignore them,
+>>>> just as you can configure it to ignore the `.ikiwiki` directory in the
+>>>> `scrdir`. --[[Joey]] 
-- 
cgit v1.2.3


From 08485ec444cf81015e39c52e6ce8e7b933a036f6 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 12 Mar 2010 15:40:47 -0500
Subject: response

---
 doc/todo/finer_control_over___60__object___47____62__s.mdwn | 7 +++++++
 1 file changed, 7 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index 714f5ae50..ac4b55568 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -27,6 +27,13 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
 
 [[wishlist]]
 
+> SVG can contain embedded javascript. The spec that you link to contains
+> examples of objects that contain python scripts, Microsoft OLE 
+> objects, and Java. And then there's flash. I don't think ikiwiki can
+> assume all the possibilities are handled securely, particularly WRT XSS
+> attacks.
+> --[[Joey]]
+
 ## See also
 
 * [Objects, Images, and Applets in HTML documents][objects-html]
-- 
cgit v1.2.3


From b5e27e60ba38365f3e252df80c2a22503f00eb06 Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/" 
Date: Fri, 12 Mar 2010 21:24:53 +0000
Subject: Note that  still may be allowed, although in a form not
 suitable for, say, SVG inclusion.

---
 ...er_control_over___60__object___47____62__s.mdwn | 34 +++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index ac4b55568..c37d052db 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -27,13 +27,43 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
 
 [[wishlist]]
 
-> SVG can contain embedded javascript. The spec that you link to contains
+> SVG can contain embedded javascript.
+
+>> Indeed.
+
+>> So, a more general tool (`XML::Scrubber`?) will be necessary to
+>> refine both [XHTML][] and SVG.
+
+>> … And to leave [MathML][] as is (?.)
+
+>> — [[Ivan_Shmakov]], 2010-03-12Z.
+
+> The spec that you link to contains
 > examples of objects that contain python scripts, Microsoft OLE 
 > objects, and Java. And then there's flash. I don't think ikiwiki can
 > assume all the possibilities are handled securely, particularly WRT XSS
 > attacks.
 > --[[Joey]]
 
+>> I've scanned over all the `object` examples in the specification and
+>> all of those that hold references to code (as opposed to data) have a
+>> distinguishing `classid` attribute.
+
+>> While I won't assert that it's impossible to reference code with
+>> `data` (and, thanks to `text/xhtml+xml` and `image/svg+xml`, it is
+>> *not* impossible), throwing away any of the “insecure”
+>> attributes listed above together with limiting the possible URI's
+>> (i. e., only *local* and certain `data:` ones for `data` and
+>> `usemap`) should make `object` almost as harmless as, say, `img`.
+
+>> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being
+>> restricted in such a way.)
+
+>> Of the remaining issues I could only think of recursive
+>> `object` — the one that references its container document.
+
+>> — [[Ivan_Shmakov]], 2010-03-12Z.
+
 ## See also
 
 * [Objects, Images, and Applets in HTML documents][objects-html]
@@ -43,6 +73,8 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
 * [Uniform Resource Identifier — the free encyclopedia][URI]
 
 [HTML::Scrubber]: http://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm
+[MathML]: http://en.wikipedia.org/wiki/MathML
 [objects-html]: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html
 [RFC 2397]: http://tools.ietf.org/html/rfc2397
 [URI]: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
+[XHTML]: http://en.wikipedia.org/wiki/XHTML
-- 
cgit v1.2.3


From 29ca20b87c565412fa603127425ccdaf4ca58b79 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 12 Mar 2010 16:50:04 -0500
Subject: response

---
 doc/todo/finer_control_over___60__object___47____62__s.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index c37d052db..0ca949954 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -56,6 +56,11 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
 >> (i. e., only *local* and certain `data:` ones for `data` and
 >> `usemap`) should make `object` almost as harmless as, say, `img`.
 
+>>> But with local data, one could not embed youtube videos, which surely
+>>> is the most obvious use case? Note that youtube embedding uses an
+>>> object element with no classid. The swf file is provided via an
+>>> enclosed param element. --[[Joey]]
+
 >> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being
 >> restricted in such a way.)
 
-- 
cgit v1.2.3


From c26b6c3be864aaf49fe0b0fc15c0af59323b7dde Mon Sep 17 00:00:00 2001
From: "http://oneingray.myopenid.com/" 
Date: Fri, 12 Mar 2010 22:12:41 +0000
Subject: Note the use of  on YouTube.

---
 .../finer_control_over___60__object___47____62__s.mdwn    | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
index 0ca949954..50c4d43bf 100644
--- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn
+++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn
@@ -57,10 +57,23 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by
 >> `usemap`) should make `object` almost as harmless as, say, `img`.
 
 >>> But with local data, one could not embed youtube videos, which surely
->>> is the most obvious use case? Note that youtube embedding uses an
+>>> is the most obvious use case?
+
+>>>> Allowing a “remote” object to render on one's page is a
+     security issue by itself.
+     Though, of course, having an explicit whitelist of URI's may make
+     this issue more tolerable.
+     — [[Ivan_Shmakov]], 2010-03-12Z.
+
+>>> Note that youtube embedding uses an
 >>> object element with no classid. The swf file is provided via an
 >>> enclosed param element. --[[Joey]]
 
+>>>> I've just checked a random video on YouTube and I see that the
+     `.swf` file is provided via an enclosed `embed` element.  Whether
+     to allow those or not is a different issue.
+     — [[Ivan_Shmakov]], 2010-03-12Z.
+
 >> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being
 >> restricted in such a way.)
 
-- 
cgit v1.2.3


From e8f6c06ca81e4ebd8d244e3863d21517d87b6620 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 17:29:06 -0500
Subject: update; openid email addresses now available so this is unblocked

---
 doc/todo/avatar.mdwn | 31 ++++++++++---------------------
 1 file changed, 10 insertions(+), 21 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index b8aa2327f..4409e7b14 100644
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -1,35 +1,24 @@
 [[!tag wishlist]]
 
 It would be nice if ikiwiki, particularly [[plugins/comments]]
-supported user avatar icons. I was considering adding a directive for this,
-as designed below.
+supported user avatar icons.
 
-However, there is no *good* service for mapping openids to avatars --
-openavatar has many issues, including not supporting delegated openids, and
-after trying it, I don't trust it to push users toward. 
-Perhaps instead ikiwiki could get the email address from the openid
-provider, though I think the perl openid modules don't support the openid
-2.x feature that allows that.
-
-At the moment, working on this doesn't feel like a good use of my time.
---[[Joey]]
-
-Hmm.. unless is just always used a single provider (gravatar) and hashed
-the openid. Then wavatars could be used to get a unique avatar per openid
-at least. --[[Joey]] 
-
-----
-
-The directive displays a small avatar image for a user. Pass it the
-email address, openid, or wiki username of the user.
+Idea is to add a directive that displays a small avatar image for a user.
+Pass it the email address, openid, or wiki username of the user.
 
 	\[[!avatar user@example.com]]
 	\[[!avatar http://joey.kitenet.net/]]
 	\[[!avatar user]]
 
+These directives can then be hand-inserted onto pages, or more likely,
+included in eg, a comment post via a template. Possibly included in a
+recentchanges page item via that template too?
+
 The avatars are provided by various sites. For email addresses, it uses a
 [gravatar](http://gravatar.com/). For openid,
-[openavatar](http://www.openvatar.com/) is used. For a wiki username, the
+[openavatar](http://www.openvatar.com/) could used, but I am not very happy
+with it; probably better to just get the email via SREG (as is done now for
+openid), and use that. For a wiki username, the
 user's email address is looked up and the gravatar for that user is
 displayed. (Of course, the user has to have filled in their email address
 on their Preferences page for that to work.)
-- 
cgit v1.2.3


From e2c9b425415a00012b2c579c40c369da4ac7c98b Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 17:46:28 -0500
Subject: thoughts

---
 doc/todo/Separate_OpenIDs_and_usernames.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 2cd52e8c4..ae427d540 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -6,6 +6,25 @@ I see this being implemented in one of two possible ways. The easiest seems like
 
 A slightly more complex next step would be to request sreg from the provider and, if provided, automatically set the identity's username and email address from the provided persona. If username login to accounts with blank passwords is disabled, then you have the best of both worlds. Passwordless signin, human-friendly attribution, automatic setting of preferences.
 
+> Given that openids are a global user identifier, that can look as pretty
+> as the user cares to make it look via delegation, I am not a fan of 
+> having a site-local identifier that layered on top of that. Perhaps
+> partly because every site that I have seen that does that has openid
+> implemented as a badly-done wart on the side of their regular login
+> system.
+> 
+> Openid Simple Registration is now used to populate the userdb with the
+> email address for openid users.
+> 
+> I am considering displaying the userid or fullname, if available,
+> instead of the munged openid url in recentchanges. It would be nice
+> for those nasty [[google_openids|forum/google_openid_broken?]]. But,
+> I first have to find a way to encode the name in the VCS commit log,
+> while still keeping the openid of the committer in there too.
+> Perhaps something like this (for git): --[[Joey]] 
+> 
+>	Author: Joey Hess 
+
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 
 [[!tag wishlist]]
-- 
cgit v1.2.3


From 4f6c544fa8e7dd21450952f0a9fc3918ee600705 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 19:12:52 -0500
Subject: munge to avoid markdown eating email addresses

---
 doc/todo/git_attribution/discussion.mdwn | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/git_attribution/discussion.mdwn b/doc/todo/git_attribution/discussion.mdwn
index dfb490bc2..6905d9b4b 100644
--- a/doc/todo/git_attribution/discussion.mdwn
+++ b/doc/todo/git_attribution/discussion.mdwn
@@ -72,7 +72,7 @@ no determination of uniqueness)
 > GIT_AUTHOR_EMAIL can also be set.
 > 
 > There is one thing yet to be solved, and that is how to tell the
-> difference between a web commit by 'Joey Hess ',
+> difference between a web commit by 'Joey Hess ',
 > and a git commit by the same. I think we do want to differentiate these,
 > and the best way to do it seems to be to add a line to the end of the
 > commit message. Something like: "\n\nWeb-commit: true"
@@ -94,5 +94,5 @@ no determination of uniqueness)
 > * github pushes to twitter ;-)
 > 
 > So while I tried that way at first, I'm now leaning toward encoding the
-> username in the email address. Like "user ", or
-> "joey ".
+> username in the email address. Like "user ", or
+> "joey ".
-- 
cgit v1.2.3


From 8f4f81cdfdcb68be5efb385dc07e4a0a04352a9d Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 19:24:51 -0500
Subject: wrinkles

---
 doc/todo/Separate_OpenIDs_and_usernames.mdwn |  9 ++++++---
 doc/todo/avatar.mdwn                         | 14 ++++++++++----
 2 files changed, 16 insertions(+), 7 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index ae427d540..3fb952f96 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -13,8 +13,9 @@ A slightly more complex next step would be to request sreg from the provider and
 > implemented as a badly-done wart on the side of their regular login
 > system.
 > 
-> Openid Simple Registration is now used to populate the userdb with the
-> email address for openid users.
+> The openid plugin now attempts to get an email and a username, and stores
+> them in the session database for later use (ie, when the user edits a
+> page).
 > 
 > I am considering displaying the userid or fullname, if available,
 > instead of the munged openid url in recentchanges. It would be nice
@@ -23,7 +24,9 @@ A slightly more complex next step would be to request sreg from the provider and
 > while still keeping the openid of the committer in there too.
 > Perhaps something like this (for git): --[[Joey]] 
 > 
->	Author: Joey Hess 
+>	Author: Joey Hess <http://joey.kitenet.net/@web>
+> 
+> 
 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 
diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index 4409e7b14..3a4e64b95 100644
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -15,14 +15,20 @@ included in eg, a comment post via a template. Possibly included in a
 recentchanges page item via that template too?
 
 The avatars are provided by various sites. For email addresses, it uses a
-[gravatar](http://gravatar.com/). For openid,
-[openavatar](http://www.openvatar.com/) could used, but I am not very happy
-with it; probably better to just get the email via SREG (as is done now for
-openid), and use that. For a wiki username, the
+[gravatar](http://gravatar.com/). For a wiki username, the
 user's email address is looked up and the gravatar for that user is
 displayed. (Of course, the user has to have filled in their email address
 on their Preferences page for that to work.)
 
+For openid, openavatar sucked and is now dead. So we need to use an email
+address instead, I guess. Problem is that the email address of a given
+openid is only known when that user is logged in and making a change.
+And we don't want to leak an openid user's email into a page either.
+Hmm. Suppose the gravatar hash could be calculated from the email address
+and embedded instead of the openid?
+
+Or, for openid, could use .
+
 An optional second parameter can be included, containing additional
 options to pass in the 
 [gravatar url](http://en.gravatar.com/site/implement/url).
-- 
cgit v1.2.3


From 702c097ac29f1b208158936a99317ebad3e4116f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 19:40:20 -0500
Subject: update

---
 doc/todo/Separate_OpenIDs_and_usernames.mdwn | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 3fb952f96..7cfe49a5a 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -18,15 +18,25 @@ A slightly more complex next step would be to request sreg from the provider and
 > page).
 > 
 > I am considering displaying the userid or fullname, if available,
-> instead of the munged openid url in recentchanges. It would be nice
-> for those nasty [[google_openids|forum/google_openid_broken?]]. But,
-> I first have to find a way to encode the name in the VCS commit log,
+> instead of the munged openid url in recentchanges and comments.
+> It would be nice for those nasty [[google_openids|forum/google_openid_broken?]].
+> But, I first have to find a way to encode the name in the VCS commit log,
 > while still keeping the openid of the committer in there too.
 > Perhaps something like this (for git): --[[Joey]] 
 > 
 >	Author: Joey Hess <http://joey.kitenet.net/@web>
 > 
+> So, what needs to be done:
 > 
+> * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
+>   instead of just a userid. (For back-compat, if the parameter is 
+>   not an object, it's a userid.) Bump ikiwiki plugin interface version.
+> * Modify all RCS plugins to include the session username somewhere
+>   in the commit, and parse it back out in `rcs_recentchanges`.
+> * Modify recentchanges plugin to display the username instead of the
+>   `openiduser`.
+> * Modify comment plugin to put the session username in the comment
+>   template instead of the `openiduser`.
 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 
-- 
cgit v1.2.3


From fd43e83fcf7bf24493ecfff54111c1c5f1cab573 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 19:56:54 -0500
Subject: update

---
 doc/forum/google_openid_broken__63__.mdwn    | 13 +++++++++++++
 doc/todo/Separate_OpenIDs_and_usernames.mdwn |  7 +++++++
 2 files changed, 20 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn
index 0e41d4ced..4ca5cac93 100644
--- a/doc/forum/google_openid_broken__63__.mdwn
+++ b/doc/forum/google_openid_broken__63__.mdwn
@@ -58,3 +58,16 @@ points to a fairly useless xml document, rather than a web page. --[[Joey]]
 > I've added buttons that submit the two above URLs for logging in with a Google and Yahoo OpenID, respectively, to my locally changed OpenID login plugin.
 
 > Using the Google profile page as the OpenID is really orthogonal to the above. --[[kaol]]
+
+>> Displaying email addresses is not really an option, because ikiwiki
+>> can't leak user email addresses like that. Displaying nicknames or
+>> usernames is, see [[todo/Separate_OpenIDs_and_usernames]].
+>>
+>> It would probably be good if the openid plugin could be configured with
+>> a list of generic openid urls, so it can add quick login buttons using
+>> those urls.
+>>
+>> The ugly google url will still be exposed here and there where
+>> a unique user id is needed. That can be avoided by not using the generic
+>> , but instead your own profile
+>> like . --[[Joey]] 
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 7cfe49a5a..fcdb49f6d 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -26,6 +26,13 @@ A slightly more complex next step would be to request sreg from the provider and
 > 
 >	Author: Joey Hess <http://joey.kitenet.net/@web>
 > 
+> Only problem with the above is that the openid will still be displayed
+> by CIA. Other option is this, which solves that, but at the expense of
+> having to munge the username to fit inside the email address,
+> and generally seems backwards: --[[Joey]] 
+> 
+>	Author: http://joey.kitenet.net/ <Joey_Hess@web>
+> 
 > So, what needs to be done:
 > 
 > * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
-- 
cgit v1.2.3


From 725a1cf0e8d1fbdb7f449b632ee1fa3cb84835c7 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Mar 2010 20:45:44 -0500
Subject: update; bleargh

---
 doc/todo/avatar.mdwn | 50 ++++++++++++++++++++++++++++++++++----------------
 1 file changed, 34 insertions(+), 16 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn
index 3a4e64b95..f0599e4ed 100644
--- a/doc/todo/avatar.mdwn
+++ b/doc/todo/avatar.mdwn
@@ -1,42 +1,60 @@
 [[!tag wishlist]]
 
 It would be nice if ikiwiki, particularly [[plugins/comments]]
-supported user avatar icons.
+(but also, ideally, recentchanges) supported user avatar icons.
 
 Idea is to add a directive that displays a small avatar image for a user.
-Pass it the email address, openid, or wiki username of the user.
+Pass it a user's the email address, openid, username, or the md5 hash
+of their email address:
 
 	\[[!avatar user@example.com]]
 	\[[!avatar http://joey.kitenet.net/]]
 	\[[!avatar user]]
+	\[[!avatar hash]]
 
 These directives can then be hand-inserted onto pages, or more likely,
-included in eg, a comment post via a template. Possibly included in a
-recentchanges page item via that template too?
+included in eg, a comment post via a template.
+
+An optional second parameter can be included, containing additional
+options to pass in the 
+[gravatar url](http://en.gravatar.com/site/implement/url).
+For example, this asks for a smaller gravatar, and if a user does
+not have a gravatar, uses a cute auto-generated "wavatar" avatar.
+
+	\[[!gravatar user@example.com "size=40&default=wavatar"]]
+
+The `gravitar_options` setting in the setup file can be used to
+specify additional options to pass. So for example if you want
+to use wavatars everywhere, set it to "default=wavatar".
 
 The avatars are provided by various sites. For email addresses, it uses a
 [gravatar](http://gravatar.com/). For a wiki username, the
 user's email address is looked up and the gravatar for that user is
 displayed. (Of course, the user has to have filled in their email address
-on their Preferences page for that to work.)
+on their Preferences page for that to work. Also, when the user changes
+their email address in Preferences, the gravatar won't change until the
+wiki is rebuilt.)
 
 For openid, openavatar sucked and is now dead. So we need to use an email
 address instead, I guess. Problem is that the email address of a given
 openid is only known when that user is logged in and making a change.
 And we don't want to leak an openid user's email into a page either.
 Hmm. Suppose the gravatar hash could be calculated from the email address
-and embedded instead of the openid?
+and embedded instead of the openid? That would work for comments,
+but not if the directive were used elsewhere.
 
-Or, for openid, could use .
+Or, for openid, could use . Which
+works fine, but users are not likely to figure out what they need to do to
+get an avatar associated with their openid.
 
-An optional second parameter can be included, containing additional
-options to pass in the 
-[gravatar url](http://en.gravatar.com/site/implement/url).
-For example, this asks for a smaller gravatar, and if a user does
-not have a gravatar, uses a cute auto-generated "wavatar" avatar.
+---
 
-	\[[!gravatar user@example.com "size=40&default=wavatar"]]
+Alternative, not overdesigned approach:
 
-The `gravitar_options` setting in the setup file can be used to
-specify additional options to pass. So for example if you want
-to use wavatars everywhere, set it to "default=wavatar".
+Modify comments plugin to have an option to display avatars.
+
+When posting a comment, fill in the avatarhash field in the template.
+The hash is calculated from the user's email address. If the user's email
+is not known, skip it. 
+
+End. :P
-- 
cgit v1.2.3


From 823ec815d4fc9625d6fa3553ad03e9f2ff737659 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 14 Mar 2010 14:58:13 -0400
Subject: Add a include setting, which can be used to make ikiwiki process wiki
 source files, such as .htaccess, that would normally be skipped for security
 or other reasons. Closes: #447267 (Thanks to Aaron Wilson for the original
 patch.)

---
 IkiWiki.pm                          | 13 +++++++++++++
 debian/changelog                    |  4 ++++
 doc/tips/htaccess_file.mdwn         | 30 ++++++++++++++++++++++++++++++
 doc/todo/enable-htaccess-files.mdwn |  5 +++++
 doc/usage.mdwn                      |  6 ++++++
 ikiwiki.in                          |  3 +++
 6 files changed, 61 insertions(+)
 create mode 100644 doc/tips/htaccess_file.mdwn

(limited to 'doc/todo')

diff --git a/IkiWiki.pm b/IkiWiki.pm
index 251ed8cc8..ee94ce659 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -334,6 +334,15 @@ sub getsetup () {
 		safe => 0, # paranoia
 		rebuild => 0,
 	},
+	include => {
+		type => "string",
+		default => undef,
+		example => '^\.htaccess$',
+		description => "regexp of normally ignored source files to include",
+		advanced => 1,
+		safe => 0, # regexp
+		rebuild => 1,
+	},
 	exclude => {
 		type => "string",
 		default => undef,
@@ -1820,6 +1829,10 @@ sub file_pruned ($;$) {
 		$file =~ s#^\Q$base\E/+##;
 	}
 
+	if (defined $config{include} && length $config{include}) {
+		return 0 if $file =~ m/$config{include}/;
+	}
+
 	my $regexp='('.join('|', @{$config{wiki_file_prune_regexps}}).')';
 	return $file =~ m/$regexp/;
 }
diff --git a/debian/changelog b/debian/changelog
index 92afe661f..e5347e2a1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,10 @@ ikiwiki (3.20100313) UNRELEASED; urgency=low
     as used by yahoo and google urls.
   * Add complete German basewiki and directives translation done by
     Sebastian Kuhnert.
+  * Add a include setting, which can be used to make ikiwiki process
+    wiki source files, such as .htaccess, that would normally be skipped
+    for security or other reasons. Closes: #447267
+    (Thanks to Aaron Wilson for the original patch.)
 
  -- Joey Hess   Sat, 13 Mar 2010 14:48:10 -0500
 
diff --git a/doc/tips/htaccess_file.mdwn b/doc/tips/htaccess_file.mdwn
new file mode 100644
index 000000000..5266eba41
--- /dev/null
+++ b/doc/tips/htaccess_file.mdwn
@@ -0,0 +1,30 @@
+If you try to include a `.htaccess` file in your wiki's source, in order to
+configure the web server, you'll find that ikiwiki excludes it from
+processing. In fact, ikiwiki excludes any file starting with a dot, as well
+as a lot of other files, for good security reasons.
+
+You can tell ikiwiki not to exclude the .htaccess file by adding this to
+your setup file:
+
+	include => '^\.htaccess$',
+
+Caution! Before you do that, please think for a minute about who can edit
+your wiki. Are attachment uploads enabled? Can users commit changes
+directly to the version control system? Do you trust everyone who can
+make a change to not do Bad Things with the htaccess file? Do you trust
+everyone who *might* be able to make a change in the future? Note that a
+determined attacker who can write to the htaccess file can probably get a
+shell on your web server.
+
+If any of these questions have given you pause, I suggest you find a
+different way to configure the web server. One way is to not put the
+`.htaccess` file under ikiwiki's control, and just manually install it
+in the destdir.
+
+[Apache's documentation](http://httpd.apache.org/docs/1.3/howto/htaccess.html)
+says
+> In general, you should never use .htaccess files unless you don't have
+> access to the main server configuration file.
+This is good advice -- if you can edit apache's main configuration files,
+then you should not use a htaccess file.
+--[[Joey]]
diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index 412cb5eba..c895db75d 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -61,3 +61,8 @@ It should be off by default of course. --Max
 +1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]]
 
 > I've described a workaround for one use case at the [[plugins/rsync]] [[plugins/rsync/discussion]] page. --[[schmonz]]
+
+---
+
+[[done]], you can use the `include` setting to override the default
+excludes now. Please use extreme caution when doing so. --[[Joey]] 
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index a105d7e59..f735170f0 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -234,6 +234,12 @@ also be configured using a setup file.
   Specifies a rexexp of source files to exclude from processing.
   May be specified multiple times to add to exclude list.
 
+* --include regexp
+
+  Specifies a rexexp of source files, that would normally be excluded,
+  but that you wish to include in processing.
+  May be specified multiple times to add to include list.
+
 * --adminuser name
 
   Specifies a username of a user (or, if openid is enabled, an openid) 
diff --git a/ikiwiki.in b/ikiwiki.in
index ae1251ff6..da5555629 100755
--- a/ikiwiki.in
+++ b/ikiwiki.in
@@ -65,6 +65,9 @@ sub getconfig () {
 			"exclude=s@" => sub {
 				push @{$config{wiki_file_prune_regexps}}, $_[1];
 			},
+			"include=s@" => sub {
+				$config{include}=defined $config{include} && length $config{include} ? "$config{include}|$_[1]" : $_[1];
+			},
 			"adminuser=s@" => sub {
 				push @{$config{adminuser}}, $_[1]
 			},
-- 
cgit v1.2.3


From a5ee40104481ba06eaaf277ed2f6c363dd326608 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 14 Mar 2010 15:08:41 -0400
Subject: note that the patch on this page is complely broken, and allows any
 file starting with a dot to be included

If you applied that patch to your site, you should remove it right away!
---
 doc/todo/enable-htaccess-files.mdwn | 7 +++++++
 1 file changed, 7 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index c895db75d..c08502bdd 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -12,6 +12,13 @@
                     qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//],
            wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/,
 
+> Note that the above patch is **completely broken**. 
+> It removes the crucial excludes of all files starting with a dot.
+> The negative regexps for htaccess have no effect, so the whole
+> thing only "works" because it allows *any* file starting with a dot.
+> If you applied this patch to your ikiwiki, you opened a huge security
+> hole. --[[Joey]] 
+
 [[!tag patch patch/core]]
 
 This lets the site administrator have a `.htaccess` file in their underlay
-- 
cgit v1.2.3


From 223b8efab0a55075bd53d03fe3cb2df07f13d9c1 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 14 Mar 2010 15:12:59 -0400
Subject: update

---
 doc/todo/enable-htaccess-files.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index c08502bdd..3b9721d50 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -64,6 +64,11 @@ It should be off by default of course. --Max
 ---
 +1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]]
 
+> Unless you cannot modify apache's configuration, you do not need htaccess
+> to do that. Apache's documentation recommends against using htaccess
+> unless you're a user who cannot modify the main server configuration.
+> --[[Joey]] 
+
 ---
 +1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]]
 
-- 
cgit v1.2.3


From 4054f8d8ce0802b43e1c2c6f9cb71badbbcaf919 Mon Sep 17 00:00:00 2001
From: kierun 
Date: Wed, 17 Mar 2010 09:14:46 +0000
Subject:

---
 doc/todo/ACL.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index d40701d60..57979385d 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -76,3 +76,12 @@ Any idea when this is going to be finished?  If you want, I am happy to beta tes
 > Example of use to only allow two users to edit the tipjar page:
 >	locked_pages => 'tipjar and !(user(joey) or user(bob))',
 > --[[Joey]] 
+
+> > Thank you for the hint but I am being still confused (read: dense)...  What I am trying to do is this:
+
+> >  * No anonymous access.
+> >  * Logged in users can edit and create pages.
+> >  * Users can set who can edit their pages. 
+> >  * Some pages are only viewable by admins. 
+
+> > Is it possible?  If so how?...
-- 
cgit v1.2.3


From ea07442e7ac6ef80cd98625b32f66bafc6af26b5 Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Thu, 18 Mar 2010 15:21:38 +0000
Subject: comment

---
 doc/todo/ACL.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index 57979385d..c1f5d86f0 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -21,6 +21,11 @@ something, that I think is very valuable.
 >>>> Which would rule out openid, or other fun forms of auth. And routing all access
 >>>> through the CGI sort of defeats the purpose of ikiwiki. --[[Ethan]]
 
+>>>>> I think what Joey is suggesting is to use apache ACLs in conjunction
+>>>>> with basic HTTP auth to control read access, and ikiwiki can use the
+>>>>> information via the httpauth plugin for other ACLs (write, admin). But
+>>>>> yes, that would rule out non-httpauth mechanisms. -- [[Jon]]
+
 Also see [[!debbug 443346]].
 
 > Just a few quick thoughts about this:
-- 
cgit v1.2.3


From 760c315589dc0e3fa0ba5380113f4e86a989a7d9 Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Thu, 18 Mar 2010 15:23:18 +0000
Subject: comment

---
 doc/todo/ACL.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index c1f5d86f0..cac6c9f18 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -90,3 +90,6 @@ Any idea when this is going to be finished?  If you want, I am happy to beta tes
 > >  * Some pages are only viewable by admins. 
 
 > > Is it possible?  If so how?...
+
+>>> I don't believe this is currently possible. What is missing is the concept
+>>> of page 'ownership'. -- [[Jon]]
-- 
cgit v1.2.3


From 96a54b35fe2cdcdc1450b5d38c80e7b27b428c14 Mon Sep 17 00:00:00 2001
From: kierun 
Date: Fri, 19 Mar 2010 15:45:26 +0000
Subject:

---
 doc/todo/ACL.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn
index cac6c9f18..dd9793233 100644
--- a/doc/todo/ACL.mdwn
+++ b/doc/todo/ACL.mdwn
@@ -93,3 +93,6 @@ Any idea when this is going to be finished?  If you want, I am happy to beta tes
 
 >>> I don't believe this is currently possible. What is missing is the concept
 >>> of page 'ownership'. -- [[Jon]]
+
+>>>> GAH! That is really a shame... Any chance of adding that?  No, I do not really expect it to be added, after all my requirements are pushing the boundary of what a wikiwiki
+ should be.  Nonetheless, thanks for your help! 
-- 
cgit v1.2.3


From 1c7d5eabd7c9e94498af7f89a005311a850d742c Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 24 Mar 2010 03:24:15 +0000
Subject: propsed branch

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 47 ++++++++++++++++++++++
 1 file changed, 47 insertions(+)
 create mode 100644 doc/todo/allow_plugins_to_add_sorting_methods.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
new file mode 100644
index 000000000..3aa1d94a6
--- /dev/null
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -0,0 +1,47 @@
+[[!template id=gitbranch branch=smcv/sort-hooks author="[[Simon_McVittie|smcv]]"]]
+[[!tag patch]]
+
+The available [[ikiwiki/pagespec/sorting]] methods are currently hard-coded in
+IkiWiki.pm, making it difficult to add any extra sorting mechanisms. I've
+prepared a branch which adds 'sort' as a hook type and uses it to implement a
+new `meta_title` sort type.
+
+Someone could use this hook to make `\[[!inline sort=title]]` prefer the meta
+title over the page name, but for compatibility, I'm not going to (I do wonder
+whether it would be worth making sort=name an alias for the current sort=title,
+and changing the meaning of sort=title in 4.0, though).
+
+Gitweb:
+
+
+## Documentation extracted from the branch
+
+### sort hook (added to [[plugins/write]])
+
+       hook(type => "sort", id => "foo", call => \&sort_by_foo);
+
+This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides
+an existing one. The callback is given two page names as arguments, and
+returns negative, zero or positive if the first page should come before,
+close to (i.e. undefined order), or after the second page.
+
+For instance, the built-in `title` sort order could be reimplemented as
+
+       sub sort_by_title {
+               pagetitle(basename($_[0])) cmp pagetitle(basename($_[1]));
+       }
+
+### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
+
+* `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]`
+  or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
+  full title was set.
+
+### meta title sort parameter (added to [[ikiwiki/directive/meta]])
+
+An optional `sort` parameter will be used preferentially when
+[[ikiwiki/pagespec/sorting]] by `meta_title`:
+
+       \[[!meta title="The Beatles" sort="Beatles, The"]]
+
+       \[[!meta title="David Bowie" sort="Bowie, David"]]
-- 
cgit v1.2.3


From 7fbddb032ee952c6d0b1ee290568ea4f42ef181f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 24 Mar 2010 03:27:11 +0000
Subject: link to an alternative approach that I decided against

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 3aa1d94a6..1533b6c44 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -14,6 +14,12 @@ and changing the meaning of sort=title in 4.0, though).
 Gitweb:
 
 
+I briefly tried to turn *all* the current sort types into hook functions, and
+have some of them pre-registered, but decided that probably wasn't a good idea.
+That earlier version of the branch is also available for comparison:
+
+
+
 ## Documentation extracted from the branch
 
 ### sort hook (added to [[plugins/write]])
-- 
cgit v1.2.3


From 48c09d44637dd724d084b1d06e2277f11e80d489 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 24 Mar 2010 03:30:06 +0000
Subject: note: old version untested

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 1533b6c44..99f256fbe 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -20,6 +20,11 @@ That earlier version of the branch is also available for comparison:
 
 
 
+(The older version is untested, and probably doesn't really work as-is - I
+misunderstood the details of how the built-in function `sort` works when using
+`$a` and `$b`. The newer version has been tested, and has a regression test for
+its core functionality.)
+
 ## Documentation extracted from the branch
 
 ### sort hook (added to [[plugins/write]])
-- 
cgit v1.2.3


From 9d4bedf760fbbbdba28986c01c3e429f67386217 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 24 Mar 2010 17:11:17 +0000
Subject: relationship with [[plugins/contrib/report]]

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 99f256fbe..21800f4de 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -25,6 +25,21 @@ misunderstood the details of how the built-in function `sort` works when using
 `$a` and `$b`. The newer version has been tested, and has a regression test for
 its core functionality.)
 
+This hook *isn't* (yet) sufficient to implement [[plugins/contrib/report]]'s
+NIH'd sorting mechanisms:
+
+* `report` can sort by any [[plugins/contrib/field]], whereas this one has a
+  finite number of hooks: if the `field` plugin's functionality is desirable,
+  perhaps parameterized sort mechanisms similar to pagespec match functions
+  would be useful? Then the `field` plugin could register
+  `hook(type => "sort", id => "field")` and you could have
+  `\[[!inline ... sort="field(Mood)"]]` or something?
+
+* `report` can sort by multiple criteria, with independent direction-changing:
+  if this is desirable, perhaps `pagespec_match_list` could be enhanced to
+  interpret `sort="x -y z(w)"` as sorting by (pseudocode)
+  `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
+
 ## Documentation extracted from the branch
 
 ### sort hook (added to [[plugins/write]])
-- 
cgit v1.2.3


From 1a587504e949bf0584acdf7737597c8332467332 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Wed, 24 Mar 2010 22:48:47 +0000
Subject: what about a SortSpec rather than a sort-hook?

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 21800f4de..5bfe102ac 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -40,6 +40,8 @@ NIH'd sorting mechanisms:
   interpret `sort="x -y z(w)"` as sorting by (pseudocode)
   `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
 
+>> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
+
 ## Documentation extracted from the branch
 
 ### sort hook (added to [[plugins/write]])
-- 
cgit v1.2.3


From 81cd30690024db1fc0b300e3a09504f1c613be21 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Thu, 25 Mar 2010 00:05:58 +0000
Subject: an updated branch

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 29 +++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 5bfe102ac..419a73419 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -40,8 +40,13 @@ NIH'd sorting mechanisms:
   interpret `sort="x -y z(w)"` as sorting by (pseudocode)
   `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
 
+> I've now added both of these features to the sort-hooks branch. --[[smcv]]
+
 >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
 
+>>> I'd be inclined to think that's overkill, but it probably wouldn't be
+>>> all that hard to implement... Joey? Any thoughts? --s
+
 ## Documentation extracted from the branch
 
 ### sort hook (added to [[plugins/write]])
@@ -49,7 +54,9 @@ NIH'd sorting mechanisms:
        hook(type => "sort", id => "foo", call => \&sort_by_foo);
 
 This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides
-an existing one. The callback is given two page names as arguments, and
+an existing one.
+
+The callback is given two page names followed by the parameter as arguments, and
 returns negative, zero or positive if the first page should come before,
 close to (i.e. undefined order), or after the second page.
 
@@ -59,12 +66,32 @@ For instance, the built-in `title` sort order could be reimplemented as
                pagetitle(basename($_[0])) cmp pagetitle(basename($_[1]));
        }
 
+and to sort by an arbitrary `meta` value, you could use:
+
+       # usage: sort="meta(description)"
+       sub sort_by_meta {
+               my $param = $_[2];
+               error "sort=meta requires a parameter" unless defined $param;
+               my $left = $pagestate{$_[0]}{meta}{$param};
+               $left = "" unless defined $left;
+               my $right = $pagestate{$_[1]}{meta}{$param};
+               $right = "" unless defined $right;
+               return $left cmp $right;
+       }
+
+
 ### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
 
 * `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]`
   or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
   full title was set.
 
+### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
+
+In addition, you can combine several sort orders and/or reverse the order of
+sorting, with a string like `age -title` (which would sort by age, then by
+title in reverse order if two pages have the same age).
+
 ### meta title sort parameter (added to [[ikiwiki/directive/meta]])
 
 An optional `sort` parameter will be used preferentially when
-- 
cgit v1.2.3


From 959d5b197d842e494076034f89d7bca84e531a45 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Thu, 25 Mar 2010 23:39:45 +0000
Subject: an alternative way to do plugins, as rubykat suggested

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 37 ++++++++++++++++++++--
 1 file changed, 34 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 419a73419..f37a0758e 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -44,10 +44,13 @@ NIH'd sorting mechanisms:
 
 >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
 
->>> I'd be inclined to think that's overkill, but it probably wouldn't be
->>> all that hard to implement... Joey? Any thoughts? --s
+>>> [[!template id=gitbranch branch=smcv/sort-package author="[[Simon_McVittie|smcv]]"]]
+>>> I'd be inclined to think that's overkill, but it wasn't very hard to
+>>> implement, and in a way is more elegant. I set it up so sort mechanisms
+>>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
+>>> 
 
-## Documentation extracted from the branch
+## Documentation from sort-hooks branch
 
 ### sort hook (added to [[plugins/write]])
 
@@ -100,3 +103,31 @@ An optional `sort` parameter will be used preferentially when
        \[[!meta title="The Beatles" sort="Beatles, The"]]
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
+
+## Documentation from sort-hooks branch
+
+The changes to [[ikiwiki/pagespec/sorting]] are the same.
+The changes to [[plugins/write]] are replaced by:
+
+### Sorting plugins
+
+Similarly, it's possible to write plugins that add new functions as
+[[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to
+the IkiWiki::PageSpec package named `cmp_foo`, which will be used when sorting
+by `foo` or `foo(...)` is requested.
+
+The function will be passed three or more parameters. The first two are
+page names, and the third is `undef` if invoked as `foo`, or the parameter
+`"bar"` if invoked as `foo(bar)`. It may also be passed additional, named
+parameters.
+
+It should return the same thing as Perl's `cmp` and `<=>` operators: negative
+if the first argument is less than the second, positive if the first argument
+is greater, or zero if they are considered equal. It may also raise an
+error using `error`, for instance if it needs a parameter but one isn't
+provided.
+
+You can also define a function called `check_cmp_foo` in the same package.
+If you do, it will be called while preparing to sort by `foo` or `foo(bar)`,
+with argument `undef` or `"bar"` respectively; it may raise an error using
+`error`, if sorting like that isn't going to work.
-- 
cgit v1.2.3


From 263d9548969dcdf9a6add96f46fe03ba7701a1ca Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Mon, 29 Mar 2010 14:58:21 +0100
Subject: ping joey: consider patch for next release?

---
 doc/todo/allow_site-wide_meta_definitions.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 99a9cf1e2..be66db99d 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -183,3 +183,5 @@ definitions essentially.
 >>> ikiwiki for the break, and now I've returned to watching recentchanges.
 >>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have
 >>> you had a chance to look at this yet? -- [[Jon]]
+>>>> Ping :) Hi.  [[Joey]], would you consider this patch for the next
+>>>> ikiwiki release? -- [[Jon]]
-- 
cgit v1.2.3


From 97898ce585b36dbcb0a83356ef3e54c41d369437 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 29 Mar 2010 12:16:53 -0400
Subject: review, multiple concerns

---
 doc/todo/allow_site-wide_meta_definitions.mdwn | 46 ++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 99a9cf1e2..e4638f94b 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -36,6 +36,30 @@ definitions essentially.
 >> I've made may not be acceptable, though -- I'd appreciate someone providing
 >> some feedback on that hunk!
 
+>>> Well, re that hunk, taint checking is currently disabled, but
+>>> if the perl bug that disallows it is fixed and it is turned back on,
+>>> the hash values will remain tainted, which will probably lead to
+>>> problems.
+>>>
+>>> I'm also leery of using such a complex data structure in config.
+>>> The websetup plugin would be hard pressed to provide a UI for such a
+>>> data structure. (It lacks even UI for a single hash ref yet, let alone
+>>> a list.)
+>>> 
+>>> Also, it seems sorta wrong to have two so very different syntaxes to 
+>>> represent the same meta data. A user without a lot of experience will
+>>> be hard pressed to map from a directive to this in the setup file.
+>>>
+>>> All of which leads me to think the setup file could just contain
+>>> a text that could hold meta directives. Which generalizes really to
+>>> a text that contains any directives, and is, perhaps appended to the
+>>> top of every page. Which nearly generalizes to the sidebar plugin,
+>>> or perhaps something more general than that... 
+>>>
+>>> However, excessive generalization is the root of all evil, so 
+>>> I'm not necessarily saying that's a good idea. Indeed, my memory
+>>> concerns below invalidate this idea pretty well. --[[Joey]] 
+
     diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm
     index 6fe9cda..2f8c098 100644
     --- a/IkiWiki/Plugin/meta.pm
@@ -125,6 +149,10 @@ definitions essentially.
 >> are only relevant to defined fields that you wouldn't want to specify a
 >> global default for anyway.
 >>
+>>> I generally agree with this. It is *possible* that meta would have a new
+>>> field added, that takes parameters and make sense to use globally.
+>>> --[[Joey]] 
+>>
 >> Due to this, and the added complexity of the second patch (having to adjust
 >> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus
 >> reverted to it here.
@@ -183,3 +211,21 @@ definitions essentially.
 >>> ikiwiki for the break, and now I've returned to watching recentchanges.
 >>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have
 >>> you had a chance to look at this yet? -- [[Jon]]
+
+>>> For this to work with websetup and --dumpsetup, it needs to define the
+>>> `meta_*` settings in the getsetup function.
+>>>
+>>> I also have some concerns about both these patches, since both throw
+>>> a lot of redundant data at meta, which then stores it in a very redundant
+>>> way. Specifically, meta populates a per-page `%metaheaders` hash
+>>> as well as storing per-page metadata in `%pagestate`. So, if you have
+>>> a wiki with a thousand pages, and you add a 1k site-wide license text,
+>>> that will bloat the memory usage of ikiwiki by in excess of 2
+>>> megabytes. It will also cause ikiwiki to write a similar amount more data
+>>> to its state file which has to be loaded back in each
+>>> run.
+>>>
+>>> Seems that this could be managed much more efficiently by having
+>>> meta special-case the site-wide settings, not store them in these
+>>> per-page data structures, and just make them be used if no per-page
+>>> metadata of the given type is present. --[[Joey]]
-- 
cgit v1.2.3


From 7a8bcf2a6745d570bf9055df7b0390f9a9ca8a0d Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 29 Mar 2010 12:19:22 -0400
Subject: fix bogus math

---
 doc/todo/allow_site-wide_meta_definitions.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 704cb2c64..01cf12c1a 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -222,7 +222,7 @@ definitions essentially.
 >>> a lot of redundant data at meta, which then stores it in a very redundant
 >>> way. Specifically, meta populates a per-page `%metaheaders` hash
 >>> as well as storing per-page metadata in `%pagestate`. So, if you have
->>> a wiki with a thousand pages, and you add a 1k site-wide license text,
+>>> a wiki with 10 thousand pages, and you add a 1k site-wide license text,
 >>> that will bloat the memory usage of ikiwiki by in excess of 2
 >>> megabytes. It will also cause ikiwiki to write a similar amount more data
 >>> to its state file which has to be loaded back in each
-- 
cgit v1.2.3


From 675e34527f56021ce39e56e4288e8f0e32b36cfa Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Mon, 29 Mar 2010 19:59:40 +0100
Subject: thanks for the review, patch to be revised

---
 doc/todo/allow_site-wide_meta_definitions.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 01cf12c1a..7129a44ac 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -232,3 +232,6 @@ definitions essentially.
 >>> meta special-case the site-wide settings, not store them in these
 >>> per-page data structures, and just make them be used if no per-page
 >>> metadata of the given type is present. --[[Joey]]
+
+>>>> Thanks for the review - these are all valid points. I'll get working
+>>>> on a revised patch. -- [[Jon]]
-- 
cgit v1.2.3


From 0b63800df32fd6e5287a253ca01a099f79b77e6e Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Mon, 29 Mar 2010 20:00:56 +0100
Subject: this sounds like the correct approach

---
 doc/todo/more_flexible_inline_postform.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/more_flexible_inline_postform.mdwn b/doc/todo/more_flexible_inline_postform.mdwn
index bc8bc0809..414476bd7 100644
--- a/doc/todo/more_flexible_inline_postform.mdwn
+++ b/doc/todo/more_flexible_inline_postform.mdwn
@@ -16,3 +16,8 @@ logical first step towards doing comment-like things with inlined pages).
 > Perhaps what we need is a `postform` plugin/directive that inline depends
 > on (automatically enables); its preprocess method could automatically be
 > invoked from preprocess_inline when needed. --[[smcv]]
+
+>> I've been looking at this stuff again. I think you are right, this would
+>> be the right approach. The comments plugin could use it similarly, allowing
+>> sites which desire it to have an inline comment submission form on all
+>> pages with comments enabled. I'm going to take a look. -- [[Jon]]
-- 
cgit v1.2.3


From f673ce266c8dadb263c6850cc5f7d3e6e7a68e70 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 30 Mar 2010 12:01:35 +0000
Subject: feature request (part of ftemplate)

---
 doc/todo/user-defined_templates_outside_the_wiki.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 doc/todo/user-defined_templates_outside_the_wiki.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/user-defined_templates_outside_the_wiki.mdwn b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
new file mode 100644
index 000000000..880ad6493
--- /dev/null
+++ b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
@@ -0,0 +1,8 @@
+[[!tag wishlist]]
+
+The [[plugins/contrib/ftemplate]] plugin looks for templates inside the wiki
+source, but also looks in the system templates directory (the one with
+`page.tmpl`). This means the wiki admin can provide templates that can be
+invoked via `\[[!template]]`, but don't have to "work" as wiki pages in their
+own right. I think the normal [[plugins/template]] plugin could benefit from
+this functionality.
-- 
cgit v1.2.3


From a7ef2204dc36777f847e282f57299d93342a8ad6 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Thu, 1 Apr 2010 23:40:37 +0000
Subject: implemented!

---
 doc/todo/matching_different_kinds_of_links.mdwn | 51 +++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 26c5a072b..0049281fe 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -36,6 +36,11 @@ Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
 > normal links.) Might be better to go ahead and add the variable to
 > core though. --[[Joey]] 
 
+>> I've implemented this with the data structure you suggested, except that
+>> I called it `%typedlinks` instead of `%linktype` (it seemed to make more
+>> sense that way). I also ported `tag` to it, and added a `tagged_is_strict`
+>> config option. See below! --[[smcv]]
+
 I saw somewhere else here some suggestions for the wiki-syntax for specifying the relation name of a link. One more suggestion---[the syntax used in Semantic MediaWiki](http://en.wikipedia.org/wiki/Semantic_MediaWiki#Basic_usage), like this:
 
 
@@ -45,3 +50,49 @@ I saw somewhere else here some suggestions for the wiki-syntax for specifying th
 So a part of the effect of [[`\[[!taglink TAG\]\]`|plugins/tag]] could be represented as something like `\[[tag::TAG]]` or (more understandable relation name in what concerns the direction) `\[[tagged::TAG]]`.
 
 I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
+
+-------
+
+>> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/link-types]]
+>> [[!tag patch]]
+
+## Documentation for smcv's branch
+
+### added to [[ikiwiki/pagespec]]
+
+* "`typedlink(type glob)`" - matches pages that link to a given page (or glob)
+  with a given link type. Plugins can create links with a specific type:
+  for instance, the tag plugin creates links of type `tag`.
+
+### added to [[plugins/tag]]
+
+If the `tagged_is_strict` config option is set, `tagged()` will only match
+tags explicitly set with [[ikiwiki/directive/tag]] or
+[[ikiwiki/directive/taglink]]; if not (the default), it will also match
+any other [[WikiLinks|ikiwiki/WikiLink]] to the tag page.
+
+### added to [[plugins/write]]
+
+#### `%typedlinks`
+
+The `%typedlinks` hash records links of specific types. Do not modify this
+hash directly; call `add_link()`. The keys are page names, and the values
+are hash references. In each page's hash reference, the keys are link types
+defined by plugins, and the values are hash references with link targets
+as keys, and 1 as a dummy value, something like this:
+
+	$typedlinks{"foo"} = {
+		tag => { short_word => 1, metasyntactic_variable => 1 },
+		next_page => { bar => 1 },
+	};
+
+Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
+`%typedlinks`.
+
+#### `add_link($$;$)`
+ 
+ This adds a link to `%links`, ensuring that duplicate links are not
+ added. Pass it the page that contains the link, and the link text.
+ 
+An optional third parameter sets the link type (`undef` produces an ordinary
+[[ikiwiki/WikiLink]]).
-- 
cgit v1.2.3


From 1c8ac7d88c5a3d2c63892737e54be8a1b535936c Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 16:41:04 -0400
Subject: review from the woods

---
 doc/todo/matching_different_kinds_of_links.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 0049281fe..20acdde49 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -96,3 +96,22 @@ Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
  
 An optional third parameter sets the link type (`undef` produces an ordinary
 [[ikiwiki/WikiLink]]).
+
+> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
+> 
+> I'm curious what your reasoning was for adding a new variable
+> rather than using `pagestate`. Was it only because you needed
+> the `old` version to detect change, or was there other complexity?
+> 
+> I have not convinced myself this is a real problem, but..
+> If a page has a typed link, there seems to be no way to tell
+> if it also has a separate, regular link. `add_link` will add
+> to `@links` when adding a typed, or untyped link. If only untyped
+> links were recorded there, one could tell the difference. But then
+> typed links would not show up at all in eg, a linkmap,
+> unless it was changed to check for typed links too.
+> (Or, regular links could be recorded in typedlinks too,
+> with a empty type. (Bloaty.))
+> 
+> I suspect we could get away without having `tagged_is_strict`
+> without too much transitional trouble. --[[Joey]]
-- 
cgit v1.2.3


From 59ba938822ba0752e8d97e769c0d14f2eb0bbeb3 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 16:54:06 -0400
Subject: template: Search for templates in the templatedir, if they are not
 found as pages in the wiki.

---
 IkiWiki/Plugin/template.pm                            | 10 ++++++++--
 debian/changelog                                      |  2 ++
 doc/templates.mdwn                                    |  6 ++++++
 doc/todo/user-defined_templates_outside_the_wiki.mdwn |  2 ++
 doc/wikitemplates.mdwn                                |  6 ++++--
 5 files changed, 22 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/template.pm b/IkiWiki/Plugin/template.pm
index 3e024c5f8..36282055a 100644
--- a/IkiWiki/Plugin/template.pm
+++ b/IkiWiki/Plugin/template.pm
@@ -37,7 +37,13 @@ sub preprocess (@) {
 	my $template_page="templates/$params{id}";
 	add_depends($params{page}, $template_page);
 
-	my $template_file=$pagesources{$template_page};
+	my $template_file;
+	if (exists $pagesources{$template_page}) {
+		$template_file=srcfile($pagesources{$template_page});
+	}
+	else {
+		$template_file=template_file("$params{id}.tmpl")
+	}
 	return sprintf(gettext("template %s not found"),
 		htmllink($params{page}, $params{destpage}, "/".$template_page))
 			unless defined $template_file;
@@ -50,7 +56,7 @@ sub preprocess (@) {
 	                        $$text_ref=&Encode::decode_utf8($$text_ref);
 				chomp $$text_ref;
 	                },
-	                filename => srcfile($template_file),
+	                filename => $template_file,
        			die_on_bad_params => 0,
 			no_includes => 1,
 			blind_cache => 1,
diff --git a/debian/changelog b/debian/changelog
index adf0dfed6..362ba54ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -26,6 +26,8 @@ ikiwiki (3.20100324) UNRELEASED; urgency=low
   * page.tmpl: Add Cache-Control must-revalidate to ensure that users
     (especially of Firefox) see fresh page content.
   * htmlscrubber: Allow colons in urls after '?'
+  * template: Search for templates in the templatedir, if they are not
+    found as pages in the wiki.
 
  -- Joey Hess   Sat, 13 Mar 2010 14:48:10 -0500
 
diff --git a/doc/templates.mdwn b/doc/templates.mdwn
index eff0e15e9..07531ae98 100644
--- a/doc/templates.mdwn
+++ b/doc/templates.mdwn
@@ -43,6 +43,12 @@ page will provide a link that can be used to create the template. The template
 is a regular wiki page, located in the `templates/` subdirectory inside
 the source directory of the wiki.
 
+(Alternatively, templates can be stored in a directory outside the wiki,
+as files with the extension ".tmpl".
+By default, these are searched for in `/usr/share/ikiwiki/templates`;
+the `templatedir` setting can be used to make another directory be searched
+first.)
+
 The template uses the syntax used by the [[!cpan HTML::Template]] perl
 module, which allows for some fairly complex things to be done. Consult its
 documentation for the full syntax, but all you really need to know are a
diff --git a/doc/todo/user-defined_templates_outside_the_wiki.mdwn b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
index 880ad6493..1d72aa6a7 100644
--- a/doc/todo/user-defined_templates_outside_the_wiki.mdwn
+++ b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
@@ -6,3 +6,5 @@ source, but also looks in the system templates directory (the one with
 invoked via `\[[!template]]`, but don't have to "work" as wiki pages in their
 own right. I think the normal [[plugins/template]] plugin could benefit from
 this functionality.
+
+[[done]] --[[Joey]] 
diff --git a/doc/wikitemplates.mdwn b/doc/wikitemplates.mdwn
index 6c0480cea..6e5a7261d 100644
--- a/doc/wikitemplates.mdwn
+++ b/doc/wikitemplates.mdwn
@@ -5,7 +5,8 @@ to learn.
 The aim is to keep almost all html out of ikiwiki and in the templates.
 
 It ships with some basic templates which can be customised. These are
-located in /usr/share/ikiwiki/templates by default.
+located in `/usr/share/ikiwiki/templates` by default; the `templatedir`
+setting can be used to make another directory be searched first.
 
 * `page.tmpl` - Used for displaying all regular wiki pages.
 * `misc.tmpl` - Generic template used for any page that doesn't
@@ -43,7 +44,8 @@ The [[plugins/pagetemplate]] plugin can allow individual pages to use a
 different template than `page.tmpl`.
 
 The [[plugins/template]] plugin also uses templates, though those
-[[templates]] are stored in the wiki and inserted into pages.
+[[templates]] are typically stored as pages in the wiki, and are inserted
+into pages.
 
 The [[plugins/edittemplate]] plugin is used to make new pages default to
 containing text from a template, which can be filled as out the page is
-- 
cgit v1.2.3


From de62ea1cc8111dd96bc84b9c839be99c921168e3 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:03:33 -0400
Subject: fix branch name

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index f37a0758e..8edc95fb9 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -104,7 +104,7 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
-## Documentation from sort-hooks branch
+## Documentation from sort-package branch
 
 The changes to [[ikiwiki/pagespec/sorting]] are the same.
 The changes to [[plugins/write]] are replaced by:
-- 
cgit v1.2.3


From 1b0d4e8d885ded59ca0ad1b4d1ca1315585cce06 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:16:12 -0400
Subject: minor comment

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 8edc95fb9..e4e1829dc 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -89,6 +89,9 @@ and to sort by an arbitrary `meta` value, you could use:
   or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
   full title was set.
 
+  > I feel it sould be clearer to call that "sortas", since "sort=" is used
+  > to specify a sort method in other directives. --[[Joey]]
+
 ### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
 
 In addition, you can combine several sort orders and/or reverse the order of
-- 
cgit v1.2.3


From 9e7dcefd7ed9424de20706f63c7bab5182c5df78 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:26:32 -0400
Subject: comments

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e4e1829dc..67d85f6f8 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -50,6 +50,21 @@ NIH'd sorting mechanisms:
 >>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
 >>> 
 
+>>>> I agree it seems more elegant, so I have focused on it.
+>>>>
+>>>> I don't know about reusing `IkiWiki::PageSpec` for this.
+>>>>
+>>>> I would be inclined to drop the `check_` stuff.
+>>>>
+>>>> Wouldn't it make sense to have `meta(title)` instead
+>>>> of `meta_title`?
+>>>>
+>>>> As I read the regexp in `cmpspec_translate`, the "command"
+>>>> is required to have params. They should be optional, 
+>>>> to match the documentation and because most sort methods
+>>>> do not need parameters.
+>>>> --[[Joey]]
+
 ## Documentation from sort-hooks branch
 
 ### sort hook (added to [[plugins/write]])
-- 
cgit v1.2.3


From 1faf9b08e16bde9b4b0d72620fcef79c715e64de Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:37:38 -0400
Subject: idea

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 67d85f6f8..e1e05e81c 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -63,6 +63,14 @@ NIH'd sorting mechanisms:
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
 >>>> do not need parameters.
+>>>>
+>>>> I wonder if it would make sense to add some combining keywords, so
+>>>> a sortspec reads like `sort="age then ascending title"`
+>>>> In a way, this reduces the amount of syntax that needs to be learned.
+>>>> I like the "then" (and it could allow other operations than
+>>>> simple combination, if any others make sense). Not so sure about the
+>>>> "ascending", which could be "reverse" instead, but "descending age" and
+>>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
 ## Documentation from sort-hooks branch
-- 
cgit v1.2.3


From 2c7fe7ae2cf73141eba817d4275d9a6a897df8a8 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Fri, 2 Apr 2010 22:25:16 +0000
Subject: respond (also unindent Joey's review to avoid very deep indentation)

---
 doc/todo/matching_different_kinds_of_links.mdwn | 61 +++++++++++++++++--------
 1 file changed, 43 insertions(+), 18 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 20acdde49..f8796652e 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -97,21 +97,46 @@ Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
 An optional third parameter sets the link type (`undef` produces an ordinary
 [[ikiwiki/WikiLink]]).
 
-> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
-> 
-> I'm curious what your reasoning was for adding a new variable
-> rather than using `pagestate`. Was it only because you needed
-> the `old` version to detect change, or was there other complexity?
-> 
-> I have not convinced myself this is a real problem, but..
-> If a page has a typed link, there seems to be no way to tell
-> if it also has a separate, regular link. `add_link` will add
-> to `@links` when adding a typed, or untyped link. If only untyped
-> links were recorded there, one could tell the difference. But then
-> typed links would not show up at all in eg, a linkmap,
-> unless it was changed to check for typed links too.
-> (Or, regular links could be recorded in typedlinks too,
-> with a empty type. (Bloaty.))
-> 
-> I suspect we could get away without having `tagged_is_strict`
-> without too much transitional trouble. --[[Joey]]
+## Review
+
+Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
+
+> Oops, I'll fix that. That must mean missing test coverage, too :-(
+> --s
+
+I'm curious what your reasoning was for adding a new variable
+rather than using `pagestate`. Was it only because you needed
+the `old` version to detect change, or was there other complexity?
+--J
+
+> You seemed to be more in favour of adding it to the core in
+> your proposal above, so I assumed that'd be more likely to be
+> accepted :-) I don't mind one way or the other - `%typedlinks`
+> costs one core variable, but saves one level of hash nesting. If
+> you're not sure either, then I think the decision should come down
+> to which one is easier to document clearly - I'm still unhappy with
+> my docs for `%typedlinks`, so I'll try to write docs for it as
+> `pagestate` and see if they work any better. --s
+
+I have not convinced myself this is a real problem, but..
+If a page has a typed link, there seems to be no way to tell
+if it also has a separate, regular link. `add_link` will add
+to `@links` when adding a typed, or untyped link. If only untyped
+links were recorded there, one could tell the difference. But then
+typed links would not show up at all in eg, a linkmap,
+unless it was changed to check for typed links too.
+(Or, regular links could be recorded in typedlinks too,
+with a empty type. (Bloaty.)) --J
+
+> I think I like the semantics as-is - I can't think of any
+> reason why you'd want to ask the question "does A link to B,
+> not counting tags and other typed links?". A typed link is
+> still a link, in my mind at least. --s
+
+I suspect we could get away without having `tagged_is_strict`
+without too much transitional trouble. --[[Joey]]
+
+> If you think so, I can delete about 5 LoC. I don't particularly
+> care either way; [[Jon]] expressed concern about people relying
+> on the current semantics, on one of the pages requesting this
+> change. --s
-- 
cgit v1.2.3


From 011fe920d162924876170d167be11dc64cf8be2f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:00:53 +0000
Subject: respond at some length

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 163 ++++++++++++---------
 1 file changed, 94 insertions(+), 69 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e1e05e81c..156678da7 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -1,4 +1,3 @@
-[[!template id=gitbranch branch=smcv/sort-hooks author="[[Simon_McVittie|smcv]]"]]
 [[!tag patch]]
 
 The available [[ikiwiki/pagespec/sorting]] methods are currently hard-coded in
@@ -11,36 +10,13 @@ title over the page name, but for compatibility, I'm not going to (I do wonder
 whether it would be worth making sort=name an alias for the current sort=title,
 and changing the meaning of sort=title in 4.0, though).
 
-Gitweb:
-
+*[sort-hooks branch now withdrawn in favour of sort-package --s]*
 
 I briefly tried to turn *all* the current sort types into hook functions, and
 have some of them pre-registered, but decided that probably wasn't a good idea.
 That earlier version of the branch is also available for comparison:
 
-
-
-(The older version is untested, and probably doesn't really work as-is - I
-misunderstood the details of how the built-in function `sort` works when using
-`$a` and `$b`. The newer version has been tested, and has a regression test for
-its core functionality.)
-
-This hook *isn't* (yet) sufficient to implement [[plugins/contrib/report]]'s
-NIH'd sorting mechanisms:
-
-* `report` can sort by any [[plugins/contrib/field]], whereas this one has a
-  finite number of hooks: if the `field` plugin's functionality is desirable,
-  perhaps parameterized sort mechanisms similar to pagespec match functions
-  would be useful? Then the `field` plugin could register
-  `hook(type => "sort", id => "field")` and you could have
-  `\[[!inline ... sort="field(Mood)"]]` or something?
-
-* `report` can sort by multiple criteria, with independent direction-changing:
-  if this is desirable, perhaps `pagespec_match_list` could be enhanced to
-  interpret `sort="x -y z(w)"` as sorting by (pseudocode)
-  `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
-
-> I've now added both of these features to the sort-hooks branch. --[[smcv]]
+*[also withdrawn in favour of sort-package --s]*
 
 >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
 
@@ -53,17 +29,65 @@ NIH'd sorting mechanisms:
 >>>> I agree it seems more elegant, so I have focused on it.
 >>>>
 >>>> I don't know about reusing `IkiWiki::PageSpec` for this.
->>>>
+>>>> --[[Joey]]
+
+>>>>> Fair enough, `IkiWiki::SortSpec::cmp_foo` would be just
+>>>>> as easy, or `IkiWiki::Sorting::cmp_foo` if you don't like
+>>>>> introducing "sort spec" in the API. I took a cue from
+>>>>> [[ikiwiki/pagespec/sorting]] being a subpage of
+>>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
+>>>>> a bit like a pagespec :-) --s
+
 >>>> I would be inclined to drop the `check_` stuff.
->>>>
+
+>>>>> It basically exists to support `title_natural`, to avoid
+>>>>> firing up the whole import mechanism on every `cmp`
+>>>>> (although I suppose that could just be a call to a
+>>>>> memoized helper function). It also lets sort specs that
+>>>>> *must* have a parameter, like
+>>>>> [[field|plugins/contrib/field/discussion]], fail early
+>>>>> (again, not so valuable).
+>>>>>
+>>>>> The former function could be achieved at a small
+>>>>> compatibility cost by putting `title_natural` in a new
+>>>>> sortnatural plugin (that fails to load if you don't
+>>>>> have `title_natural`), if you'd prefer - that's what would
+>>>>> have happened if `title_natural` was written after this
+>>>>> code had been merged, I suspect. --s
+
 >>>> Wouldn't it make sense to have `meta(title)` instead
->>>> of `meta_title`?
->>>>
+>>>> of `meta_title`? --J
+
+>>>>> Yes, you're right. I added parameters to support `field`,
+>>>>> and didn't think about making `meta` use them too.
+>>>>> However, `title` does need a special case to make it
+>>>>> default to the basename instead of the empty string.
+>>>>>
+>>>>> Another special case for `title` is to use `titlesort`
+>>>>> first (the name `titlesort` is derived from Ogg/FLAC
+>>>>> tags, which can have `titlesort` and `artistsort`).
+>>>>> I could easily extend that to other metas, though;
+>>>>> in fact, for e.g. book lists it would be nice for
+>>>>> `field(bookauthor)` to behave similarly, so you can
+>>>>> display "Douglas Adams" but sort by "Adams, Douglas".
+>>>>>
+>>>>> `meta_title` is also meant to be a prototype of how
+>>>>> `sort=title` could behave in 4.0 or something - sorting
+>>>>> by page name (which usually sorts in approximately the
+>>>>> same place as the meta-title, but occasionally not), while
+>>>>> displaying meta-titles, does look quite odd. --s
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
->>>> do not need parameters.
->>>>
+>>>> do not need parameters. --J
+
+>>>>> No, `$2` is either `\w+\([^\)]*\)` or `[^\s]+` (with the
+>>>>> latter causing an error later if it doesn't also match `\w+`).
+>>>>> This branch doesn't add any parameterized sort methods,
+>>>>> in fact, although I did provide one on
+>>>>> [[field's_discussion_page|plugins/contrib/report/discussion]]. --s
+
 >>>> I wonder if it would make sense to add some combining keywords, so
 >>>> a sortspec reads like `sort="age then ascending title"`
 >>>> In a way, this reduces the amount of syntax that needs to be learned.
@@ -73,38 +97,42 @@ NIH'd sorting mechanisms:
 >>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
-## Documentation from sort-hooks branch
-
-### sort hook (added to [[plugins/write]])
-
-       hook(type => "sort", id => "foo", call => \&sort_by_foo);
-
-This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides
-an existing one.
-
-The callback is given two page names followed by the parameter as arguments, and
-returns negative, zero or positive if the first page should come before,
-close to (i.e. undefined order), or after the second page.
-
-For instance, the built-in `title` sort order could be reimplemented as
-
-       sub sort_by_title {
-               pagetitle(basename($_[0])) cmp pagetitle(basename($_[1]));
-       }
-
-and to sort by an arbitrary `meta` value, you could use:
-
-       # usage: sort="meta(description)"
-       sub sort_by_meta {
-               my $param = $_[2];
-               error "sort=meta requires a parameter" unless defined $param;
-               my $left = $pagestate{$_[0]}{meta}{$param};
-               $left = "" unless defined $left;
-               my $right = $pagestate{$_[1]}{meta}{$param};
-               $right = "" unless defined $right;
-               return $left cmp $right;
-       }
+>>>>> Perhaps. I do like the simplicity of [[KathyrnAndersen]]'s syntax
+>>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
+>>>>> turning sort-by-`field` into a parameterized spec), and I can't really
+>>>>> think of any sensible way to combine sort specs other than "sort by a,
+>>>>> break ties by b, ...", possibly with some reversals thrown in.
+>>>>>
+>>>>> If no other combinations do make sense, is your proposal that "then"
+>>>>> is entirely redundant (easy, just make it a predefined sort spec that
+>>>>> returns 0!), or that it's mandatory "punctuation" (add an explicit
+>>>>> check, or make "then" expand to "||" and let Perl fail to compile
+>>>>> the generated code if it's omitted)?
+>>>>>
+>>>>> It is a little unfortunate that reversal has to move into the sort
+>>>>> spec - I prefer `reverse=yes` - but that's necessary for multi-level
+>>>>> sorting. I can see your point about ascending/descending being more
+>>>>> obvious to look at, but they're also considerably more verbose.
+>>>>>
+>>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
+>>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
+>>>>> now minus `ctime`). `sort=freshness` isn't right either, because
+>>>>> "sort by freshness" seems as though it ought to mean freshest first,
+>>>>> but "sort by ascending freshness" means put the least fresh first. If
+>>>>> we have ascending and descending keywords which are optional, I don't
+>>>>> think we really want different sort types to have different default
+>>>>> directions - it seems clearer to have `ascending` always be a no-op,
+>>>>> and `descending` always negate.
+>>>>>
+>>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
+>>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
+>>>>> makes me think that updateage is a quantity analagous to tonnage or
+>>>>> voltage, with more or less recently updated pages being said to have
+>>>>> more or less updateage. I don't know whether that's good or bad :-)
+>>>>>
+>>>>> I'm sure there's a much better word, but I can't see it. --s
 
+## Documentation from sort-package branch
 
 ### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
 
@@ -115,6 +143,8 @@ and to sort by an arbitrary `meta` value, you could use:
   > I feel it sould be clearer to call that "sortas", since "sort=" is used
   > to specify a sort method in other directives. --[[Joey]]
 
+  >> Fair enough, that's easy to do. --[[smcv]]
+
 ### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
 
 In addition, you can combine several sort orders and/or reverse the order of
@@ -130,12 +160,7 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
-## Documentation from sort-package branch
-
-The changes to [[ikiwiki/pagespec/sorting]] are the same.
-The changes to [[plugins/write]] are replaced by:
-
-### Sorting plugins
+### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as
 [[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to
-- 
cgit v1.2.3


From aec7dec2795aedfe1f13cff9a888bed83ee760df Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:12:59 +0000
Subject: make questions to Joey more explicit

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 156678da7..36c134a59 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -36,9 +36,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> introducing "sort spec" in the API. I took a cue from
 >>>>> [[ikiwiki/pagespec/sorting]] being a subpage of
 >>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
->>>>> a bit like a pagespec :-) --s
+>>>>> a bit like a pagespec :-) Which name would you prefer? --s
 
->>>> I would be inclined to drop the `check_` stuff.
+>>>> I would be inclined to drop the `check_` stuff. --J
 
 >>>>> It basically exists to support `title_natural`, to avoid
 >>>>> firing up the whole import mechanism on every `cmp`
@@ -50,10 +50,10 @@ That earlier version of the branch is also available for comparison:
 >>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
->>>>> sortnatural plugin (that fails to load if you don't
+>>>>> `sortnatural` plugin (that fails to load if you don't
 >>>>> have `title_natural`), if you'd prefer - that's what would
 >>>>> have happened if `title_natural` was written after this
->>>>> code had been merged, I suspect. --s
+>>>>> code had been merged, I suspect. Would you prefer this? --s
 
 >>>> Wouldn't it make sense to have `meta(title)` instead
 >>>> of `meta_title`? --J
@@ -97,7 +97,7 @@ That earlier version of the branch is also available for comparison:
 >>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
->>>>> Perhaps. I do like the simplicity of [[KathyrnAndersen]]'s syntax
+>>>>> Perhaps. I do like the simplicity of [[KathrynAndersen]]'s syntax
 >>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
 >>>>> turning sort-by-`field` into a parameterized spec), and I can't really
 >>>>> think of any sensible way to combine sort specs other than "sort by a,
@@ -130,7 +130,8 @@ That earlier version of the branch is also available for comparison:
 >>>>> voltage, with more or less recently updated pages being said to have
 >>>>> more or less updateage. I don't know whether that's good or bad :-)
 >>>>>
->>>>> I'm sure there's a much better word, but I can't see it. --s
+>>>>> I'm sure there's a much better word, but I can't see it. Do you have
+>>>>> a better idea? --s
 
 ## Documentation from sort-package branch
 
-- 
cgit v1.2.3


From 5f87d5d242b87ce5cfbd7ac5fcb1efcc62fc5582 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:25:28 +0000
Subject: actually I can see a second use for "nonlinear" syntax - but I don't
 think it's worth it

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 32 ++++++++++++++--------
 1 file changed, 20 insertions(+), 12 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 36c134a59..1657ca8e9 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -99,20 +99,28 @@ That earlier version of the branch is also available for comparison:
 
 >>>>> Perhaps. I do like the simplicity of [[KathrynAndersen]]'s syntax
 >>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
->>>>> turning sort-by-`field` into a parameterized spec), and I can't really
->>>>> think of any sensible way to combine sort specs other than "sort by a,
->>>>> break ties by b, ...", possibly with some reversals thrown in.
+>>>>> turning sort-by-`field` into a parameterized spec).
 >>>>>
->>>>> If no other combinations do make sense, is your proposal that "then"
->>>>> is entirely redundant (easy, just make it a predefined sort spec that
->>>>> returns 0!), or that it's mandatory "punctuation" (add an explicit
->>>>> check, or make "then" expand to "||" and let Perl fail to compile
->>>>> the generated code if it's omitted)?
+>>>>> If we're getting into English-like (or at least SQL-like) queries,
+>>>>> it might make sense to change the signature of the hook function
+>>>>> so it's a function to return a key, e.g.
+>>>>> `sub key_age { return -%pagemtime{$_[0]) }`. Then we could sort like
+>>>>> this:
 >>>>>
->>>>> It is a little unfortunate that reversal has to move into the sort
->>>>> spec - I prefer `reverse=yes` - but that's necessary for multi-level
->>>>> sorting. I can see your point about ascending/descending being more
->>>>> obvious to look at, but they're also considerably more verbose.
+>>>>>     field(artistsort) or field(artist) or constant(Various Artists) then meta(titlesort) or meta(title) or title
+>>>>>
+>>>>> with "or" binding more closely than "then". Does this seem valuable?
+>>>>> I think the implementation would be somewhat more difficult. and
+>>>>> it's probably getting too complicated to be worthwhile, though?
+>>>>> (The keys that actually benefit from this could just
+>>>>> have smarter cmp functions, I think.)
+>>>>>
+>>>>> If the hooks return keys rather than cmp results, then we could even
+>>>>> have "lowercase" as an adjective used like "ascending"... maybe.
+>>>>> However, there are two types of adjective here: "lowercase"
+>>>>> really applies to the keys, whereas "ascending" applies to the "cmp"
+>>>>> result. Again, I think this is getting too complex, and could just
+>>>>> be solved with smarter cmp functions.
 >>>>>
 >>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
 >>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
-- 
cgit v1.2.3


From c2f54ccfb7b401b59f7eda13095e2ba2af69ed7a Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:41:31 +0000
Subject: sort-order could usefully be overridden for meta author, too

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 1657ca8e9..e79e52f39 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -169,6 +169,9 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
+> I now realise that `author` should also have this, again for use
+> with (Western) names. --s
+
 ### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as
-- 
cgit v1.2.3


From c4a838b33a34ff61a1dd5c6f65e40df3609e727f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:53:59 +0000
Subject: perhaps the typedlink(tag foo) pagespec isn't so useful

---
 doc/todo/matching_different_kinds_of_links.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index f8796652e..4f52ade52 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -140,3 +140,12 @@ without too much transitional trouble. --[[Joey]]
 > care either way; [[Jon]] expressed concern about people relying
 > on the current semantics, on one of the pages requesting this
 > change. --s
+
+I might have been wrong to introduce `typedlink(tag foo)`. It's not
+very user-friendly, and is more useful as a backend for other plugins
+that as a feature in its own right - any plugin introducing a link
+type will probably also want to have its own preprocessor directive
+to set that link type, and its own pagespec function to match it.
+I wonder whether to make a `typedlink` plugin that has the typedlink
+pagespec match function and a new `\[[!typedlink to="foo" type="bar"]]`
+though... --[[smcv]]
-- 
cgit v1.2.3


From 3934759592c35ab475e06501e2e4613d5c1f2e08 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 01:13:08 +0000
Subject: vague musings about wikilinks

---
 .../link_plugin_perhaps_too_general__63__.mdwn     | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 doc/todo/link_plugin_perhaps_too_general__63__.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/link_plugin_perhaps_too_general__63__.mdwn b/doc/todo/link_plugin_perhaps_too_general__63__.mdwn
new file mode 100644
index 000000000..8a5fd50eb
--- /dev/null
+++ b/doc/todo/link_plugin_perhaps_too_general__63__.mdwn
@@ -0,0 +1,25 @@
+[[!tag wishlist blue-sky]]
+(This isn't important to me - I don't use MediaWiki or Creole syntax myself -
+but just thinking out loud...)
+
+The [[ikiwiki/wikilink]] syntax IkiWiki uses sometimes conflicts with page
+languages' syntax (notably, [[plugins/contrib/MediaWiki]] and [[plugins/Creole]]
+want their wikilinks the other way round, like
+`\[[plugins/write|how to write a plugin]]`). It would be nice if there was
+some way for page language plugins to opt in/out of the normal wiki link
+processing - then MediaWiki and Creole could have their own `linkify` hook
+that was only active for *their* page types, and used the appropriate
+syntax.
+
+In [[todo/matching_different_kinds_of_links]] I wondered about adding a
+`\[[!typedlink to="foo" type="bar"]]` directive. This made me wonder whether
+a core `\[[!link]]` directive would be useful; this could be a fallback for
+page types where a normal wikilink can't be done for whatever reason, and
+could also provide extension points more easily than WikiLinks' special
+syntax with extra punctuation, which doesn't really scale?
+
+Straw-man:
+
+    \[[!link to="ikiwiki/wikilink" desc="WikiLinks"]]
+
+--[[smcv]]
-- 
cgit v1.2.3


From 5445fe765777dc6254c7e0e13d4fa5e07810751a Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 01:15:28 +0000
Subject: cross-reference

---
 doc/todo/rewrite_ikiwiki_in_haskell.mdwn | 1 +
 1 file changed, 1 insertion(+)

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
index 204c48cd7..48ed744b1 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
@@ -29,6 +29,7 @@ It's appealing for a lot of reasons, including:
     edit in html editors currently.
   - This would be a chance to make WikiLinks with link texts read
     "the right way round" (ie, vaguely wiki creole compatably).
+    *[See also [[todo/link_plugin_perhaps_too_general?]] --[[smcv]]]*
   - The data structures would probably be quite different.
   - I might want to drop a lot of the command-line flags, either
     requiring a setup file be used for those things, or leaving the
-- 
cgit v1.2.3


From e4e53d7a18ec18d1ba72b1a4f124e211148e0f12 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 22:23:36 -0400
Subject: response

---
 doc/todo/matching_different_kinds_of_links.mdwn | 7 +++++++
 1 file changed, 7 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 4f52ade52..2cd484852 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -104,6 +104,8 @@ Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
 > Oops, I'll fix that. That must mean missing test coverage, too :-(
 > --s
 
+>> A test suite for the dependency resolver *would* be nice. --[[Joey]]
+
 I'm curious what your reasoning was for adding a new variable
 rather than using `pagestate`. Was it only because you needed
 the `old` version to detect change, or was there other complexity?
@@ -133,6 +135,8 @@ with a empty type. (Bloaty.)) --J
 > not counting tags and other typed links?". A typed link is
 > still a link, in my mind at least. --s
 
+>> Me neither, let's not worry about it. --[[Joey]] 
+
 I suspect we could get away without having `tagged_is_strict`
 without too much transitional trouble. --[[Joey]]
 
@@ -149,3 +153,6 @@ to set that link type, and its own pagespec function to match it.
 I wonder whether to make a `typedlink` plugin that has the typedlink
 pagespec match function and a new `\[[!typedlink to="foo" type="bar"]]`
 though... --[[smcv]]
+
+> I agree, per-type matchers are more friendly and I'm not enamored of the
+> multi-parameter pagespec syntax. --[[Joey]]
-- 
cgit v1.2.3


From 931c7b00ccb47371ee6e1d56baf5c52d725a321f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 22:46:31 -0400
Subject: response

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 25 +++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e79e52f39..c6e18505e 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -38,7 +38,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
 >>>>> a bit like a pagespec :-) Which name would you prefer? --s
 
->>>> I would be inclined to drop the `check_` stuff. --J
+>>>>>> `SortSpec` --[[Joey]] 
+
+>>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
 >>>>> It basically exists to support `title_natural`, to avoid
 >>>>> firing up the whole import mechanism on every `cmp`
@@ -48,6 +50,11 @@ That earlier version of the branch is also available for comparison:
 >>>>> [[field|plugins/contrib/field/discussion]], fail early
 >>>>> (again, not so valuable).
 >>>>>
+>>>>>> AFAIK, `use foo` has very low overhead when the module is already
+>>>>>> loaded. There could be some evalation overhead in `eval q{use foo}`,
+>>>>>> if so it would be worth addressing across the whole codebase.
+>>>>>> --[[Joey]] 
+>>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
 >>>>> `sortnatural` plugin (that fails to load if you don't
@@ -55,8 +62,12 @@ That earlier version of the branch is also available for comparison:
 >>>>> have happened if `title_natural` was written after this
 >>>>> code had been merged, I suspect. Would you prefer this? --s
 
+>>>>>> Yes! (Assuming it does not make sense to support
+>>>>>> natural order sort of other keys than the title, at least..)
+>>>>>>  --[[Joey]]
+
 >>>> Wouldn't it make sense to have `meta(title)` instead
->>>> of `meta_title`? --J
+>>>> of `meta_title`? --[[Joey]]
 
 >>>>> Yes, you're right. I added parameters to support `field`,
 >>>>> and didn't think about making `meta` use them too.
@@ -77,10 +88,12 @@ That earlier version of the branch is also available for comparison:
 >>>>> same place as the meta-title, but occasionally not), while
 >>>>> displaying meta-titles, does look quite odd. --s
 
+>>>>>> Agreed. --[[Joey]]
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
->>>> do not need parameters. --J
+>>>> do not need parameters. --[[Joey]]
 
 >>>>> No, `$2` is either `\w+\([^\)]*\)` or `[^\s]+` (with the
 >>>>> latter causing an error later if it doesn't also match `\w+`).
@@ -122,6 +135,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> result. Again, I think this is getting too complex, and could just
 >>>>> be solved with smarter cmp functions.
 >>>>>
+>>>>>> I agree. (Also, I think returning keys may make it harder to write
+>>>>>> smarter cmp functions.) --[[Joey]] 
+>>>>>
 >>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
 >>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
 >>>>> now minus `ctime`). `sort=freshness` isn't right either, because
@@ -132,6 +148,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> directions - it seems clearer to have `ascending` always be a no-op,
 >>>>> and `descending` always negate.
 >>>>>
+>>>>>> I think you've convinced me that ascending/descending impose too
+>>>>>> much semantics on it, so "-" is better. --[[Joey]]
+>>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
 >>>>> makes me think that updateage is a quantity analagous to tonnage or
-- 
cgit v1.2.3


From 56c64ff1963b33da74677f08a0b8c6579bc2d68b Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 13:39:44 +0000
Subject: updated branch

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 56 +++++++++++++++-------
 1 file changed, 38 insertions(+), 18 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index c6e18505e..8c6e1df3b 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -40,6 +40,8 @@ That earlier version of the branch is also available for comparison:
 
 >>>>>> `SortSpec` --[[Joey]] 
 
+>>>>>>> Done. --s
+
 >>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
 >>>>> It basically exists to support `title_natural`, to avoid
@@ -54,6 +56,8 @@ That earlier version of the branch is also available for comparison:
 >>>>>> loaded. There could be some evalation overhead in `eval q{use foo}`,
 >>>>>> if so it would be worth addressing across the whole codebase.
 >>>>>> --[[Joey]] 
+>>>>>>
+>>>>>>> check_cmp_foo now dropped. --s
 >>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
@@ -66,6 +70,8 @@ That earlier version of the branch is also available for comparison:
 >>>>>> natural order sort of other keys than the title, at least..)
 >>>>>>  --[[Joey]]
 
+>>>>>>> Done. I added some NEWS.Debian for it, too. --s
+
 >>>> Wouldn't it make sense to have `meta(title)` instead
 >>>> of `meta_title`? --[[Joey]]
 
@@ -90,6 +96,11 @@ That earlier version of the branch is also available for comparison:
 
 >>>>>> Agreed. --[[Joey]]
 
+>>>>>>> I've implemented meta(title). meta(author) also has the
+>>>>>>> `sortas` special case; meta(updated) and meta(date)
+>>>>>>> should also work how you'd expect them to (but they're
+>>>>>>> earliest-first, unlike age). --s
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
@@ -150,6 +161,10 @@ That earlier version of the branch is also available for comparison:
 >>>>>
 >>>>>> I think you've convinced me that ascending/descending impose too
 >>>>>> much semantics on it, so "-" is better. --[[Joey]]
+
+>>>>>>> I've kept the semantics from `report` as-is, then:
+>>>>>>> e.g. `sort="age -title"`. --s
+
 >>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
@@ -160,18 +175,22 @@ That earlier version of the branch is also available for comparison:
 >>>>> I'm sure there's a much better word, but I can't see it. Do you have
 >>>>> a better idea? --s
 
-## Documentation from sort-package branch
+[Regarding the `meta title=foo sort=bar` special case]
 
-### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
+> I feel it sould be clearer to call that "sortas", since "sort=" is used
+> to specify a sort method in other directives. --[[Joey]]
+>> Done. --[[smcv]]
 
-* `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]`
-  or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
-  full title was set.
+## Documentation from sort-package branch
 
-  > I feel it sould be clearer to call that "sortas", since "sort=" is used
-  > to specify a sort method in other directives. --[[Joey]]
+### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
 
-  >> Fair enough, that's easy to do. --[[smcv]]
+* `title_natural` - Orders by title, but numbers in the title are treated
+  as such, ("1 2 9 10 20" instead of "1 10 2 20 9")
+* `meta(title)` - Order according to the `\[[!meta title="foo" sortas="bar"]]`
+  or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
+  full title was set. `meta(author)`, `meta(date)`, `meta(updated)`, etc.
+  also work.
 
 ### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
 
@@ -179,23 +198,29 @@ In addition, you can combine several sort orders and/or reverse the order of
 sorting, with a string like `age -title` (which would sort by age, then by
 title in reverse order if two pages have the same age).
 
-### meta title sort parameter (added to [[ikiwiki/directive/meta]])
+### meta sortas parameter (added to [[ikiwiki/directive/meta]])
+
+[in title]
 
 An optional `sort` parameter will be used preferentially when
-[[ikiwiki/pagespec/sorting]] by `meta_title`:
+[[ikiwiki/pagespec/sorting]] by `meta(title)`:
 
        \[[!meta title="The Beatles" sort="Beatles, The"]]
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
-> I now realise that `author` should also have this, again for use
-> with (Western) names. --s
+[in author]
+
+  An optional `sortas` parameter will be used preferentially when
+  [[ikiwiki/pagespec/sorting]] by `meta(author)`:
+
+        \[[!meta author="Joey Hess" sortas="Hess, Joey"]]
 
 ### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as
 [[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to
-the IkiWiki::PageSpec package named `cmp_foo`, which will be used when sorting
+the IkiWiki::SortSpec package named `cmp_foo`, which will be used when sorting
 by `foo` or `foo(...)` is requested.
 
 The function will be passed three or more parameters. The first two are
@@ -208,8 +233,3 @@ if the first argument is less than the second, positive if the first argument
 is greater, or zero if they are considered equal. It may also raise an
 error using `error`, for instance if it needs a parameter but one isn't
 provided.
-
-You can also define a function called `check_cmp_foo` in the same package.
-If you do, it will be called while preparing to sort by `foo` or `foo(bar)`,
-with argument `undef` or `"bar"` respectively; it may raise an error using
-`error`, if sorting like that isn't going to work.
-- 
cgit v1.2.3


From 36202d461f86bb3869444cf161d9bfe62298b8f8 Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 5 Feb 2010 12:54:07 +0100
Subject: link to commits

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index a0e76fd48..c4a92824b 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -165,7 +165,7 @@ wrong direction.
 > optimised, and security-sensitive ground, so I have to look at them very
 > carefully. --[[Joey]]
 > 
-> * In the refactoring in f3abeac919c4736429bd3362af6edf51ede8e7fe,
+> * In the refactoring in [f3abeac919c4736429bd3362af6edf51ede8e7fe][],
 >   you introduced at least 2 bugs, one a possible security hole.
 >   Now one part of the code tests `if ($file)` and the other
 >   caller tests `if ($f)`. These two tests both tested `if (! defined $f)`
@@ -181,14 +181,18 @@ wrong direction.
 > I'd like to cherry-pick the above commit, once it's in shape, before
 > looking at the rest in detail. So just a few other things that stood out.
 > 
-> * Commit 4af4d26582f0c2b915d7102fb4a604b176385748 seems unnecessary.
+> * Commit [4af4d26582f0c2b915d7102fb4a604b176385748][] seems unnecessary.
 >   `srcfile($file, 1)` already is documented to return undef if the
 >   file does not exist. (But without the second parameter, it throws
 >   an error.)
 >
-> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 adds a line
+> * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] adds a line
 >   that is intented by a space, not a tab.
 > 
-> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 says that auto-added
+> * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] says that auto-added
 >   files will be recreated if the user deletes them. That seems bad.
 >   `autoindex` goes to some trouble to not recreate deleted files.
+
+[f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
+[4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
+[f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From 129bea3177b59be8ed4cc303720c8747f59a11ba Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Sat, 3 Apr 2010 23:38:05 +0200
Subject: answer about autofiles for tags

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 29 +++++++++++++++++++---
 1 file changed, 25 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index c4a92824b..07b570b1b 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -164,7 +164,11 @@ wrong direction.
 > Starting review of this. Some of your commits are to very delicate,
 > optimised, and security-sensitive ground, so I have to look at them very
 > carefully. --[[Joey]]
-> 
+
+>> First of, sorry that it took me so damn long to answer. I didn't lose
+>> interest but it took a while for me to find the time and motivation
+>> to address you suggestions. --[[David_Riebenbauer]]
+
 > * In the refactoring in [f3abeac919c4736429bd3362af6edf51ede8e7fe][],
 >   you introduced at least 2 bugs, one a possible security hole.
 >   Now one part of the code tests `if ($file)` and the other
@@ -177,7 +181,11 @@ wrong direction.
 >   bare `_` in the first to make perl reuse the stat buffer.
 > * (As a matter of style, could you put a space after the commas in your
 >   perl?)
-> 
+
+>> The first two points should be addressed in
+>> [da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0][]. And sure, I can add the
+>> spaces. --[[David_Riebenbauer]]
+
 > I'd like to cherry-pick the above commit, once it's in shape, before
 > looking at the rest in detail. So just a few other things that stood out.
 > 
@@ -185,14 +193,27 @@ wrong direction.
 >   `srcfile($file, 1)` already is documented to return undef if the
 >   file does not exist. (But without the second parameter, it throws
 >   an error.)
->
+
+>> You're right. I must have been some confused by some other promplem I
+>> introduced then. Reverted. --[[David_Riebenbauer]]
+
 > * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] adds a line
 >   that is intented by a space, not a tab.
-> 
+
+>> Sorry, That one was reverted anyway. --[[David_Riebenbauer]]
+
 > * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] says that auto-added
 >   files will be recreated if the user deletes them. That seems bad.
 >   `autoindex` goes to some trouble to not recreate deleted files.
 
+>> I reverted the commit and addressed the issue in
+>> [a358d74bef51dae31332ff27e897fe04834571e6][] and
+>> [981400177d68a279f485727be3f013e68f0bf691][].
+ --[[David_Riebenbauer]]
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
+[da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0 (commitdiff for da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0)
+[a358d74bef51dae31332ff27e897fe04834571e6]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=a358d74bef51dae31332ff27e897fe04834571e6 (commitdiff for a358d74bef51dae31332ff27e897fe04834571e6)
+[981400177d68a279f485727be3f013e68f0bf691]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=981400177d68a279f485727be3f013e68f0bf691 (commitdiff for 981400177d68a279f485727be3f013e68f0bf691)
-- 
cgit v1.2.3


From 61a31a3d63a19f75e3362c7e5ac2067f572c9dca Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sun, 4 Apr 2010 00:34:36 +0000
Subject: updated branch

---
 doc/todo/matching_different_kinds_of_links.mdwn | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 2cd484852..c4383c0b7 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -106,6 +106,10 @@ Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
 
 >> A test suite for the dependency resolver *would* be nice. --[[Joey]]
 
+>>> Bug fixed, I think. A test suite for the dependency resolver seems
+>>> more ambitious than I want to get into right now, but I added a
+>>> unit test for this part of it... --s
+
 I'm curious what your reasoning was for adding a new variable
 rather than using `pagestate`. Was it only because you needed
 the `old` version to detect change, or was there other complexity?
@@ -120,6 +124,17 @@ the `old` version to detect change, or was there other complexity?
 > my docs for `%typedlinks`, so I'll try to write docs for it as
 > `pagestate` and see if they work any better. --s
 
+>> On reflection, I don't think it's any better as a pagestate, and
+>> the contents of pagestates (so far) aren't documented for other
+>> plugins' consumption, so I'm inclined to leave it as-is, unless
+>> you want to veto that. Loose rationale: it needs special handling
+>> in the core to be a dependency type (I re-used the existing link
+>> type), it's API beyond a single plugin, and it's really part of
+>> the core parallel to pagestate rather than being tied to a
+>> specific plugin. Also, I'd need to special-case it to have
+>> ikiwiki not delete it from the index, unless I introduced a
+>> dummy typedlinks plugin (or just hook) that did nothing... --s
+
 I have not convinced myself this is a real problem, but..
 If a page has a typed link, there seems to be no way to tell
 if it also has a separate, regular link. `add_link` will add
@@ -145,6 +160,8 @@ without too much transitional trouble. --[[Joey]]
 > on the current semantics, on one of the pages requesting this
 > change. --s
 
+>> Removed in a newer version of the branch. --s
+
 I might have been wrong to introduce `typedlink(tag foo)`. It's not
 very user-friendly, and is more useful as a backend for other plugins
 that as a feature in its own right - any plugin introducing a link
@@ -156,3 +173,6 @@ though... --[[smcv]]
 
 > I agree, per-type matchers are more friendly and I'm not enamored of the
 > multi-parameter pagespec syntax. --[[Joey]]
+
+>> Removed in a newer version of the branch. I re-introduced it as a
+>> plugin in `smcv/typedlink`, but I don't think we really need it. --s
-- 
cgit v1.2.3


From b51703569d35790f31dccc3dc2921e8bcccd5b49 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 5 Apr 2010 14:59:29 -0400
Subject: speed

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 8c6e1df3b..739a3d6b0 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -181,6 +181,20 @@ That earlier version of the branch is also available for comparison:
 > to specify a sort method in other directives. --[[Joey]]
 >> Done. --[[smcv]]
 
+## speed
+
+I notice the implementation does not use the magic `$a` and `$b` globals.
+That nasty perl optimisation is still worthwhile:
+
+	perl -e 'use warnings; use strict; use Benchmark; sub a { $a <=> $b } sub b ($$) { $_[0] <=> $_[1] }; my @list=reverse(1..9999); timethese(10000, {a => sub {my @f=sort a @list}, b => sub {my @f=sort b  @list}, c => => sub {my @f=sort { b($a,$b) } @list}})'
+	Benchmark: timing 10000 iterations of a, b, c...
+	         a: 80 wallclock secs (76.74 usr +  0.05 sys = 76.79 CPU) @ 130.23/s (n=10000)
+	         b: 112 wallclock secs (106.14 usr +  0.20 sys = 106.34 CPU) @ 94.04/s (n=10000)
+                 c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
+
+Unfortunatly, I think that c is closest to the new implementation.
+--[[Joey]]
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
-- 
cgit v1.2.3


From 861080b918ef71d82f4a4b9a22093f4a379b5ef8 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Mon, 5 Apr 2010 19:19:00 +0000
Subject: potential performance improvements

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 739a3d6b0..2ce1de6a4 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -195,6 +195,28 @@ That nasty perl optimisation is still worthwhile:
 Unfortunatly, I think that c is closest to the new implementation.
 --[[Joey]]
 
+> Unfortunately, `$a` isn't always `$main::a` - it's `$Package::a` where
+> `Package` is the call site of the sort call. This was a showstopper when
+> `sort` was a hook implemented in many packages, but now that it's a
+> `SortSpec`, I may be able to fix this by putting a `sort` wrapper in the
+> `SortSpec` namespace, so it's like this:
+>
+>     sub sort ($@)
+>     {
+>         my $cmp = shift;
+>         return sort $cmp @_;
+>     }
+>
+> which would mean that the comparison used `$IkiWiki::SortSpec::a`.
+>
+> I do notice that `pagespec_match_list` performs the sort before the
+> filter by pagespec. Is this a deliberate design choice, or
+> coincidence? I can see that when `limit` is used, this could be
+> used to only run the pagespec match function until `limit` pages
+> have been selected, but the cost is that every page in the wiki
+> is sorted. Or, it might be useful to do the filtering first, then
+> sort the sub-list thus produced, then finally apply the limit? --s
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
-- 
cgit v1.2.3


From 10f4695abd65db6c009864c5abb7cb5dfa1cf153 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 5 Apr 2010 15:28:54 -0400
Subject: response

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 2ce1de6a4..0aca74be2 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -165,7 +165,6 @@ That earlier version of the branch is also available for comparison:
 >>>>>>> I've kept the semantics from `report` as-is, then:
 >>>>>>> e.g. `sort="age -title"`. --s
 
->>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
 >>>>> makes me think that updateage is a quantity analagous to tonnage or
@@ -190,7 +189,7 @@ That nasty perl optimisation is still worthwhile:
 	Benchmark: timing 10000 iterations of a, b, c...
 	         a: 80 wallclock secs (76.74 usr +  0.05 sys = 76.79 CPU) @ 130.23/s (n=10000)
 	         b: 112 wallclock secs (106.14 usr +  0.20 sys = 106.34 CPU) @ 94.04/s (n=10000)
-                 c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
+	         c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
 
 Unfortunatly, I think that c is closest to the new implementation.
 --[[Joey]]
@@ -217,6 +216,10 @@ Unfortunatly, I think that c is closest to the new implementation.
 > is sorted. Or, it might be useful to do the filtering first, then
 > sort the sub-list thus produced, then finally apply the limit? --s
 
+>> Yes, it was deliberate, pagespec matching can be expensive enough that
+>> needing to sort a lot of pages seems likely to be less work. (I don't
+>> remember what benchmarking was done though.) --[[Joey]] 
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
-- 
cgit v1.2.3


From b186ec1b4cb8145d6a6cb68478e23d7fb0fa1476 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 6 Apr 2010 00:02:18 +0000
Subject: ready for review, I think

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 51 +++++++++++++++++-----
 1 file changed, 39 insertions(+), 12 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 0aca74be2..d4da13feb 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -20,7 +20,7 @@ That earlier version of the branch is also available for comparison:
 
 >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
 
->>> [[!template id=gitbranch branch=smcv/sort-package author="[[Simon_McVittie|smcv]]"]]
+>>> [[!template id=gitbranch branch=smcv/ready/sort-package author="[[Simon_McVittie|smcv]]"]]
 >>> I'd be inclined to think that's overkill, but it wasn't very hard to
 >>> implement, and in a way is more elegant. I set it up so sort mechanisms
 >>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
@@ -207,7 +207,26 @@ Unfortunatly, I think that c is closest to the new implementation.
 >     }
 >
 > which would mean that the comparison used `$IkiWiki::SortSpec::a`.
->
+> --s
+
+>> I've now done this. On a wiki with many [[plugins/contrib/album]]s
+>> (a full rebuild takes half an hour!), I tested a refresh after
+>> `touch tags/*.mdwn` (my tag pages contain inlines of the form
+>> `tagged(foo)` sorted by date, so they exercise sorting).
+>> I also tried removing sorting from `pagespec_match_list`
+>> altogether, as an upper bound for how fast we can possibly make it.
+>>
+>> * `master` at branch point: 63.72user 0.29system
+>> * `master` at branch point: 63.91user 0.37system
+>> * my branch, with `@_`: 65.28user 0.29system
+>> * my branch, with `@_`: 65.21user 0.28system
+>> * my branch, with `$a`: 64.09user 0.28system
+>> * my branch, with `$a`: 63.83user 0.36system
+>> * not sorted at all: 58.99user 0.29system
+>> * not sorted at all: 58.92user 0.29system
+>>
+>> --s
+
 > I do notice that `pagespec_match_list` performs the sort before the
 > filter by pagespec. Is this a deliberate design choice, or
 > coincidence? I can see that when `limit` is used, this could be
@@ -218,7 +237,15 @@ Unfortunatly, I think that c is closest to the new implementation.
 
 >> Yes, it was deliberate, pagespec matching can be expensive enough that
 >> needing to sort a lot of pages seems likely to be less work. (I don't
->> remember what benchmarking was done though.) --[[Joey]] 
+>> remember what benchmarking was done though.) --[[Joey]]
+
+>>> We discussed this on IRC and Joey pointed out that this also affects
+>>> dependency calculation, so I'm not going to get into this now... --s
+
+Joey pointed out on IRC that the `titlesort` feature duplicates all the
+meta titles. I did that in order to sort by the unescaped version, but
+I've now changed the branch to only store that if it makes a difference.
+--s
 
 ## Documentation from sort-package branch
 
@@ -262,13 +289,13 @@ Similarly, it's possible to write plugins that add new functions as
 the IkiWiki::SortSpec package named `cmp_foo`, which will be used when sorting
 by `foo` or `foo(...)` is requested.
 
-The function will be passed three or more parameters. The first two are
-page names, and the third is `undef` if invoked as `foo`, or the parameter
-`"bar"` if invoked as `foo(bar)`. It may also be passed additional, named
-parameters.
+The names of pages to be compared are in the global variables `$a` and `$b`
+in the IkiWiki::SortSpec package. The function should return the same thing
+as Perl's `cmp` and `<=>` operators: negative if `$a` is less than `$b`,
+positive if `$a` is greater, or zero if they are considered equal. It may
+also raise an error using `error`, for instance if it needs a parameter but
+one isn't provided.
 
-It should return the same thing as Perl's `cmp` and `<=>` operators: negative
-if the first argument is less than the second, positive if the first argument
-is greater, or zero if they are considered equal. It may also raise an
-error using `error`, for instance if it needs a parameter but one isn't
-provided.
+The function will also be passed one or more parameters. The first is
+`undef` if invoked as `foo`, or the parameter `"bar"` if invoked as `foo(bar)`;
+it may also be passed additional, named parameters.
-- 
cgit v1.2.3


From 1fb5b9f61c114a0151416d2de69b5ea420c6706b Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 6 Apr 2010 00:04:47 +0000
Subject: switch branch for review to use ready/foo convention

---
 doc/todo/matching_different_kinds_of_links.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index c4383c0b7..5678ee7e2 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -53,7 +53,7 @@ I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
 
 -------
 
->> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/link-types]]
+>> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/ready/link-types]]
 >> [[!tag patch]]
 
 ## Documentation for smcv's branch
-- 
cgit v1.2.3


From ee1e7079ebe0a1e9d3d6c79cb221a0fb86f423d5 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 6 Apr 2010 04:41:55 +0000
Subject: more flexible underlays, please?

---
 doc/todo/optional_underlaydir_prefix.mdwn | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 doc/todo/optional_underlaydir_prefix.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
new file mode 100644
index 000000000..8fd6d76c5
--- /dev/null
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -0,0 +1,20 @@
+For security reasons, symlinks are disabled in IkiWiki.  That's fair enough, but that means that some problems, which one could otherwise solve by using a symlink, cannot be solved. The specfic problem in this case is that all underlays are placed at the root of the wiki, when it could be more convenient to place some underlays in specific sub-directories.
+
+Use-case 1 (to keep things tidy):
+
+Currently IkiWiki has some javascript files in `underlays/javascript`; that directory is given as one of the underlay directories.  Thus, all the javascript files appear in the root of the generated site.  But it would be tidier if one could say "put the contents of *this* underlaydir under the `js` directory".
+
+Use-case 2 (a read-only external dir):
+
+Suppose I want to include a subset of `/usr/local/share/docs` on my wiki, say the docs about `foo`.  But I want them to be under the `docs/foo` sub-directory on the generated site.  Currently I can't do that.  If I give `/usr/local/share/docs/foo` as an underlaydir, then the contents of that will be in the root of the site, rather than under `docs/foo`.  And if I give `/usr/local/share/docs` as an underlaydir, then the contents of the `foo` dir will be under `foo`, but it will also include every other thing in `/usr/local/share/docs`.
+
+Since we can't use symlinks in an underlay dir to link to these directories, then perhaps one could give a specific underlay dir a specific prefix, which defines the sub-directory that the underlay should appear in.
+
+I'm not sure how this would be implemented, but I guess it could be configured something like this:
+
+    prefixed_underlay => {
+         'js' => '/usr/local/share/ikiwiki/javascript',
+         'docs/foo' => '/usr/local/share/docs/foo',
+    }
+
+[[!taglink wishlist]]
-- 
cgit v1.2.3


From c87ddb6908485fecff9c516223ca0b2973df88f6 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 13:58:55 -0400
Subject: idea

---
 doc/todo/optional_underlaydir_prefix.mdwn | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
index 8fd6d76c5..dd11d062d 100644
--- a/doc/todo/optional_underlaydir_prefix.mdwn
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -4,6 +4,9 @@ Use-case 1 (to keep things tidy):
 
 Currently IkiWiki has some javascript files in `underlays/javascript`; that directory is given as one of the underlay directories.  Thus, all the javascript files appear in the root of the generated site.  But it would be tidier if one could say "put the contents of *this* underlaydir under the `js` directory".
 
+> Of course, this could be accomplished, if we wanted to, by moving the
+> files to `underlays/javascript/js`. --[[Joey]] 
+
 Use-case 2 (a read-only external dir):
 
 Suppose I want to include a subset of `/usr/local/share/docs` on my wiki, say the docs about `foo`.  But I want them to be under the `docs/foo` sub-directory on the generated site.  Currently I can't do that.  If I give `/usr/local/share/docs/foo` as an underlaydir, then the contents of that will be in the root of the site, rather than under `docs/foo`.  And if I give `/usr/local/share/docs` as an underlaydir, then the contents of the `foo` dir will be under `foo`, but it will also include every other thing in `/usr/local/share/docs`.
@@ -17,4 +20,25 @@ I'm not sure how this would be implemented, but I guess it could be configured s
          'docs/foo' => '/usr/local/share/docs/foo',
     }
 
+> So, let me review why symlinks are an issue. For normal, non-underlay
+> pages, users who do not have filesystem access to the server may have 
+> commit access, and so could commit eg, a symlink to `/etc/passwd` (or
+> to `/` !). The guards are there to prevent ikiwiki either exposing the
+> symlink target's contents, or potentially overwriting it.
+> 
+> Is this a concern for underlays? Most of the time, certianly not;
+> the underlay tends to be something only the site admin controls.
+> Not all the security checks that are done on the srcdir are done
+> on the underlays, either. Most checks done on files in the underlay
+> are only done because the same code handles srcdir files. The one
+> exception is the test that skips processing symlinks in the underlay dir.
+> (But note that the underlay directory can be a symlinkt to elsewhere
+> which the srcdir, by default, cannot.)
+> 
+> So, one way to approach this is to make ikiwiki follow directory symlinks
+> inside the underlay directory. Just a matter of passing `follow => 1` to
+> find. (This would still not allow individual files to be symlinks, because
+> `readfile` does not allow reading symlinks. But I don't see much need
+> for that.) --[[Joey]]
+
 [[!taglink wishlist]]
-- 
cgit v1.2.3


From 407a3493599afbb2f16a0ace49ff1924997895d2 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 14:20:44 -0400
Subject: nearly there!

---
 doc/todo/matching_different_kinds_of_links.mdwn | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 5678ee7e2..76a99f6a5 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -176,3 +176,15 @@ though... --[[smcv]]
 
 >> Removed in a newer version of the branch. I re-introduced it as a
 >> plugin in `smcv/typedlink`, but I don't think we really need it. --s
+
+----
+
+I am ready to merge this, but I noticed one problem -- since `match_tagged`
+now only matches pages with the tag linktype, a wiki will need to be
+rebuilt on upgrade in order to get the linktype of existing tags in it
+recorded. So there needs to be a NEWS item about this and
+the postinst modified to force the rebuild.
+
+Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
+but you removed that feature as documented above.
+--[[Joey]]
-- 
cgit v1.2.3


From 899639f10d49cff410059c3af2e1d5717c25b738 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 6 Apr 2010 20:03:26 +0000
Subject: fixed

---
 doc/todo/matching_different_kinds_of_links.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 76a99f6a5..8e81860a1 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -185,6 +185,12 @@ rebuilt on upgrade in order to get the linktype of existing tags in it
 recorded. So there needs to be a NEWS item about this and
 the postinst modified to force the rebuild.
 
+> Done, although you'll need to plug in an appropriate version number when
+> you release it. Is there a distinctive reminder string you grep for
+> during releases? I've used `UNRELEASED` for now. --[[smcv]]
+
 Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
 but you removed that feature as documented above.
 --[[Joey]]
+
+> Done. --s
-- 
cgit v1.2.3


From 811d398646337717f8f2ad92897c6410faa42777 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 6 Apr 2010 23:20:49 +0000
Subject: response

---
 doc/todo/optional_underlaydir_prefix.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
index dd11d062d..06900a904 100644
--- a/doc/todo/optional_underlaydir_prefix.mdwn
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -41,4 +41,6 @@ I'm not sure how this would be implemented, but I guess it could be configured s
 > `readfile` does not allow reading symlinks. But I don't see much need
 > for that.) --[[Joey]]
 
+>> If you think that enabling symlinks in underlay directories wouldn't be a security issue, then I'm all for it!  That would be much simpler to implement, I'm sure. --[[KathrynAndersen]]
+
 [[!taglink wishlist]]
-- 
cgit v1.2.3


From fcd810d236fdf779beb740082953a14feba07f0d Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 23:04:54 -0400
Subject: close

---
 doc/todo/matching_different_kinds_of_links.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 8e81860a1..da3ea49f6 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -193,4 +193,4 @@ Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
 but you removed that feature as documented above.
 --[[Joey]]
 
-> Done. --s
+> [[Done]]. --s
-- 
cgit v1.2.3


From dad7ac5a21bc049b9f559c98f4e113c99edb4eb5 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 23:24:22 -0400
Subject: question

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index d4da13feb..d7f10528a 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -10,6 +10,9 @@ title over the page name, but for compatibility, I'm not going to (I do wonder
 whether it would be worth making sort=name an alias for the current sort=title,
 and changing the meaning of sort=title in 4.0, though).
 
+> What compatability concerns, exactly, are there that prevent making that
+> change now? --[[Joey]] 
+
 *[sort-hooks branch now withdrawn in favour of sort-package --s]*
 
 I briefly tried to turn *all* the current sort types into hook functions, and
-- 
cgit v1.2.3


From 32ce94f5a30e52da17f06b9b9dce7f3d3112da98 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 23:30:10 -0400
Subject: close (but one question remains!)

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index d7f10528a..b523cd19f 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -43,7 +43,7 @@ That earlier version of the branch is also available for comparison:
 
 >>>>>> `SortSpec` --[[Joey]] 
 
->>>>>>> Done. --s
+>>>>>>> [[Done]]. --s
 
 >>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
-- 
cgit v1.2.3


From c127e964f1704a6704639350851afee722825529 Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Wed, 7 Apr 2010 21:25:26 +0100
Subject: expand my response

---
 doc/todo/allow_site-wide_meta_definitions.mdwn | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 7129a44ac..82670250e 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -217,6 +217,16 @@ definitions essentially.
 
 >>> For this to work with websetup and --dumpsetup, it needs to define the
 >>> `meta_*` settings in the getsetup function.
+>>>> 
+>>>> I think this will be problematic with the current implementation of this
+>>>> patch. The datatype here is an array of hash references, with each hash
+>>>> having a variable (and arbitrary) number of key/value pairs.  I can't
+>>>> think of an intuitive way of implementing a way of editing such a
+>>>> datatype in the web interface, let alone registering the option in
+>>>> getsetup.
+>>>> 
+>>>> Perhaps a limited set of defined meta values could be exposed via
+>>>> websetup (the obvious ones: author, copyright, license, etc.) -- [[Jon]]
 >>>
 >>> I also have some concerns about both these patches, since both throw
 >>> a lot of redundant data at meta, which then stores it in a very redundant
@@ -232,6 +242,5 @@ definitions essentially.
 >>> meta special-case the site-wide settings, not store them in these
 >>> per-page data structures, and just make them be used if no per-page
 >>> metadata of the given type is present. --[[Joey]]
-
->>>> Thanks for the review - these are all valid points. I'll get working
->>>> on a revised patch. -- [[Jon]]
+>>>> 
+>>>> that should be easy enough to do. I will work on a patch. -- [[Jon]]
-- 
cgit v1.2.3


From a8761a086ebf353192e4721090ff11d3f67707b6 Mon Sep 17 00:00:00 2001
From: Cord 
Date: Sat, 10 Apr 2010 07:06:06 +0000
Subject:

---
 doc/todo/More_flexible_po-plugin_for_translation.mdwn | 5 +++++
 1 file changed, 5 insertions(+)
 create mode 100644 doc/todo/More_flexible_po-plugin_for_translation.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/More_flexible_po-plugin_for_translation.mdwn b/doc/todo/More_flexible_po-plugin_for_translation.mdwn
new file mode 100644
index 000000000..3399f7834
--- /dev/null
+++ b/doc/todo/More_flexible_po-plugin_for_translation.mdwn
@@ -0,0 +1,5 @@
+I have a website with multi-language content, where some content is only in English, some in German, and some is available in both languages.
+
+The po-module currently has only one master-language, with slave languages, and a  PageSpec should be considered.
+
+It would be nice to flag the content which should have a translation on a file-by-file basis (with some inline directive?) which could contain the information of the master-language for that file and the desired target-languages.
-- 
cgit v1.2.3


From cecbd529389788c1f1cb647e2ff297cda7554456 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 11 Apr 2010 00:30:27 -0400
Subject: plan for more efficient pagespec_match_list sorting

(smcv please note)
---
 doc/todo/smarter_sorting.mdwn | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 doc/todo/smarter_sorting.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
new file mode 100644
index 000000000..5a6d63ef1
--- /dev/null
+++ b/doc/todo/smarter_sorting.mdwn
@@ -0,0 +1,33 @@
+I benchmarked a build of a large wiki (my home wiki), and it was spending
+quite a lot of time sorting; `CORE::sort` was called only 1138 times, but
+still flagged as the #1 time sink. (I'm not sure I trust NYTProf fully
+about that FWIW, since it also said 27238263 calls to `cmp_age` were
+the #3 timesink, and I suspect it may not entirely accurately measure
+the overhead of so many short function calls.)
+
+`pagespec_match_list` currently always sorts *all* pages first, and then
+finds the top M that match the pagespec. That's innefficient when M is
+small (as for example in a typical blog, where only 20 posts are shown,
+out of maybe thousands).
+
+As [[smcv]] noted, It could be flipped, so the pagespec is applied first,
+and then sort the smaller matching set. But, checking pagespecs is likely
+more expensive than sorting. (Also, influence calculation complicates
+doing that, since only influences for the M returned pages should be tracked.)
+
+Another option, when there is a limit on M pages to return, might be to
+cull the M top pages without sorting the rest. This could be done using
+a variant of Ye Olde Bubble Sort. Take the first M pages, and (quick)sort.
+Then for each of the rest, check if it is higher than the Mth page.
+If it is, bubble it up so it's sorted.
+If not, throw it out (that's the fast bit and why this is not O(N^2)).
+
+This would be bad when M is very large, and particularly, of course, when
+there is no limit and all pages are being matched on. (For example, an
+archive page shows all pages that match a pagespec specifying a creation
+date range.) Well, in this case, it *does* make sense to flip it, limit by
+pagespe first, and do a (quick)sort second. (No influence complications,
+either.)
+
+Adding these special cases will be more complicated, but I think the best
+of both worlds. --[[Joey]]
-- 
cgit v1.2.3


From 0bfc364a7df124509855b8ed0b1b33ab5bc9ebbb Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 11 Apr 2010 01:30:03 -0400
Subject: optimization: pagespec_match_list with no num limit matches before
 sorting

This can be a lot faster, since huge numbers of pages are not sorted
only to mostly be thrown away. It sped up a build of my blog by at least
5 minutes.
---
 IkiWiki.pm                    | 38 ++++++++++++++++++++++++++------------
 doc/todo/smarter_sorting.mdwn |  3 +++
 t/pagespec_match_list.t       |  6 +++++-
 3 files changed, 34 insertions(+), 13 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki.pm b/IkiWiki.pm
index 2cad6a3ef..74d452c50 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -1951,8 +1951,9 @@ sub add_link ($$;$) {
 	}
 }
 
-sub sortspec_translate ($) {
+sub sortspec_translate ($$) {
 	my $spec = shift;
+	my $reverse = shift;
 
 	my $code = "";
 	my @data;
@@ -2007,6 +2008,10 @@ sub sortspec_translate ($) {
 		return sub { 0 };
 	}
 
+	if ($reverse) {
+		$code="-($code)";
+	}
+
 	no warnings;
 	return eval 'sub { '.$code.' }';
 }
@@ -2109,18 +2114,20 @@ sub pagespec_match_list ($$;@) {
 			? grep { ! $params{filter}->($_) } keys %pagesources
 			: keys %pagesources;
 	}
-
-	if (defined $params{sort}) {
-		@candidates = IkiWiki::SortSpec::sort_pages($params{sort},
-			@candidates);
+	
+	my $num=$params{num};
+	my $sort=$params{sort};
+	my $reverse=$params{reverse};
+	# when only the top matches will be returned, it's efficient to
+	# sort before matching to pagespec,
+	if (defined $num && defined $sort) {
+		@candidates=IkiWiki::SortSpec::sort_pages(
+			$sort, $reverse, @candidates);
 	}
-
-	@candidates=reverse(@candidates) if $params{reverse};
 	
 	$depends{$page}{$pagespec} |= ($params{deptype} || $DEPEND_CONTENT);
 	
 	# clear params, remainder is passed to pagespec
-	my $num=$params{num};
 	delete @params{qw{num deptype reverse sort filter list}};
 	
 	my @matches;
@@ -2144,7 +2151,15 @@ sub pagespec_match_list ($$;@) {
 		$depends_simple{$page}{lc $k} |= $i->{$k};
 	}
 
-	return @matches;
+	# when all matches will be returned, it's efficient to
+	# sort after matching
+	if (! defined $num && defined $sort) {
+		return IkiWiki::SortSpec::sort_pages(
+			$sort, $reverse, @matches);
+	}
+	else {
+		return @matches;
+	}
 }
 
 sub pagespec_valid ($) {
@@ -2437,9 +2452,8 @@ package IkiWiki::SortSpec;
 # This is in the SortSpec namespace so that the $a and $b that sort() uses
 # are easily available in this namespace, for cmp functions to use them.
 sub sort_pages {
-	my $f = IkiWiki::sortspec_translate(shift);
-
-	return sort $f @_;
+	my $f=IkiWiki::sortspec_translate(shift, shift);
+	sort $f @_
 }
 
 sub cmp_title {
diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index 5a6d63ef1..f8ac216dc 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -29,5 +29,8 @@ date range.) Well, in this case, it *does* make sense to flip it, limit by
 pagespe first, and do a (quick)sort second. (No influence complications,
 either.)
 
+> Flipping when there's no limit implemented, and it knocked 1/3 off
+> the rebuild time of my blog's archive pages. --[[Joey]] 
+
 Adding these special cases will be more complicated, but I think the best
 of both worlds. --[[Joey]]
diff --git a/t/pagespec_match_list.t b/t/pagespec_match_list.t
index 2ad7a9105..c7688c6c0 100755
--- a/t/pagespec_match_list.t
+++ b/t/pagespec_match_list.t
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 use warnings;
 use strict;
-use Test::More tests => 90;
+use Test::More tests => 92;
 
 BEGIN { use_ok("IkiWiki"); }
 
@@ -38,12 +38,16 @@ $links{foo3}=[qw{bar}];
 is_deeply([pagespec_match_list("foo", "bar")], ["bar"]);
 is_deeply([sort(pagespec_match_list("foo", "* and !post/*"))], ["bar", "foo", "foo2", "foo3"]);
 is_deeply([sort(pagespec_match_list("foo", "post/*"))], ["post/1", "post/2", "post/3"]);
+is_deeply([pagespec_match_list("foo", "post/*", sort => "title")],
+	["post/1", "post/2", "post/3"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title", reverse => 1)],
 	["post/3", "post/2", "post/1"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title", num => 2)],
 	["post/1", "post/2"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title", num => 50)],
 	["post/1", "post/2", "post/3"]);
+is_deeply([pagespec_match_list("foo", "post/*", sort => "title", num => 50, reverse => 1)],
+	["post/3", "post/2", "post/1"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title",
                          filter => sub { $_[0] =~ /3/}) ],
 	["post/1", "post/2"]);
-- 
cgit v1.2.3


From df022df35e3e3fd1d2916e762a2359f23a84a955 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 12 Apr 2010 14:57:40 -0400
Subject: implemented the other half of this

Writing my own sort code actually was faster than the built in sort. Whee!
(That's not supposed to happen, is it. ;)

But, I need to make sure influences are calculated alright.
---
 doc/todo/smarter_sorting.mdwn | 107 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 106 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index f8ac216dc..4a638213f 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -13,7 +13,7 @@ out of maybe thousands).
 As [[smcv]] noted, It could be flipped, so the pagespec is applied first,
 and then sort the smaller matching set. But, checking pagespecs is likely
 more expensive than sorting. (Also, influence calculation complicates
-doing that, since only influences for the M returned pages should be tracked.)
+doing that.)
 
 Another option, when there is a limit on M pages to return, might be to
 cull the M top pages without sorting the rest. This could be done using
@@ -22,6 +22,111 @@ Then for each of the rest, check if it is higher than the Mth page.
 If it is, bubble it up so it's sorted.
 If not, throw it out (that's the fast bit and why this is not O(N^2)).
 
+> The patch below implements this, perhaps not as efficiently as possible.
+> It speeds up building just the top page of my blog by 1 second (out of
+> 18). It's probably buggy.
+> 
+> But, I have not thought enough about influence calculation.
+> I need to figure out which pagespec matches influences need to be
+> accumulated for in order to determine all possible influences of a
+> pagespec are known.
+> 
+> The old code accumulates influences from matching all successful pages
+> up to the num cutoff, as well as influences from an arbitrary (sometimes
+> zero) number of failed matches. New code does not accumulate influences
+> from all the top successful matches, only an arbitrary group of
+> successes and some failures.
+
+
+diff --git a/IkiWiki.pm b/IkiWiki.pm
+index 1730e47..6798799 100644
+--- a/IkiWiki.pm
++++ b/IkiWiki.pm
+@@ -2122,36 +2122,53 @@ sub pagespec_match_list ($$;@) {
+ 	my $num=$params{num};
+ 	delete @params{qw{num deptype reverse sort filter list}};
+ 	
+-	# when only the top matches will be returned, it's efficient to
+-	# sort before matching to pagespec,
+-	if (defined $num && defined $sort) {
+-		@candidates=IkiWiki::SortSpec::sort_pages(
+-			$sort, @candidates);
+-	}
+-	
++	# Find the first num matches (or all), before sorting.
+ 	my @matches;
+-	my $firstfail;
+ 	my $count=0;
+ 	my $accum=IkiWiki::SuccessReason->new();
+-	foreach my $p (@candidates) {
+-		my $r=$sub->($p, %params, location => $page);
++	my $i;
++	for ($i=0; $i < @candidates; $i++) {
++		my $r=$sub->($candidates[$i], %params, location => $page);
+ 		error(sprintf(gettext("cannot match pages: %s"), $r))
+ 			if $r->isa("IkiWiki::ErrorReason");
+ 		$accum |= $r;
+ 		if ($r) {
+-			push @matches, $p;
++			push @matches, $candidates[$i];
+ 			last if defined $num && ++$count == $num;
+ 		}
+ 	}
+ 
++	# We have num natches, but they may not be the best.
++	# Efficiently find and add the rest, without sorting the full list of
++	# candidates.
++	if (defined $num && defined $sort) {
++		@matches=IkiWiki::SortSpec::sort_pages($sort, @matches);
++
++		for ($i++; $i < @candidates; $i++) {
++			# Comparing candidate with lowest match is cheaper,
++			# so it's done before testing against pagespec.
++			if (IkiWiki::SortSpec::cmptwo($candidates[$i], $matches[-1], $sort) < 0 &&
++			    $sub->($candidates[$i], %params, location => $page)
++			) {
++				# this could be done less expensively
++				# using a binary search
++				for (my $j=0; $j < @matches; $j++) {
++					if (IkiWiki::SortSpec::cmptwo($candidates[$i], $matches[$j], $sort) < 0) {
++						$matches[$j]=$candidates[$i];
++						last;
++					}
++				}
++			}
++		}
++	}
++
+ 	# Add simple dependencies for accumulated influences.
+-	my $i=$accum->influences;
+-	foreach my $k (keys %$i) {
+-		$depends_simple{$page}{lc $k} |= $i->{$k};
++	my $inf=$accum->influences;
++	foreach my $k (keys %$inf) {
++		$depends_simple{$page}{lc $k} |= $inf->{$k};
+ 	}
+ 
+-	# when all matches will be returned, it's efficient to
+-	# sort after matching
++	# Sort if we didn't already.
+ 	if (! defined $num && defined $sort) {
+ 		return IkiWiki::SortSpec::sort_pages(
+ 			$sort, @matches);
+@@ -2455,6 +2472,12 @@ sub sort_pages {
+ 	sort $f @_
+ }
+ 
++sub cmptwo {
++	$a=$_[0];
++	$b=$_[1];
++	$_[2]->();
++}
++
+ sub cmp_title {
+ 	IkiWiki::pagetitle(IkiWiki::basename($a))
+ 	cmp
+

+
 This would be bad when M is very large, and particularly, of course, when
 there is no limit and all pages are being matched on. (For example, an
 archive page shows all pages that match a pagespec specifying a creation
-- 
cgit v1.2.3


From 24fb346938037b0d41988510bc6e19e81aa62190 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 12 Apr 2010 16:04:49 -0400
Subject: fix bug

---
 doc/todo/smarter_sorting.mdwn | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index 4a638213f..33c825641 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -24,7 +24,7 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)).
 
 > The patch below implements this, perhaps not as efficiently as possible.
 > It speeds up building just the top page of my blog by 1 second (out of
-> 18). It's probably buggy.
+> 18).
 > 
 > But, I have not thought enough about influence calculation.
 > I need to figure out which pagespec matches influences need to be
@@ -39,10 +39,10 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)).
 
 
 diff --git a/IkiWiki.pm b/IkiWiki.pm
-index 1730e47..6798799 100644
+index 1730e47..bc8b23d 100644
 --- a/IkiWiki.pm
 +++ b/IkiWiki.pm
-@@ -2122,36 +2122,53 @@ sub pagespec_match_list ($$;@) {
+@@ -2122,36 +2122,54 @@ sub pagespec_match_list ($$;@) {
  	my $num=$params{num};
  	delete @params{qw{num deptype reverse sort filter list}};
  	
@@ -89,7 +89,8 @@ index 1730e47..6798799 100644
 +				# using a binary search
 +				for (my $j=0; $j < @matches; $j++) {
 +					if (IkiWiki::SortSpec::cmptwo($candidates[$i], $matches[$j], $sort) < 0) {
-+						$matches[$j]=$candidates[$i];
++						splice @matches, $j, $#matches-$j+1, $candidates[$i],
++							@matches[$j..$#matches-1];
 +						last;
 +					}
 +				}
@@ -112,7 +113,7 @@ index 1730e47..6798799 100644
  	if (! defined $num && defined $sort) {
  		return IkiWiki::SortSpec::sort_pages(
  			$sort, @matches);
-@@ -2455,6 +2472,12 @@ sub sort_pages {
+@@ -2455,6 +2473,12 @@ sub sort_pages {
  	sort $f @_
  }
  
-- 
cgit v1.2.3


From aaaef740107aacd8f6987711da6895c02e4473ad Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 12 Apr 2010 16:46:38 -0400
Subject: update

---
 doc/todo/smarter_sorting.mdwn | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index 33c825641..901e143a7 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -16,15 +16,9 @@ more expensive than sorting. (Also, influence calculation complicates
 doing that.)
 
 Another option, when there is a limit on M pages to return, might be to
-cull the M top pages without sorting the rest. This could be done using
-a variant of Ye Olde Bubble Sort. Take the first M pages, and (quick)sort.
-Then for each of the rest, check if it is higher than the Mth page.
-If it is, bubble it up so it's sorted.
-If not, throw it out (that's the fast bit and why this is not O(N^2)).
+cull the M top pages without sorting the rest.
 
-> The patch below implements this, perhaps not as efficiently as possible.
-> It speeds up building just the top page of my blog by 1 second (out of
-> 18).
+> The patch below implements this.
 > 
 > But, I have not thought enough about influence calculation.
 > I need to figure out which pagespec matches influences need to be
@@ -36,6 +30,11 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)).
 > zero) number of failed matches. New code does not accumulate influences
 > from all the top successful matches, only an arbitrary group of
 > successes and some failures.
+> 
+> Also, by the time I finished this, it was not measuarably faster than 
+> the old method. At least not with a few thousand pages; it
+> might be worth revisiting this sometime for many more pages? [[done]]
+> --[[Joey]] 
 
 
 diff --git a/IkiWiki.pm b/IkiWiki.pm
-- 
cgit v1.2.3


From 43ed0cd07ece2b5238d1c148552620a6a1c37436 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 14 Apr 2010 16:04:52 -0400
Subject: note link types are now available

---
 doc/todo/structured_page_data.mdwn            | 3 +++
 doc/todo/tracking_bugs_with_dependencies.mdwn | 3 +++
 2 files changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn
index da9da9663..9f21fab7f 100644
--- a/doc/todo/structured_page_data.mdwn
+++ b/doc/todo/structured_page_data.mdwn
@@ -253,6 +253,9 @@ in a large number of other cases.
 > dependencies between bugs from arbitrary links.
 >> This issue (the need for distinguished kinds of links) has also been brought up in other discussions: [[tracking_bugs_with_dependencies#another_kind_of_links]] (deps vs. links) and [[tag_pagespec_function]] (tags vs. links). --Ivan Z.
 
+>>> And multiple link types are now supported; plugins can set the link
+>>> type when registering a link, and pagespec functions can match on them. --[[Joey]] 
+
 ----
 
     #!/usr/bin/perl
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index 5f3ece290..456dadad0 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -81,6 +81,9 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so
 
 >> I saw that this issue is targeted at by the work on [[structured page data#another_kind_of_links]]. --Ivan Z.
 
+>>> It's fixed now; links can have a type, such as "tag", or "dependency", 
+>>> and pagespecs can match links of a given typo. --[[Joey]] 
+
 Okie - I've had a quick attempt at this.  Initial patch attached.  This one doesn't quite work.
 And there is still a lot of debugging stuff in there.
 
-- 
cgit v1.2.3


From 2f6da5fd2b17541ff88072862d37c4d6f95a50b5 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Thu, 15 Apr 2010 07:19:47 +0000
Subject: Describe my tag type proposal

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 doc/todo/Multiple_categorization_namespaces.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
new file mode 100644
index 000000000..8a0866dc5
--- /dev/null
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -0,0 +1,24 @@
+I came across this when working on converting my old blog into an ikiwiki, but I think it could be of more general use.
+
+The background: I have a (currently suspended, waiting to be converted) blog on the [il Cannocchiale](http://www.ilcannocchiale.it) hosting platform. Aside from the usual metatadata (title, author), il Cannocchiale also provides tags and two additional categorization namespaces: a blog-specific user-defind "column" (Rubrica) and a platform-wide "category" (Categoria). The latter is used to group and label a couple of platform-wide lists of latest posts, the former may be used in many different ways (e.g. multi-author blogs could have one column per author or so, or as a form of 'macro-tagging'). Columns are also a little more sophisticated than classical tags because you can assign them a subtitle too.
+
+When I started working on the conversion, my first idea was to convert Rubriche to subdirectories of an ikiwiki blog. However, this left me with a few annoying things: when rebuilding links from the import, I had to (programmatically) dive into each subdirectory to see where each post was; this would also be problematic for future posting, too. It also meant that moving a post from a Robrica to the other would break all links (unless ikiwiki has a way to fix this automagically). And I wasn't too keen on the fact that the Rubrica would come up in the URL of the post. And finally, of course, I couldn't use this to preserve the Categoria metadata.
+
+Another solution I thought about was to use special deeper tags for the Rubrica and Categoria (like: `\[[!tag "Rubrica/Some name"]]`), but this is horrible, clumsy, and makes special treatment of these tags a PITN (for example you wouldn't want the Rubrica to be displayed together with the other tags, and you would want it displayed somewhere else like next to the title of the post). This solution however looks to me as the proper path, as long as tags could support totally separate namespaces. I have a tentative implementation of this `tagtype` feature at [my git clone of ikiwiki](http://git.oblomov.eu/ikiwiki).
+
+The feature is currently implemented as follows: a `tagtypes` config options takes an array of strings: the tag types to be defined _aside from the usual tags_. Each tag type automatically provides a new directive which sets up tags that different from standard tags by having a different tagbase (the same as the tagtype) and link type (again, the same as the tagtype) (a TODO item for this would to make the directive, tagbase and link type customizable). For example, for my imported blog I would define
+
+    tagtypes => [qw{Categoria Rubrica}]
+
+and then in the blog posts I would have stuff like
+
+    \[[!Categoria "LAVORO/Vita da impiegato"]]
+    \[[!Rubrica "Il mio mondo"]]
+    \[[!meta title="Blah blah"]]
+    \[[!meta author="oblomov"]]
+
+    The body of the article
+
+    \[[!tag a bunch of tags]]
+
+and the tags would appear at the bottom of the post, the Rubrica next to the title, etc. All of this information would end up as categories in the feeds (although I would like to rework that code to make use of namespaces, terms and labels in a different way).
-- 
cgit v1.2.3


From 19700c70e54cd6d94cf02bf160d65f951dcb7d66 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Thu, 15 Apr 2010 07:39:32 +0000
Subject: response, alternative proposal

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 11 +++++++++++
 1 file changed, 11 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 8a0866dc5..dc66a0245 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -22,3 +22,14 @@ and then in the blog posts I would have stuff like
     \[[!tag a bunch of tags]]
 
 and the tags would appear at the bottom of the post, the Rubrica next to the title, etc. All of this information would end up as categories in the feeds (although I would like to rework that code to make use of namespaces, terms and labels in a different way).
+
+> Note [[plugins/contrib/report/discussion]].  To quote myself from the latter page:
+> *I find tags as they currently exist to be too limiting. I prefer something that can be used for Faceted Tagging http://en.wikipedia.org/wiki/Faceted_classification; that is, things like Author:Fred Nurk, Genre:Historical, Rating:Good, and so on. Of course, that doesn't mean that each tag is limited to only one value, either; just to take the above examples, something might have more than one author, or have multiple genres (such as Historical + Romance).*
+
+> So you aren't the only one who wants to do more with tags, but I don't think that adding a new directive for each tag type is the way to go; I think it would be simpler to just have one directive, and take advantage of the new [[matching different kinds of links]] functionality, and enhance the tag directive.
+> Perhaps something like this:
+
+	     \[[!tag categorica="LAVORO/Vita da impiegato" rubrica="Il mio mondo"]]
+
+> Part of my thinking in this is to also combine tags with [[plugins/contrib/field]], so that the tags for a page could be queried and displayed; that way, one could put them wherever you wanted on the page, using any of [[plugins/contrib/getfield]], [[plugins/contrib/ftemplate]], or [[plugins/contrib/report]].
+> --[[KathrynAndersen]]
-- 
cgit v1.2.3


From 55d4e6bdce5cf16c629765bf227125ea8899417b Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Thu, 15 Apr 2010 13:54:54 +0000
Subject: Reply to KA about collapsing metadata functionality

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index dc66a0245..15b97e480 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -2,7 +2,7 @@ I came across this when working on converting my old blog into an ikiwiki, but I
 
 The background: I have a (currently suspended, waiting to be converted) blog on the [il Cannocchiale](http://www.ilcannocchiale.it) hosting platform. Aside from the usual metatadata (title, author), il Cannocchiale also provides tags and two additional categorization namespaces: a blog-specific user-defind "column" (Rubrica) and a platform-wide "category" (Categoria). The latter is used to group and label a couple of platform-wide lists of latest posts, the former may be used in many different ways (e.g. multi-author blogs could have one column per author or so, or as a form of 'macro-tagging'). Columns are also a little more sophisticated than classical tags because you can assign them a subtitle too.
 
-When I started working on the conversion, my first idea was to convert Rubriche to subdirectories of an ikiwiki blog. However, this left me with a few annoying things: when rebuilding links from the import, I had to (programmatically) dive into each subdirectory to see where each post was; this would also be problematic for future posting, too. It also meant that moving a post from a Robrica to the other would break all links (unless ikiwiki has a way to fix this automagically). And I wasn't too keen on the fact that the Rubrica would come up in the URL of the post. And finally, of course, I couldn't use this to preserve the Categoria metadata.
+When I started working on the conversion, my first idea was to convert Rubriche to subdirectories of an ikiwiki blog. However, this left me with a few annoying things: when rebuilding links from the import, I had to (programmatically) dive into each subdirectory to see where each post was; this would also be problematic for future posting, too. It also meant that moving a post from a Rubrica to the other would break all links (unless ikiwiki has a way to fix this automagically). And I wasn't too keen on the fact that the Rubrica would come up in the URL of the post. And finally, of course, I couldn't use this to preserve the Categoria metadata.
 
 Another solution I thought about was to use special deeper tags for the Rubrica and Categoria (like: `\[[!tag "Rubrica/Some name"]]`), but this is horrible, clumsy, and makes special treatment of these tags a PITN (for example you wouldn't want the Rubrica to be displayed together with the other tags, and you would want it displayed somewhere else like next to the title of the post). This solution however looks to me as the proper path, as long as tags could support totally separate namespaces. I have a tentative implementation of this `tagtype` feature at [my git clone of ikiwiki](http://git.oblomov.eu/ikiwiki).
 
@@ -33,3 +33,13 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 
 > Part of my thinking in this is to also combine tags with [[plugins/contrib/field]], so that the tags for a page could be queried and displayed; that way, one could put them wherever you wanted on the page, using any of [[plugins/contrib/getfield]], [[plugins/contrib/ftemplate]], or [[plugins/contrib/report]].
 > --[[KathrynAndersen]]
+
+>> A very generic metadata framework could cover all possible usages of fields, tags, and related metadata, but keeping its _user interface_ generic would only make it hard to use. Note that this is not an objection to the idea of collapsing the fields and tags functionality (at quick glance, I cannot see a real difference between single-valued custom tagtypes and fields, but see below), but more about the syntax.
+
+>> I had thought about the `\[[!tag type1=value1 type2=value2]]` syntax myself, but ultimately decided against it for a number of reasons, most importantly the fact that (1) it's harder to type, (2) it's harder to spot errors in the tag types (so for example if one misspelled `categoria` as `categorica`, he might not notice it as quickly as seeing the un-parsed `\[[!categorica ]]` directive in the output html) and (3) it encourages collapsing possibly unrelated metadata together (for example, I would never consider putting the categoria information together with the rubrica  one; of course with your syntax it's perfectly possible to keep them separate as well).
+
+>> Point (2) may be considered a downside as well as an upside, depending on perspective, of course. And it would be possible to have a set of predefined tag types to match against, like in my tagtype directive approach but with your syntax. Point (3) is of course entirely in the hands of the user, but that's exactly what syntax should be about. There is nothing functionally wrong with e.g. `\[[!meta tag=sometag author=someauthor title=sometitle rubrica=somecolumn]]`, but I honestly find it horrible.
+
+>> A solution could be to allow both syntaxes, getting to have for example `\[[!sometagtype "blah"]]` as a shortcut for `\[[!tag sometagtype="blah"]]` (or, in the more general case, `\[[!somefieldname "blah"]]` as a shortcut for `\[[!meta fieldname="blah"]]`).
+
+>> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me.
-- 
cgit v1.2.3


From f0ed76441d94c9bec9ebc1314b81301fe179a7fc Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Thu, 15 Apr 2010 23:36:42 +0000
Subject: some comments about this and autoindex

---
 ...auto-create_tag_pages_according_to_a_template.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 07b570b1b..7631e6fc8 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -211,6 +211,25 @@ wrong direction.
 >> [981400177d68a279f485727be3f013e68f0bf691][].
  --[[David_Riebenbauer]]
 
+>>> This doesn't seem to have all the refinements that autoindex has:
+>>>
+>>> * `autoindex` attaches the record of deletions off the `index` page, which
+>>>   is (nearly) guaranteed to exist; this one attaches the record of
+>>>   deletions to the deleted page's page state.
+>>>
+>>> * `autoindex` forgets that a page was deleted when that page is
+>>>   re-created
+>>>
+>>> * `autoindex` forgets that a page was deleted when it's no longer needed
+>>>   anyway (this may be harder for `autotag`?)
+>>>
+>>> It'd probably be an interesting test of the core change to port
+>>> `autoindex` to use it? (Adding the file to the RCS would be
+>>> necessary to get parity with `autoindex`.) --[[smcv]]
+
+> Regarding the call from `IkiWiki.pm` to `Render.pm`, wouldn't this be
+> quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From b5e7f7a67f9893c7083afe3594c4a274c1b96062 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Thu, 15 Apr 2010 23:39:02 +0000
Subject: slight clarification

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 7631e6fc8..6118cb014 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -213,9 +213,10 @@ wrong direction.
 
 >>> This doesn't seem to have all the refinements that autoindex has:
 >>>
->>> * `autoindex` attaches the record of deletions off the `index` page, which
+>>> * `autoindex` attaches the record of deletions to the `index` page, which
 >>>   is (nearly) guaranteed to exist; this one attaches the record of
->>>   deletions to the deleted page's page state.
+>>>   deletions to the deleted page's page state. Won't that tend to result
+>>>   in losing the record along with the deleted page?
 >>>
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
-- 
cgit v1.2.3


From 208a77a977615b3e285d08b33345daca7072432e Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Fri, 16 Apr 2010 03:41:25 +0000
Subject: response

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 15b97e480..eb1f58cfa 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -38,8 +38,16 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 
 >> I had thought about the `\[[!tag type1=value1 type2=value2]]` syntax myself, but ultimately decided against it for a number of reasons, most importantly the fact that (1) it's harder to type, (2) it's harder to spot errors in the tag types (so for example if one misspelled `categoria` as `categorica`, he might not notice it as quickly as seeing the un-parsed `\[[!categorica ]]` directive in the output html) and (3) it encourages collapsing possibly unrelated metadata together (for example, I would never consider putting the categoria information together with the rubrica  one; of course with your syntax it's perfectly possible to keep them separate as well).
 
->> Point (2) may be considered a downside as well as an upside, depending on perspective, of course. And it would be possible to have a set of predefined tag types to match against, like in my tagtype directive approach but with your syntax. Point (3) is of course entirely in the hands of the user, but that's exactly what syntax should be about. There is nothing functionally wrong with e.g. `\[[!meta tag=sometag author=someauthor title=sometitle rubrica=somecolumn]]`, but I honestly find it horrible.
+>> Point (2) may be considered a downside as well as an upside, depending on perspective, of course. And it would be possible to have a set of predefined tag types to match against, like in my tagtype directive approach but with your syntax.
+
+>>> You seem to have answered your own objections already. -- K.A.
+
+>>Point (3) is of course entirely in the hands of the user, but that's exactly what syntax should be about. There is nothing functionally wrong with e.g. `\[[!meta tag=sometag author=someauthor title=sometitle rubrica=somecolumn]]`, but I honestly find it horrible.
+
+>>> So, really, point 3 comes down to differing aesthetics. -- K.A.
 
 >> A solution could be to allow both syntaxes, getting to have for example `\[[!sometagtype "blah"]]` as a shortcut for `\[[!tag sometagtype="blah"]]` (or, in the more general case, `\[[!somefieldname "blah"]]` as a shortcut for `\[[!meta fieldname="blah"]]`).
 
 >> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me.
+
+>>> Whereas I prefer being able to control such things with templates, because it gives more flexibility AND control. - K.A.
-- 
cgit v1.2.3


From 5c263623c2446191332088a29fda4e045cc06f1e Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 16 Apr 2010 17:19:44 +0200
Subject: answer about the `%pagestate` of autopages.

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 26 +++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 6118cb014..ca3475149 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -217,20 +217,40 @@ wrong direction.
 >>>   is (nearly) guaranteed to exist; this one attaches the record of
 >>>   deletions to the deleted page's page state. Won't that tend to result
 >>>   in losing the record along with the deleted page?
->>>
+
+>>>> This is probably on of the harder things to do, 'cause there are (most of the
+>>>> time) several pages that are responsible for the creation of a single tag page.
+>>>> Of course I could attach the info to all of them.
+
+>>>> With current behaviour I think the information in `%pagestate` is kept around
+>>>> regardless whether the corresponding page exists or not.
+>>>> --[[David_Riebenbauer]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
->>>
+
+>>>> Yes, I forgot about that and that is a bug. I'll fix that.
+>>>> --[[David_Riebenbauer]]
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
->>>
+
+>>>> I don't think so. AFAIK ikiwiki can detect whether there are taglinks to a page
+>>>> anyway, so it should be quite easy. I'll try to implement that too.
+>>>> --[[David_Riebenbauer]]
+
 >>> It'd probably be an interesting test of the core change to port
 >>> `autoindex` to use it? (Adding the file to the RCS would be
 >>> necessary to get parity with `autoindex`.) --[[smcv]]
 
+>>>> Good suggestion. Adding the files to RCS is on my todo list anyway.
+>>>> --[[David_Riebenbauer]]
+
 > Regarding the call from `IkiWiki.pm` to `Render.pm`, wouldn't this be
 > quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
 
+>> True. I'll do that. --[[David_Riebenbauer]]
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From e26ac520bffe39e400a037aa35b68f617991da2b Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 16 Apr 2010 17:21:54 +0200
Subject: typo

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index ca3475149..c4d9538a1 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -126,7 +126,7 @@ is not satisfied for the newly created tag page. I shall put debug msgs into Ren
 
 ---
 
-I've made another attempt at fixiing this
+I've made another attempt at fixing this
 
 The current progress can be found at my [git repository][gitweb] on branch
 `autotag`:
-- 
cgit v1.2.3


From 18b39ff9757a0e6bc8672a2453411676a09bffea Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Fri, 16 Apr 2010 15:31:31 +0000
Subject: try to clarify

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index c4d9538a1..b8b0186b4 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -226,6 +226,11 @@ wrong direction.
 >>>> regardless whether the corresponding page exists or not.
 >>>> --[[David_Riebenbauer]]
 
+>>>>> Sorry, I'll try to be clearer: `autoindex` hard-codes that the [[index]] page
+>>>>> of the entire wiki is the one responsible for storing the page state. That
+>>>>> page isn't responsible for the creation of the tag page, it's just an
+>>>>> arbitrary page that's (more or less) guaranteed to exist. --[[smcv]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
 
-- 
cgit v1.2.3


From 49be30eae88b4a027becc3e67bc321e0bf89840f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 16 Apr 2010 12:08:12 -0400
Subject: clarify re %pagestate persistence

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index b8b0186b4..1259552bf 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -231,6 +231,11 @@ wrong direction.
 >>>>> page isn't responsible for the creation of the tag page, it's just an
 >>>>> arbitrary page that's (more or less) guaranteed to exist. --[[smcv]]
 
+>>>>> I don't like that [[plugins/autoindex]] has to do that,
+>>>>> but `%pagestate` values are only stored for pages that exist,
+>>>>> so it was necessary. (Another way to look at this is that
+>>>>> `%pagestate` is not the ideal data structure.) --[[Joey]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
 
-- 
cgit v1.2.3


From a70c2518af7f48036a21d04c5b4070f3ea96002c Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 16 Apr 2010 18:16:47 +0200
Subject: answer to clarification.

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 1259552bf..0ae025a13 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -236,6 +236,8 @@ wrong direction.
 >>>>> so it was necessary. (Another way to look at this is that
 >>>>> `%pagestate` is not the ideal data structure.) --[[Joey]]
 
+>>>>> Ok, now I know what you mean. --[[David_Riebenbauer]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
 
-- 
cgit v1.2.3


From 720522859806d9cf50231ed6aa28085754713701 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Fri, 16 Apr 2010 17:51:51 +0000
Subject: ... and indeed there is a better way to store it

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 0ae025a13..8fc97578c 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -236,6 +236,9 @@ wrong direction.
 >>>>> so it was necessary. (Another way to look at this is that
 >>>>> `%pagestate` is not the ideal data structure.) --[[Joey]]
 
+>>>>>> Aha! Having looked at [[plugins/write]] again, it turns out that what this
+>>>>>> feature should really use is `%wikistate`, I think? :-) --[[smcv]]
+
 >>>>> Ok, now I know what you mean. --[[David_Riebenbauer]]
 
 >>> * `autoindex` forgets that a page was deleted when that page is
-- 
cgit v1.2.3


From ff5b73163f97110e83dd777cf7e14debebf85288 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Fri, 16 Apr 2010 18:20:29 +0000
Subject: Proposal for tags/meta/field coalescing

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index eb1f58cfa..ee3bbd88d 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -51,3 +51,22 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 >> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me.
 
 >>> Whereas I prefer being able to control such things with templates, because it gives more flexibility AND control. - K.A.
+
+>>>> Flexibility and control is good for tuning and power-usage, but sensible defaults are a must for a platform to be usable out of the box without much intervention. Moreover, there's a possible problem with what kind of data must be passed over to templates.
+
+Aside from the name of the plugin (and thus of the main directive), which could be `tag`, `meta`, `field` or whatever (maybe extending `meta` would be the most sensible choice), the features we want are
+
+  1. allow multiple values per type/attribute/field/whatever (fields currently only allows one)
+  2. allow both hidden and visible references (à la tag vs taglink)
+  3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
+  4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
+
+Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters:
+
+  * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
+  * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
+  * `linktype` : link type for (hidden and visible) references
+  * `linkbase` : akin to the tagbase parameter
+  * `queries` : list of template queries this type/attribute/field/whatever is exposed to
+
+Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From b14f84c4acccbc8450a9102b3b647013989b27bb Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 16 Apr 2010 17:02:29 -0400
Subject: --gettime revamp

* Rename --getctime to --gettime. (The old name still works for
  backwards compatability.)
* --gettime now also looks up last modification time.
* Add rcs_getmtime to plugin API; currently only implemented
  for git.
---
 IkiWiki.pm                                         |  8 +++++--
 IkiWiki/Plugin/bzr.pm                              |  5 +++++
 IkiWiki/Plugin/cvs.pm                              |  5 +++++
 IkiWiki/Plugin/darcs.pm                            |  5 +++++
 IkiWiki/Plugin/git.pm                              |  5 +++++
 IkiWiki/Plugin/mercurial.pm                        |  5 +++++
 IkiWiki/Plugin/monotone.pm                         |  5 +++++
 IkiWiki/Plugin/norcs.pm                            |  7 +++++-
 IkiWiki/Plugin/svn.pm                              |  5 +++++
 IkiWiki/Plugin/tla.pm                              |  5 +++++
 IkiWiki/Render.pm                                  | 18 +++++++++++++---
 debian/changelog                                   |  5 +++++
 .../How_does_ikiwiki_remember_times__63__.mdwn     | 25 ++++++----------------
 ...old_repository_to_new_ikiwiki_system__63__.mdwn |  4 ----
 doc/plugins/write.mdwn                             |  7 ++++++
 doc/rcs.mdwn                                       |  8 +++++--
 doc/tips/Importing_posts_from_Wordpress.mdwn       |  2 +-
 doc/tips/inside_dot_ikiwiki/discussion.mdwn        |  7 +++---
 doc/todo/auto_getctime_on_fresh_build.mdwn         |  8 +++++--
 doc/usage.mdwn                                     | 10 ++++-----
 ikiwiki.in                                         |  3 ++-
 mtime-to-git                                       | 14 ------------
 22 files changed, 109 insertions(+), 57 deletions(-)
 delete mode 100755 mtime-to-git

(limited to 'doc/todo')

diff --git a/IkiWiki.pm b/IkiWiki.pm
index 1730e476a..7655dada5 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -440,10 +440,10 @@ sub getsetup () {
 		safe => 0,
 		rebuild => 0,
 	},
-	getctime => {
+	gettime => {
 		type => "internal",
 		default => 0,
-		description => "running in getctime mode",
+		description => "running in gettime mode",
 		safe => 0,
 		rebuild => 0,
 	},
@@ -1790,6 +1790,10 @@ sub rcs_getctime ($) {
 	$hooks{rcs}{rcs_getctime}{call}->(@_);
 }
 
+sub rcs_getmtime ($) {
+	$hooks{rcs}{rcs_getmtime}{call}->(@_);
+}
+
 sub rcs_receive () {
 	$hooks{rcs}{rcs_receive}{call}->();
 }
diff --git a/IkiWiki/Plugin/bzr.pm b/IkiWiki/Plugin/bzr.pm
index 0efc26b49..f79ca7c8f 100644
--- a/IkiWiki/Plugin/bzr.pm
+++ b/IkiWiki/Plugin/bzr.pm
@@ -20,6 +20,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -306,4 +307,8 @@ sub rcs_getctime ($) {
 	return $ctime;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for bzr\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/cvs.pm b/IkiWiki/Plugin/cvs.pm
index 26a3e9dd2..360d97249 100644
--- a/IkiWiki/Plugin/cvs.pm
+++ b/IkiWiki/Plugin/cvs.pm
@@ -49,6 +49,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub genwrapper () {
@@ -485,4 +486,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for cvs\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/darcs.pm b/IkiWiki/Plugin/darcs.pm
index bc8394b90..c1d6661d3 100644
--- a/IkiWiki/Plugin/darcs.pm
+++ b/IkiWiki/Plugin/darcs.pm
@@ -18,6 +18,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub silentsystem (@) {
@@ -427,4 +428,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for darcs\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm
index b02f4a5ed..86d80186f 100644
--- a/IkiWiki/Plugin/git.pm
+++ b/IkiWiki/Plugin/git.pm
@@ -25,6 +25,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 	hook(type => "rcs", id => "rcs_receive", call => \&rcs_receive);
 }
 
@@ -634,6 +635,10 @@ sub rcs_getctime ($) {
 	return $ctime;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for git\n"; # TODO
+}
+
 sub rcs_receive () {
 	# The wiki may not be the only thing in the git repo.
 	# Determine if it is in a subdirectory by examining the srcdir,
diff --git a/IkiWiki/Plugin/mercurial.pm b/IkiWiki/Plugin/mercurial.pm
index ea00a3364..34e009c7a 100644
--- a/IkiWiki/Plugin/mercurial.pm
+++ b/IkiWiki/Plugin/mercurial.pm
@@ -20,6 +20,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -254,4 +255,8 @@ sub rcs_getctime ($) {
 	return $ctime;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for mercurial\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/monotone.pm b/IkiWiki/Plugin/monotone.pm
index c33cf7e3a..67d4abbaa 100644
--- a/IkiWiki/Plugin/monotone.pm
+++ b/IkiWiki/Plugin/monotone.pm
@@ -23,6 +23,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -693,4 +694,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for monotone\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/norcs.pm b/IkiWiki/Plugin/norcs.pm
index e6a05a3c5..053652a5f 100644
--- a/IkiWiki/Plugin/norcs.pm
+++ b/IkiWiki/Plugin/norcs.pm
@@ -18,6 +18,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub getsetup () {
@@ -63,7 +64,11 @@ sub rcs_diff ($) {
 }
 
 sub rcs_getctime ($) {
-	error gettext("getctime not implemented");
+	return 0;
+}
+
+sub rcs_getmtime ($) {
+	return 0;
 }
 
 1
diff --git a/IkiWiki/Plugin/svn.pm b/IkiWiki/Plugin/svn.pm
index 7d27ec842..85c205f09 100644
--- a/IkiWiki/Plugin/svn.pm
+++ b/IkiWiki/Plugin/svn.pm
@@ -19,6 +19,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -379,4 +380,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for svn\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/tla.pm b/IkiWiki/Plugin/tla.pm
index 764da9b98..f5ad0cc96 100644
--- a/IkiWiki/Plugin/tla.pm
+++ b/IkiWiki/Plugin/tla.pm
@@ -18,6 +18,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -284,4 +285,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for tla\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm
index e98888d76..e1cb68462 100644
--- a/IkiWiki/Render.pm
+++ b/IkiWiki/Render.pm
@@ -365,14 +365,26 @@ sub find_new_files ($) {
 			}
 			else {
 				push @new, $file;
-				if ($config{getctime} && -e "$config{srcdir}/$file") {
+				if ($config{gettime} && -e "$config{srcdir}/$file") {
 					eval {
-						my $time=rcs_getctime("$config{srcdir}/$file");
-						$pagectime{$page}=$time;
+						my $ctime=rcs_getctime("$config{srcdir}/$file");
+						if ($ctime > 0) {
+							$pagectime{$page}=$ctime;
+						}
 					};
 					if ($@) {
 						print STDERR $@;
 					}
+					my $mtime;
+					eval {
+						my $mtime=rcs_getmtime("$config{srcdir}/$file");
+					};
+					if ($@) {
+						print STDERR $@;
+					}
+					elsif ($mtime > 0) {
+						utime($mtime, $mtime, "$config{srcdir}/$file");
+					}
 				}
 			}
 			$pagecase{lc $page}=$page;
diff --git a/debian/changelog b/debian/changelog
index 737d73655..615d5916f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -44,6 +44,11 @@ ikiwiki (3.20100415) UNRELEASED; urgency=low
   * conditional: Fix bug that forced "all" mode off by default.
   * calendarmonth.tmpl: The month calendar is now put in a sidebar.
   * calendar: Improved display of arrows.
+  * Rename --getctime to --gettime. (The old name still works for
+    backwards compatability.)
+  * --gettime now also looks up last modification time.
+  * Add rcs_getmtime to plugin API; currently only implemented
+    for git.
 
  -- Joey Hess   Sun, 04 Apr 2010 12:17:11 -0400
 
diff --git a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
index 6ce576db1..6b7739fd0 100644
--- a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
+++ b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
@@ -20,15 +20,17 @@ Do I have it right?
 > Some VCS, like git, set the file mtimes to the current time
 > when making a new checkout, so they will be lost if you do that.
 > The creation times can be retrived using the `--getctime` option.
-> I suppose it might be nice if there were a `--getmtime` that pulled
-> true modification times out of the VCS, but I haven't found it a big
-> deal in practice for the last modification times to be updated to the
-> current time when rebuilding a wiki like this. --[[Joey]] 
+> --[[Joey]] 
 >
 > > Thanks for the clarification. I ran some tests of my own to make sure I understand it right, and I'm satisfied
 > > that the order of posts in my blog can be retrieved from the VCS using the `--getctime` option, at least if I
 > > choose to order my posts by creation time rather than modification time. But I now know that I can't rely on
 > > page modification times in ikiwiki as these can be lost permanently.
+> 
+> > > Update: It's now renamed to `--gettime`, and pulls both the creation
+> > > and modification times. Also, per [[todo/auto_getctime_on_fresh_build]],
+> > > this is now done automatically the first time ikiwiki builds a
+> > > srcdir. So, no need to worry about this any more! --[[Joey]] 
 > >
 > > I would suggest that there should at least be a `--getmtime` option like you describe, and perhaps that 
 > > `--getctime` and `--getmtime` be _on by default_. In my opinion the creation times and modification times of 
@@ -91,19 +93,6 @@ Do I have it right?
 > A quick workaround for me to get modification times right is the following
 > little zsh script, which unfortunately only works for git:
 
-    #!/usr/bin/env zsh
-    
-    set +x
-    
-    for FILE in **/*(.); do
-      TIMES="`git log --pretty=format:%ai $FILE`"
-      MTIME="`echo $TIMES | head -n1`"
-    
-      if [ ! -z $MTIME ]; then
-        echo  touch -m -d "$MTIME" $FILE
-        touch -m -d "$MTIME" $FILE
-      fi
-    
-    done
+>> Elided; no longer needed since --gettime does that, and much faster! --[[Joey]] 
 
 > --[[David_Riebenbauer]]
diff --git a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
index fe67e6aba..d7a33b526 100644
--- a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
+++ b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
@@ -20,10 +20,6 @@ How do I set up an ikiwiki system using a pre-existing repository (instead of cr
 >    recreate the ikiwiki srcdir
 > 3. `git clone` from the bare git repository a second time,
 >    to create a checkout you can manually edit (optional)
-> 4. run `ikiwiki --getctime --setup your.setup`
->    The getctime will ensure page creation times are accurate
->    by putting the info out of the git history,
->    and only needs to be done once.
 >
 > If you preserved your repository, but not the setup file,
 > the easiest way to make one is probably to run
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 707622956..cf7044b2c 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -1085,6 +1085,13 @@ it up in the history.
 
 It's ok if this is not implemented, and throws an error.
 
+#### `rcs_getmtime($)`
+
+This is used to get the page modification time for a file from the RCS, by
+looking it up in the history.
+
+It's ok if this is not implemented, and throws an error.
+
 #### `rcs_receive()`
 
 This is called when ikiwiki is running as a pre-receive hook (or
diff --git a/doc/rcs.mdwn b/doc/rcs.mdwn
index 4e7a8d2a6..b5bfc2414 100644
--- a/doc/rcs.mdwn
+++ b/doc/rcs.mdwn
@@ -14,8 +14,10 @@ use, some advanced or special features are not supported in all of them.
 Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to
 set up a wiki using that revision control system. The `rcs_commit_staged`
 hook is needed to use [[attachments|plugins/attachment]] or
-[[plugins/comments]]. And so on. The table below summarises this for each
-revision control system and links to more information about each.
+[[plugins/comments]]. `rcs_getctime` may be implemented in a fast way
+(ie, one log lookup for all files), or very slowly (one lookup per file).
+And so on. The table below summarises this for each revision control
+system and links to more information about each.
 
 [[!table data="""
 feature             |[[git]]|[[svn]]|[[bzr]]   |[[monotone]]|[[mercurial]]|[[darcs]]|[[tla]]   |[[cvs]]
@@ -25,6 +27,8 @@ auto.setup          |yes    |yes    |incomplete|yes         |incomplete   |yes
 `rcs_rename`        |yes    |yes    |yes       |yes         |no           |yes      |no        |yes
 `rcs_remove`        |yes    |yes    |yes       |yes         |no           |yes      |no        |yes
 `rcs_diff`          |yes    |yes    |yes       |yes         |no           |yes      |yes       |yes
+`rcs_getctime`      |fast   |slow   |slow      |slow        |slow         |slow     |slow      |slow
+`rcs_getmtime`      |fast   |no     |no        |no          |no           |no       |no        |no
 anonymous push      |yes    |no     |no        |no          |no           |no       |no        |no
 conflict handling   |yes    |yes    |yes       |buggy       |yes          |yes      |yes       |yes
 """]]
diff --git a/doc/tips/Importing_posts_from_Wordpress.mdwn b/doc/tips/Importing_posts_from_Wordpress.mdwn
index 59330caa4..8774c9723 100644
--- a/doc/tips/Importing_posts_from_Wordpress.mdwn
+++ b/doc/tips/Importing_posts_from_Wordpress.mdwn
@@ -1,6 +1,6 @@
 Use case: You want to move away from Wordpress to Ikiwiki as your blogging/website platform, but you want to retain your old posts.
 
-[This](http://git.chris-lamb.co.uk/?p=ikiwiki-wordpress-import.git) is a simple tool that generates [git-fast-import](http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html)-compatible data from a WordPress export XML file. It retains creation time of each post, so you can use Ikiwiki's --getctime to get the preserve creation times on checkout. 
+[This](http://git.chris-lamb.co.uk/?p=ikiwiki-wordpress-import.git) is a simple tool that generates [git-fast-import](http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html)-compatible data from a WordPress export XML file. It retains creation time of each post, so you can use Ikiwiki's --gettime to get the preserve creation times on checkout. 
 
 WordPress categories are mapped onto Ikiwiki tags. The ability to import comments is planned.
 
diff --git a/doc/tips/inside_dot_ikiwiki/discussion.mdwn b/doc/tips/inside_dot_ikiwiki/discussion.mdwn
index 34d5b9252..69df369ec 100644
--- a/doc/tips/inside_dot_ikiwiki/discussion.mdwn
+++ b/doc/tips/inside_dot_ikiwiki/discussion.mdwn
@@ -6,14 +6,15 @@ My database appears corrupted:
 No idea how this happened.  I've blown it away and recreated it but, for future reference, is there any less violent way to recover from this situation?  I miss having the correct created and last edited times.  --[[sabr]]
 > update: fixed ctimes and mtimes using [these instructions](http://u32.net/Mediawiki_Conversion/Git_Import/#Correct%20Creation%20and%20Last%20Edited%20time) --[[sabr]]
 
-> That's overly complex. Just run `ikiwiki -setup your.setup -getctime`. 
+> That's overly complex. Just run `ikiwiki -setup your.setup -gettime`. 
 > BTW, I'd be interested in examining such a corrupt storable file to try
 > to see what happened to it. --[[Joey]]
 
->> --getctime appears to only set the last edited date.  It's not supposed to set the creation date, is it?  The only place that info is stored is in the git repo.
+>> --gettime appears to only set the last edited date.  It's not supposed to set the creation date, is it?  The only place that info is stored is in the git repo.
 
 >>> Pulling the page creation date out of the git history is exactly what
->>> --getctime does. --[[Joey]]
+>>> --gettime does. (It used to be called --getctime, and only do that; now
+>>> it also pulls out the last modified date). --[[Joey]]
 
 >> Alas, I seem to have lost the bad index file to periodic /tmp wiping; I'll send it to you if it happens again.  --[[sabr]]
 
diff --git a/doc/todo/auto_getctime_on_fresh_build.mdwn b/doc/todo/auto_getctime_on_fresh_build.mdwn
index ea95fb8c9..760c56fa1 100644
--- a/doc/todo/auto_getctime_on_fresh_build.mdwn
+++ b/doc/todo/auto_getctime_on_fresh_build.mdwn
@@ -1,9 +1,13 @@
 [[!tag wishlist]]
 
-It might be a good idea to enable --getctime when `.ikiwiki` does not
+It might be a good idea to enable --gettime when `.ikiwiki` does not
 exist. This way a new checkout of a `srcdir` would automatically get
-ctimes right. (Running --getctime whenever a rebuild is done would be too
+ctimes right. (Running --gettime whenever a rebuild is done would be too
 slow.) --[[Joey]] 
 
 Could this be too annoying in some cases, eg, checking out a large wiki
 that needs to get set up right away? --[[Joey]] 
+
+> Not for git with the new, optimised --getctime. For other VCS.. well,
+> pity they're not as fast as git ;), but it is a one-time expense...
+> [[done]] --[[Joey]]
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index db1e36a10..553fef01e 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -320,13 +320,11 @@ also be configured using a setup file.
   intercepted. If you enable this option then you must run at least the 
   CGI portion of ikiwiki over SSL.
 
-* --getctime
+* --gettime
 
-  Pull creation time for each new page out of the revision control
-  system. This rarely used option provides a way to get the real creation
-  times of items in weblogs, such as when building a wiki from a new
-  VCS checkout. It is unoptimised and quite slow. It is best used
-  with --rebuild, to force ikiwiki to get the ctime for all pages.
+  Extract creation and modification times for each new page from the
+  the revision control's log. This is done automatically when building a
+  wiki for the first time, so you normally do not need to use this option.
 
 * --set var=value
   
diff --git a/ikiwiki.in b/ikiwiki.in
index 38e4d3201..801ff9a0b 100755
--- a/ikiwiki.in
+++ b/ikiwiki.in
@@ -44,7 +44,8 @@ sub getconfig () {
 			"wrappergroup=s" => \$config{wrappergroup},
 			"usedirs!" => \$config{usedirs},
 			"prefix-directives!" => \$config{prefix_directives},
-			"getctime" => \$config{getctime},
+			"getctime" => \$config{gettime},
+			"gettime" => \$config{gettime},
 			"numbacklinks=i" => \$config{numbacklinks},
 			"rcs=s" => \$config{rcs},
 			"no-rcs" => sub { $config{rcs}="" },
diff --git a/mtime-to-git b/mtime-to-git
deleted file mode 100755
index 9875af5d7..000000000
--- a/mtime-to-git
+++ /dev/null
@@ -1,14 +0,0 @@
-#!/bin/sh
-# Sets mtimes of all files in the tree their last change date
-# based on git's log. Useful to avoid too new dates after a
-# fresh checkout, which lead to ikiwiki unnecessarily rebuilding
-# basewiki files on upgrade.
-if [ -d .git ]; then
-	for file in $(git ls-files); do
-		date="$(git log -1 --date=rfc "$file" | grep ^Date: | sed -e 's/Date://')"
-		if [ -n "$date" ]; then
-			echo "$date $file"
-			touch -d"$date" $file
-		fi
-	done
-fi
-- 
cgit v1.2.3


From c769a33392c4dedbabfb1fa1fda5c8bb30b84c78 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 12:20:50 -0400
Subject: autoindex: Switch to using %wikistate instead of abusing
 $pagestate{index}.

---
 IkiWiki/Plugin/autoindex.pm                          | 20 ++++++++++++++------
 debian/changelog                                     |  2 ++
 ...uto-create_tag_pages_according_to_a_template.mdwn |  3 +++
 3 files changed, 19 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/autoindex.pm b/IkiWiki/Plugin/autoindex.pm
index 555856b11..c71d73349 100644
--- a/IkiWiki/Plugin/autoindex.pm
+++ b/IkiWiki/Plugin/autoindex.pm
@@ -61,8 +61,16 @@ sub refresh () {
 	}
 	
 	my %deleted;
-        if (ref $pagestate{index}{autoindex}{deleted}) {
-	       %deleted=%{$pagestate{index}{autoindex}{deleted}};
+	if (ref $wikistate{autoindex}{deleted}) {
+		%deleted=%{$wikistate{autoindex}{deleted}};
+	}
+        elsif (ref $pagestate{index}{autoindex}{deleted}) {
+		# compatability code
+		%deleted=%{$pagestate{index}{autoindex}{deleted}};
+		delete $pagestate{index}{autoindex};
+	}
+
+	if (keys %deleted) {
 		foreach my $dir (keys %deleted) {
 			# remove deleted page state if the deleted page is re-added,
 			# or if all its subpages are deleted
@@ -71,7 +79,7 @@ sub refresh () {
 				delete $deleted{$dir};
 			}
 		}
-		$pagestate{index}{autoindex}{deleted}=\%deleted;
+		$wikistate{autoindex}{deleted}=\%deleted;
 	}
 
 	my @needed;
@@ -82,10 +90,10 @@ sub refresh () {
 				# This page must have just been deleted, so
 				# don't re-add it. And remember it was
 				# deleted.
-				if (! ref $pagestate{index}{autoindex}{deleted}) {
-					$pagestate{index}{autoindex}{deleted}={};
+				if (! ref $wikistate{autoindex}{deleted}) {
+					$wikistate{autoindex}{deleted}={};
 				}
-				${$pagestate{index}{autoindex}{deleted}}{$dir}=1;
+				${$wikistate{autoindex}{deleted}}{$dir}=1;
 			}
 			else {
 				push @needed, $dir;
diff --git a/debian/changelog b/debian/changelog
index d65ffffd7..4721c5309 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -58,6 +58,8 @@ ikiwiki (3.20100415) UNRELEASED; urgency=low
     an iffy thing.
   * Use above to fix up timestamps on docwiki, as well as ensure that
     timestamps on basewiki files shipped in the deb are sane.
+  * autoindex: Switch to using %wikistate instead of abusing
+    $pagestate{index}.
 
  -- Joey Hess   Sun, 04 Apr 2010 12:17:11 -0400
 
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 8fc97578c..49da3c80c 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -239,6 +239,9 @@ wrong direction.
 >>>>>> Aha! Having looked at [[plugins/write]] again, it turns out that what this
 >>>>>> feature should really use is `%wikistate`, I think? :-) --[[smcv]]
 
+>>>>>>> Ah, indeed, that came after I wrote autoindex. I've fixed autoindex to
+>>>>>>> use it. --[[Joey]]
+
 >>>>> Ok, now I know what you mean. --[[David_Riebenbauer]]
 
 >>> * `autoindex` forgets that a page was deleted when that page is
-- 
cgit v1.2.3


From 7fcc0faf8367c5ae64a3ff06d0d74baa063c4dfc Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 12:45:20 -0400
Subject: few more suggestions

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 49da3c80c..def55f3ee 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -269,6 +269,15 @@ wrong direction.
 
 >> True. I'll do that. --[[David_Riebenbauer]]
 
+> Seems that `%autofiles` stores plugin names as keys, but never
+> really uses them. So it could just as easily be an array.
+> 
+> I'd be happy if the `%del_hash` global were not needed. 
+> Looks like it could be avoided by moving the checks
+> that `add_autofile` does into the autofile handling loop in
+> `Render`. (Also, that loop should probably be in its own
+> function anyway.) --[[Joey]] 
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From c721a9ef872db85b26d430a2098234a4fca6ec51 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 13:41:06 -0400
Subject: my autotag branch

---
 .../auto-create_tag_pages_according_to_a_template.mdwn     | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index def55f3ee..867306f0d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -269,14 +269,12 @@ wrong direction.
 
 >> True. I'll do that. --[[David_Riebenbauer]]
 
-> Seems that `%autofiles` stores plugin names as keys, but never
-> really uses them. So it could just as easily be an array.
-> 
-> I'd be happy if the `%del_hash` global were not needed. 
-> Looks like it could be avoided by moving the checks
-> that `add_autofile` does into the autofile handling loop in
-> `Render`. (Also, that loop should probably be in its own
-> function anyway.) --[[Joey]] 
+>> I've pushed an autotag branch of my own, which refactors
+>> things a bit. It is untested so far though. --[[Joey]]
+>>
+>> * `verify_src_file` only called from Render.pm
+>> * Gets rid of `%del_files`.
+>> * Uses `%wikistate`.
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 9fbef7e1d2c4e8bbaf3eaf89885f18b88edbe429 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 13:42:50 -0400
Subject: reformat

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 867306f0d..ed681ac4d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -269,12 +269,13 @@ wrong direction.
 
 >> True. I'll do that. --[[David_Riebenbauer]]
 
->> I've pushed an autotag branch of my own, which refactors
->> things a bit. It is untested so far though. --[[Joey]]
->>
->> * `verify_src_file` only called from Render.pm
->> * Gets rid of `%del_files`.
->> * Uses `%wikistate`.
+[[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
+I've pushed an autotag branch of my own, which refactors
+things a bit. It is untested so far though. --[[Joey]]
+
+* `verify_src_file` only called from Render.pm
+* Gets rid of `%del_files`.
+* Uses `%wikistate`.
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 63e6c00890a11144f8d035f7052a6229227fce52 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Mon, 19 Apr 2010 02:23:12 +0000
Subject: response to the further thoughts

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 26 ++++++++++++++++--------
 1 file changed, 17 insertions(+), 9 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index ee3bbd88d..1861d860c 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -56,17 +56,25 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 
 Aside from the name of the plugin (and thus of the main directive), which could be `tag`, `meta`, `field` or whatever (maybe extending `meta` would be the most sensible choice), the features we want are
 
-  1. allow multiple values per type/attribute/field/whatever (fields currently only allows one)
-  2. allow both hidden and visible references (à la tag vs taglink)
-  3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
-  4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
+1. allow multiple values per type/attribute/field/whatever (fields currently only allows one)
+   * Agreed about multiple values; I've been considering whether I should add that to `field`. -- K.A.
+2. allow both hidden and visible references (a la tag vs taglink)
+   * Hidden and visible references; that's fair enough too.  My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A.
+3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
+   * I'm not sure what you mean here. -- K.A.
+4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
+   * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A.
 
 Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters:
 
-  * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
-  * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
-  * `linktype` : link type for (hidden and visible) references
-  * `linkbase` : akin to the tagbase parameter
-  * `queries` : list of template queries this type/attribute/field/whatever is exposed to
+* `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
+  * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A.
+* `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
+* `linktype` : link type for (hidden and visible) references
+  * Is this the equivalent to "field name"? -- K.A.
+* `linkbase` : akin to the tagbase parameter
+  * Is this a field-name -> directory mapping? -- K.A.
+* `queries` : list of template queries this type/attribute/field/whatever is exposed to
+  * I'm not sure what you mean here. -- K.A.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From 99cdd38dd54047d0e79dbf65d58ba11ee38f2c92 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Mon, 19 Apr 2010 08:36:38 +0000
Subject: Respond

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 1861d860c..ae35e8dfe 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -62,19 +62,25 @@ Aside from the name of the plugin (and thus of the main directive), which could
    * Hidden and visible references; that's fair enough too.  My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A.
 3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
    * I'm not sure what you mean here. -- K.A.
+     * Typical example is tags: they are accessible both as `tags` and as `categories`, although the way they are presented changes a little -- G.B.
 4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
    * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A.
+     * I am saying that the user should be able to define (e.g. in the config) some set of types/fields/attributes/whatever, following the specification illustrated below, but also be able to use something like `\[[!meta somefield="somevalue"]]` where `somefield` was never defined before. In this case `somefield` will have some default values for the properties described in the spec below. -- G.B.
 
 Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters:
 
 * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
   * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A.
+     * The possibility to use a directive does not preclude other ways of defining the field values. IOW, even if the directive `somefield` is defined, the user would still be able to use the syntax `\[[!meta somefield="somevalue"]]`, or any other syntax (such as YAML). -- G.B.
 * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
 * `linktype` : link type for (hidden and visible) references
   * Is this the equivalent to "field name"? -- K.A.
+     * This would be such by default, but it could be set to something different. [[Typed links|matching_different_kinds_of_links]] is a very recent ikiwiki feature. -- G.B.
 * `linkbase` : akin to the tagbase parameter
   * Is this a field-name -> directory mapping? -- K.A.
+     * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
+     * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
 
-Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
+Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From 1b7c455f4a4214bc9df766be4ec2b12adcf679e1 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 19 Apr 2010 16:03:53 -0400
Subject: thinking about changing how templatedir works and allowing
 wikitemplate files into the srcdir

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 33 +++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 doc/todo/auto_rebuild_on_template_change.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
new file mode 100644
index 000000000..c4ffae178
--- /dev/null
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -0,0 +1,33 @@
+If `page.tmpl` is changed, it would be nice if ikiwiki automatically
+noticed, and rebuilt all pages. If `inlinepage.tmpl` is changed, a rebuild
+of all pages using it in an inline would be stellar.
+
+This would allow setting:
+
+	templatedir => "$srcdir/templates",
+
+.. and then the [[wikitemplates]] are managed like other wiki files; and
+like other wiki files, a change to them automatically updates dependent
+pages.
+
+Originally, it made good sense not to have the templatedir inside the wiki.
+Those templates can be used to bypass the htmlscrubber, and you don't want
+just anyone to edit them. But the same can be said of `style.css` and
+`ikiwiki.js`, which *are* in the wiki. We rely on `allowed_attachments`
+being set to secure those to prevent users uploading replacements. And we
+assume that users who can directly (non-anon) commit *can* edit them, and
+that's ok.
+
+So, perhaps the easiest way to solve this [[wishlist]] would be to
+make templatedir *default* to "$srcdir/templates/, and make ikiwiki
+register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're
+used. Although, having every page declare an explicit dep on `page.tmpl`
+is perhaps a bit much; might be better to implement a special case for that
+one. Also, having the templates be copied to `destdir` is not desirable.
+
+The risk is that a site might have `allowed_attachments` set to "templates/*"
+or "*.tmpl" something like that. I think such a configuration is the *only*
+risk, and it's unlikely enough that a NEWS warning should suffice.
+
+(This would also help to clear up the tricky disctinction between
+wikitemplates and in-wiki templates.)
-- 
cgit v1.2.3


From 09c647c1773d5c8eafacea486082684909e47449 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:31:00 +0000
Subject: response

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index c4ffae178..2799842ed 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -31,3 +31,5 @@ risk, and it's unlikely enough that a NEWS warning should suffice.
 
 (This would also help to clear up the tricky disctinction between
 wikitemplates and in-wiki templates.)
+
+> But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
-- 
cgit v1.2.3


From 9f00692a798888b9cc9edb30a961c6418efba39b Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 19 Apr 2010 22:37:55 -0400
Subject: response

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 2799842ed..cde19700c 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -25,11 +25,15 @@ used. Although, having every page declare an explicit dep on `page.tmpl`
 is perhaps a bit much; might be better to implement a special case for that
 one. Also, having the templates be copied to `destdir` is not desirable.
 
-The risk is that a site might have `allowed_attachments` set to "templates/*"
-or "*.tmpl" something like that. I think such a configuration is the *only*
-risk, and it's unlikely enough that a NEWS warning should suffice.
+The risk is that a site might have `allowed_attachments` set to
+`templates/*` or `*.tmpl` something like that. I think such a configuration
+is the *only* risk, and it's unlikely enough that a NEWS warning should
+suffice.
 
 (This would also help to clear up the tricky disctinction between
 wikitemplates and in-wiki templates.)
 
 > But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
+
+>> It would be better for them not to be rendered separately at all.
+>> --[[Joey]]  
-- 
cgit v1.2.3


From 16afa9e8446771fabe45ab45d8a36d09034d0319 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:41:13 +0000
Subject: further clarification

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index ae35e8dfe..190070816 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -79,8 +79,10 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t
 * `linkbase` : akin to the tagbase parameter
   * Is this a field-name -> directory mapping? -- K.A.
      * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
+       * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
      * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
+       * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From fda191cbbbfa76114a27a53bfc5b90289f26f72b Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:43:44 +0000
Subject: formatting

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 190070816..74e5bc812 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -79,10 +79,10 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t
 * `linkbase` : akin to the tagbase parameter
   * Is this a field-name -> directory mapping? -- K.A.
      * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
-       * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
+         * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
      * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
-       * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
+         * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From 529929e732e1c6604d31b68e81898780de06e640 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:45:14 +0000
Subject: non comprend

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index cde19700c..6a1013f8d 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -37,3 +37,5 @@ wikitemplates and in-wiki templates.)
 
 >> It would be better for them not to be rendered separately at all.
 >> --[[Joey]]  
+
+>>> I don't follow you. --[[KathrynAndersen]]
-- 
cgit v1.2.3


From 563428ebd2a75cfabccf1974da0c1cbbe07eb369 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 19 Apr 2010 23:52:16 -0400
Subject: response

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 6a1013f8d..2558d5f3e 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -24,6 +24,7 @@ register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're
 used. Although, having every page declare an explicit dep on `page.tmpl`
 is perhaps a bit much; might be better to implement a special case for that
 one. Also, having the templates be copied to `destdir` is not desirable.
+(However, if they're not copied, wikilinks to them will be broken. Hmm.)
 
 The risk is that a site might have `allowed_attachments` set to
 `templates/*` or `*.tmpl` something like that. I think such a configuration
@@ -39,3 +40,8 @@ wikitemplates and in-wiki templates.)
 >> --[[Joey]]  
 
 >>> I don't follow you. --[[KathrynAndersen]]
+
+>>>> If they don't render to output files, they clearly don't
+>>>> need to be treated as wiki pages. (They need to be treated
+>>>> as raw files anyway, because you don't want random users editing them 
+>>>> in the online editor.) --[[Joey]] 
-- 
cgit v1.2.3


From 11718519348382892d5c6fdb21b8e721c2413eb0 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 20 Apr 2010 01:32:19 -0400
Subject: similarity to internal pages

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 2558d5f3e..2e4ba8e9a 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -24,7 +24,8 @@ register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're
 used. Although, having every page declare an explicit dep on `page.tmpl`
 is perhaps a bit much; might be better to implement a special case for that
 one. Also, having the templates be copied to `destdir` is not desirable.
-(However, if they're not copied, wikilinks to them will be broken. Hmm.)
+In a sense, these template would be like internal pages, except not wiki
+pages, but raw files.
 
 The risk is that a site might have `allowed_attachments` set to
 `templates/*` or `*.tmpl` something like that. I think such a configuration
-- 
cgit v1.2.3


From 52ccc03d10c532b3cf6335b00a9b60057061596b Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Tue, 20 Apr 2010 15:40:10 +0100
Subject: clarify whether the raw files would be put in destdir

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 2e4ba8e9a..09a623427 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -46,3 +46,6 @@ wikitemplates and in-wiki templates.)
 >>>> need to be treated as wiki pages. (They need to be treated
 >>>> as raw files anyway, because you don't want random users editing them 
 >>>> in the online editor.) --[[Joey]] 
+
+>>>>> Just to be clear, the raw files would not be copied across to the output
+>>>>> directory? -- [[Jon]]
-- 
cgit v1.2.3


From 3b8f4f59d6720e5a77cae30eacc4c46582b1603b Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 20 Apr 2010 15:01:39 +0000
Subject: internal pages: the revenge?

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 09a623427..b5c107915 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -49,3 +49,9 @@ wikitemplates and in-wiki templates.)
 
 >>>>> Just to be clear, the raw files would not be copied across to the output
 >>>>> directory? -- [[Jon]]
+
+>>>>>> Without modifying ikiwiki, they'd be copied to the output directory as
+>>>>>> (e.g.) http://ikiwiki.info/templates/inlinepage.tmpl; to not copy them,
+>>>>>> it'd either be necessary to make them be internal pages
+>>>>>> (templates/inlinepage._tmpl) or special-case them in some other way.
+>>>>>> --[[smcv]]
-- 
cgit v1.2.3


From 4b4fdc85abba7200eed78eb473341e44fecc6087 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Tue, 20 Apr 2010 20:18:29 +0000
Subject: Clarifications

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 74e5bc812..a8ee6755c 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -80,9 +80,14 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t
   * Is this a field-name -> directory mapping? -- K.A.
      * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
          * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
+             * that's the idea. In your case you could have the linkbase of genre be fiction/genre, and it would be created if it was missing. -- G.B.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
      * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
          * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
+              * Actually this is about the same information appearing in different queries (e.g. NAME="FOO" and NAME="BAR"). Example: say that I defined a "Rubrica" field. I would want both tags and categories to appear in `categories` template query, but only tags would appear in the `tags` query, and only Rubrica values to appear in `rubrica` queries. The issue of different output formats was presented in the next paragraph instead. -- G.B.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
+
+One possibility could be to have the `queries` configuration allow a hash mapping query names to functions that would transform the data. Lacking that possibility, we might have to leave some predefined fields to have custom Perl-side treatment and leave custom fields to be untransformable.
+
-- 
cgit v1.2.3


From 9fa5f71034497043e2b5dbb2c40417aebd94e327 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 15:18:11 -0400
Subject: update; my branch is (partially) debugged now

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index ed681ac4d..63bcabaee 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -273,7 +273,7 @@ wrong direction.
 I've pushed an autotag branch of my own, which refactors
 things a bit. It is untested so far though. --[[Joey]]
 
-* `verify_src_file` only called from Render.pm
+* `verify_src_file` only called from Render.pm (actually, function removed)
 * Gets rid of `%del_files`.
 * Uses `%wikistate`.
 
-- 
cgit v1.2.3


From e3ea28f8c7fb9682d9e5bea32de835cee7605846 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 15:53:44 -0400
Subject: update, tag deletion bug

---
 ...uto-create_tag_pages_according_to_a_template.mdwn | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 63bcabaee..d7637ef1b 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -152,12 +152,12 @@ consider this a feature, not a bug)
 Todo/Bugs:
 
 * Will still create a page even if there's a page other than `$tag` under
-`tagbase` satisfying the tag link.
+`tagbase` satisfying the tag link. (details? --[[Joey]])
 * Call from `IkiWiki.pm` to `Render.pm`, which adds a module dependency in the
-wrong direction.
+wrong direction. (fixed --[[Joey]] )
 * Add files to RCS.
 * Unit tests.
-* Proper documentation.
+* Proper documentation. (fixed (mostly) --[[Joey]])
 
 --[[David_Riebenbauer]]
 
@@ -273,9 +273,17 @@ wrong direction.
 I've pushed an autotag branch of my own, which refactors
 things a bit. It is untested so far though. --[[Joey]]
 
-* `verify_src_file` only called from Render.pm (actually, function removed)
-* Gets rid of `%del_files`.
-* Uses `%wikistate`.
+---
+
+Known bugs in my branch (probably also in David's):
+
+* Does not remember that a tag was deleted.
+  
+  The code to do that only works if, at the same time the tag
+  is deleted, one of the pages that has the tag is modified.
+  That's because `add_autofile` needs to be called before it's
+  aware the autofile exists, and if it's not aware, it does not
+  record it as a deleted autofile.
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 6a30b45e7521f98a3e94b04ff46eeeb7f80774ca Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:07:23 -0400
Subject: update

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 28 ++++++++++++----------
 1 file changed, 15 insertions(+), 13 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index d7637ef1b..f10c2cdee 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -250,6 +250,12 @@ wrong direction. (fixed --[[Joey]] )
 >>>> Yes, I forgot about that and that is a bug. I'll fix that.
 >>>> --[[David_Riebenbauer]]
 
+>>>>> In my branch, it keeps a list of autofiles that were created,
+>>>>> not deleted. And I think that turns out to be necessary, really.
+>>>>> However, I see no way to clean out that list on deletion and
+>>>>> manual recreation -- it still needs to remember it was once an autofile,
+>>>>> in order to avoid recreating it if it's deleted yet again. --[[Joey]]
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
 
@@ -264,6 +270,13 @@ wrong direction. (fixed --[[Joey]] )
 >>>> Good suggestion. Adding the files to RCS is on my todo list anyway.
 >>>> --[[David_Riebenbauer]]
 
+>>>>> I think it may be better to allow the `add_autofile` caller
+>>>>> to specify if it is added to RCS. In my branch, it can do
+>>>>> so by just making the callback it registers call `rcs_add`; 
+>>>>> and I have tag do this. Other plugins might want autofiles
+>>>>> that do not get checked in, conceivably.
+>>>>> --[[Joey]] 
+
 > Regarding the call from `IkiWiki.pm` to `Render.pm`, wouldn't this be
 > quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
 
@@ -271,19 +284,8 @@ wrong direction. (fixed --[[Joey]] )
 
 [[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
 I've pushed an autotag branch of my own, which refactors
-things a bit. It is untested so far though. --[[Joey]]
-
----
-
-Known bugs in my branch (probably also in David's):
-
-* Does not remember that a tag was deleted.
-  
-  The code to do that only works if, at the same time the tag
-  is deleted, one of the pages that has the tag is modified.
-  That's because `add_autofile` needs to be called before it's
-  aware the autofile exists, and if it's not aware, it does not
-  record it as a deleted autofile.
+things a bit and fixes bugs around deletion/recreation.
+I've tested it somewhat. --[[Joey]]
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 760b840e8f5af9e8ea0197bda783fd9b54a8ab7c Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:19:16 -0400
Subject: update

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 1 +
 1 file changed, 1 insertion(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f10c2cdee..724a52ec9 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -281,6 +281,7 @@ wrong direction. (fixed --[[Joey]] )
 > quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
 
 >> True. I'll do that. --[[David_Riebenbauer]]
+>> Fixed in my branch --[[Joey]]
 
 [[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
 I've pushed an autotag branch of my own, which refactors
-- 
cgit v1.2.3


From b21db4197802ebd4d268b81b3df9448aa8108742 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 21 Apr 2010 20:23:19 +0000
Subject: elide an older patch that's no longer under discussion

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 81 +---------------------
 1 file changed, 1 insertion(+), 80 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f10c2cdee..e993a9aa4 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -15,86 +15,7 @@ A new setting is used to enable or disable auto-create tag pages, `tag_autocreat
 The new tag file is created during the preprocess phase. 
 The new tag file is then complied during the change phase.
 
-_tag.pm from version 3.01_
-
-
-	--- tag.pm      2009-02-06 10:26:03.000000000 -0700
-	+++ tag_new.pm  2009-02-06 12:17:19.000000000 -0700
-	@@ -14,6 +14,7 @@
-			hook(type => "preprocess", id => "tag", call => \&preprocess_tag, scan => 1);
-			hook(type => "preprocess", id => "taglink", call => \&preprocess_taglink, scan => 1);
-			hook(type => "pagetemplate", id => "tag", call => \&pagetemplate);
-	+       hook(type => "change", id => "tag", call => \&change);
-	 }
-	 
-	 sub getopt () {
-	@@ -36,6 +37,36 @@
-							safe => 1,
-							rebuild => 1,
-					},
-	+               tag_autocreate => {
-	+                       type => "boolean",
-	+                       example => 0,
-	+                       description => "Auto-create the new tag pages, uses autotagpage.tmpl ",
-	+                       safe => 1,
-	+                       rebulid => 1,
-	+               },
-	+}
-	+
-	+my $autocreated_page = 0;
-	+
-	+sub gen_tag_page($)    {
-	+       my $tag=shift;
-	+
-	+       my $tag_file=$tag.'.'.$config{default_pageext};
-	+       return if (-f $config{srcdir}.$tag_file);
-	+
-	+       my $template=template("autotagpage.tmpl");
-	+       $template->param(tag => $tag);
-	+       writefile($tag_file, $config{srcdir}, $template->output);
-	+       $autocreated_page = 1;
-	+
-	+       if ($config{rcs}) {
-	+               IkiWiki::disable_commit_hook();
-	+               IkiWiki::rcs_add($tag_file);
-	+               IkiWiki::rcs_commit_staged(
-	+                       gettext("Automatic tag page generation"),
-	+                       undef, undef);
-	+               IkiWiki::enable_commit_hook();
-	+       }
-	 }
-	 
-	 sub tagpage ($) {
-	@@ -47,6 +78,10 @@
-					$tag=~y#/#/#s; # squash dups
-			}
-	 
-	+       if (defined $config{tag_autocreate} && $config{tag_autocreate} ) {
-	+               gen_tag_page($tag);
-	+       }
-	+
-			return $tag;
-	 }
-	 
-	@@ -125,4 +160,18 @@
-			}
-	 }
-	 
-	+sub change(@) {
-	+       return unless($autocreated_page);
-	+       $autocreated_page = 0;
-	+
-	+       # This refresh/saveindex is to complie the autocreated tag pages
-	+       IkiWiki::refresh();
-	+       IkiWiki::saveindex();
-	+
-	+       # This refresh/saveindex is to fix the Tags link
-	+       # With out this additional refresh/saveindex the tag link displays ?tag
-	+       IkiWiki::refresh();
-	+       IkiWiki::saveindex();
-	+}
-	+
-
+*see git history of this page if you want the patch --[[smcv]]*
 
 This uses a [[template|wikitemplates]] called `autotagpage.tmpl`, here is my template file:
 
-- 
cgit v1.2.3


From ffe9fd8eb14cedaf31477dbce72c28dd38cc78ae Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 21 Apr 2010 20:30:14 +0000
Subject: suppressing auto-creation can be quite counter-intuitive

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index e993a9aa4..5a1aff928 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -177,6 +177,32 @@ wrong direction. (fixed --[[Joey]] )
 >>>>> manual recreation -- it still needs to remember it was once an autofile,
 >>>>> in order to avoid recreating it if it's deleted yet again. --[[Joey]]
 
+>>>>>> Are these really the semantics we want? It seems strange to me
+>>>>>> that this:
+>>>>>>
+>>>>>> * tag a page as foo
+>>>>>> * tags/foo automatically appears
+>>>>>> * delete tags/foo
+>>>>>> * create tags/foo manually
+>>>>>> * delete tags/foo again
+>>>>>> * tags/foo isn't automatically created
+>>>>>>
+>>>>>> isn't the same as this:
+>>>>>>
+>>>>>> * create tags/foo
+>>>>>> * delete tags/foo
+>>>>>> * tag a page as foo
+>>>>>> * tags/foo automatically appears
+>>>>>>
+>>>>>> or even this:
+>>>>>>
+>>>>>> * create tags/foo
+>>>>>> * tag a page as foo
+>>>>>> * delete tags/foo
+>>>>>> * tags/foo automatically appears (?)
+>>>>>>
+>>>>>> --[[smcv]]
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
 
-- 
cgit v1.2.3


From 463ba55dce0d07e97fa44500146e850f72d7ea24 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:33:03 -0400
Subject: note re includes

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index b5c107915..a112cb9da 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -35,6 +35,10 @@ suffice.
 (This would also help to clear up the tricky disctinction between
 wikitemplates and in-wiki templates.)
 
+Note also that when using templates from "$srcdir/templates/", `no_includes`
+needs to be set. Currently this is done by the two plugins that use
+such templates, while includes are allowed in `templatedir`.
+
 > But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
 
 >> It would be better for them not to be rendered separately at all.
-- 
cgit v1.2.3


From 1336a3270b664dbd548c6ad66ec981d5fa24a953 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:36:58 -0400
Subject: response

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 254ec42b5..32870dd3d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -203,6 +203,12 @@ wrong direction. (fixed --[[Joey]] )
 >>>>>>
 >>>>>> --[[smcv]]
 
+>>>>>>> I agree that the last of these is not desired. It could be avoided
+>>>>>>> by extending the list of autofiles to include those that were not
+>>>>>>> created due to the file/page already existing.
+>>>>>>> 
+>>>>>>> Hmm, that would fix the previous scenario too. --[[Joey]] 
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
 
-- 
cgit v1.2.3


From 557912c723a6e8df320a3c6dae461956cf893f10 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 20:47:18 -0400
Subject: my autotag branch seems ready

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 32870dd3d..b05e1db3d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -239,7 +239,7 @@ wrong direction. (fixed --[[Joey]] )
 [[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
 I've pushed an autotag branch of my own, which refactors
 things a bit and fixes bugs around deletion/recreation.
-I've tested it somewhat. --[[Joey]]
+I've tested it fairly thouroughly. --[[Joey]]
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 17a89d3d19f3a04ca2686ff18df127e5afaf9577 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 21:57:12 -0400
Subject: update

---
 doc/plugins/tag/discussion.mdwn                             | 1 +
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 ++
 2 files changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/plugins/tag/discussion.mdwn b/doc/plugins/tag/discussion.mdwn
index 03dcb7b2f..dfd749252 100644
--- a/doc/plugins/tag/discussion.mdwn
+++ b/doc/plugins/tag/discussion.mdwn
@@ -28,3 +28,4 @@ See [[todo/auto-create tag pages according to a template]]
 
 -- Jeremy Schultz 
 
+`tag_autocreate` can now enable this. --[[Joey]] 
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 32870dd3d..1e0a910f4 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -247,3 +247,5 @@ I've tested it somewhat. --[[Joey]]
 [da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0 (commitdiff for da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0)
 [a358d74bef51dae31332ff27e897fe04834571e6]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=a358d74bef51dae31332ff27e897fe04834571e6 (commitdiff for a358d74bef51dae31332ff27e897fe04834571e6)
 [981400177d68a279f485727be3f013e68f0bf691]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=981400177d68a279f485727be3f013e68f0bf691 (commitdiff for 981400177d68a279f485727be3f013e68f0bf691)
+
+[[!tag done]]
-- 
cgit v1.2.3


From ad296f90c3b99bb5e033f769c44e5653f518f264 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Thu, 22 Apr 2010 13:45:25 -0400
Subject: add

---
 ...dittemplate_should_look_in_templates_directory_by_default.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn b/doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn
new file mode 100644
index 000000000..4bc10e432
--- /dev/null
+++ b/doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn
@@ -0,0 +1,8 @@
+[[plugins/edittemplate]] looks for the specified template relative to the
+page the directive appears on. Which can be handy, eg, make a
+blog/mytemplate and put the directive on blog, and it will find
+"mytemplate". However, it can also be confusing, since other templates
+always are looked for in `templates/`.
+
+I think it should probably fall back to looking for `templates/$foo`.
+--[[Joey]] 
-- 
cgit v1.2.3


From 4c99904af30c9213060809937962c1a4ab9c5ad2 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Thu, 22 Apr 2010 16:29:49 -0400
Subject: reference my branch for this

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index a112cb9da..66aa07193 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -39,6 +39,9 @@ Note also that when using templates from "$srcdir/templates/", `no_includes`
 needs to be set. Currently this is done by the two plugins that use
 such templates, while includes are allowed in `templatedir`.
 
+Have started working on this.
+[[!template id=gitbranch branch=origin/templatemove author="[[Joey]]"]]
+
 > But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
 
 >> It would be better for them not to be rendered separately at all.
-- 
cgit v1.2.3


From 53c8bf9ed98f263163768daeb1d4e0fdbf6e7ef3 Mon Sep 17 00:00:00 2001
From: privat 
Date: Fri, 23 Apr 2010 17:28:38 +0000
Subject: multiple_sidebars in a gitbranch

---
 doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index 02b83244e..bb4339f88 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -15,6 +15,8 @@ those contents instead.
 
 >> Here a simple [[patch]] for multiple sidebars. Not too fancy but better than having multiple copies of the sidebar plugin. --[[jeanprivat]]
 
+>>> I made a [[git]] branch for it [[!template id=gitbranch branch="privat/multiple_sidebars" author="[[jeanprivat]]"]] --[[jeanprivat]]
+
 
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
-- 
cgit v1.2.3


From 7e79da76332b93214a7d9a5c91bc046db4219ee2 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 23 Apr 2010 16:10:46 -0400
Subject: template docu reorg

Remove wikitemplates page; fold its contents into templates page.
Update all backlinks. Document new ability to put templates inside srcdir.
---
 doc/bugs/SSI_include_stripped_from_mdwn.mdwn       |  2 +-
 doc/bugs/login_page_non-obvious_with_openid.mdwn   |  4 +-
 doc/features.mdwn                                  |  2 +-
 doc/freesoftware.mdwn                              |  2 +-
 doc/ikiwiki-calendar.mdwn                          |  2 +-
 doc/ikiwiki/directive/edittemplate.mdwn            |  2 +-
 doc/ikiwiki/directive/pagetemplate.mdwn            |  8 +-
 doc/ikiwiki/directive/template.mdwn                |  8 +-
 doc/plugins/autoindex.mdwn                         |  2 +-
 doc/plugins/map/discussion.mdwn                    |  2 +-
 doc/plugins/pagetemplate.mdwn                      |  6 +-
 doc/plugins/template.mdwn                          |  4 +-
 doc/plugins/write.mdwn                             |  4 +-
 doc/templates.mdwn                                 | 91 +++++++++++++++++++---
 doc/tips/comments_feed.mdwn                        |  2 +-
 ...o-create_tag_pages_according_to_a_template.mdwn |  2 +-
 doc/todo/auto_rebuild_on_template_change.mdwn      |  2 +-
 doc/todo/html.mdwn                                 |  2 +-
 doc/todo/multiple_templates.mdwn                   |  2 +-
 doc/usage.mdwn                                     |  5 +-
 doc/wikitemplates.mdwn                             | 52 -------------
 doc/wikitemplates/discussion.mdwn                  | 46 -----------
 22 files changed, 111 insertions(+), 141 deletions(-)
 delete mode 100644 doc/wikitemplates.mdwn
 delete mode 100644 doc/wikitemplates/discussion.mdwn

(limited to 'doc/todo')

diff --git a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
index 5519e45c6..270da86d3 100644
--- a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
+++ b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
@@ -10,7 +10,7 @@ If I have a <--#include virtual="foo" --> in some file, it gets stripped,
 > Anyway, it makes sense for the htmlscrubber to strip server-side
 > includes because otherwise your wiki could be attacked
 > by them being added to it. If you want to use both the htmlscrubber and
-> SSI together, I'd suggest you modify the [[wikitemplates]]
+> SSI together, I'd suggest you modify the [[templates]]
 > and put the SSI on there.
 > 
 > Ie, `page.tmpl` has a 
diff --git a/doc/bugs/login_page_non-obvious_with_openid.mdwn b/doc/bugs/login_page_non-obvious_with_openid.mdwn
index 1d087985a..9aa702037 100644
--- a/doc/bugs/login_page_non-obvious_with_openid.mdwn
+++ b/doc/bugs/login_page_non-obvious_with_openid.mdwn
@@ -36,7 +36,7 @@ If you want to keep it as one form, then perhaps using some javascript to disabl
 > that allows modifying that form, but does not allow creating a separate
 > form. The best way to make it obvious how to use it currently is to just
 > disable password auth, then it's nice and simple. :-) Javascript is an
-> interesting idea. It's also possible to write a custom [[signin.tmpl wikitemplates]] that
+> interesting idea. It's also possible to write a custom [[templates]] that
 > is displayed instead of the regular signin form, and it should be
 > possible to use that to manually lay it out better than FormBuilder
 > manages with its automatic layout. --[[Joey]]
@@ -44,4 +44,4 @@ If you want to keep it as one form, then perhaps using some javascript to disabl
 > I've improved the form, I think it's more obvious now that the openid
 > stuff is separate. Good enough to call this [[done]]. I think. --[[Joey]]
 
->> Looks good, thanks!  :-) -- [[AdamShand]]
\ No newline at end of file
+>> Looks good, thanks!  :-) -- [[AdamShand]]
diff --git a/doc/features.mdwn b/doc/features.mdwn
index ab521213d..07ce648ea 100644
--- a/doc/features.mdwn
+++ b/doc/features.mdwn
@@ -72,7 +72,7 @@ you would care to syndicate.
 
 Ikiwiki aims to produce 
 [valid XHTML 1.0](http://validator.w3.org/check?url=referer). Ikiwiki
-generates html using [[templates|wikitemplates]], and uses [[css]], so you
+generates html using [[templates]], and uses [[css]], so you
 can change the look and layout of all pages in any way you would like.
 
 ## [[Plugins]]
diff --git a/doc/freesoftware.mdwn b/doc/freesoftware.mdwn
index 7ac1ac6b4..2243d9b1f 100644
--- a/doc/freesoftware.mdwn
+++ b/doc/freesoftware.mdwn
@@ -4,7 +4,7 @@ ikiwiki, and this documentation wiki, are licensed under the terms of the
 GNU [[GPL]], version 2 or later.
 
 The parts of ikiwiki that become part of your own wiki (the [[basewiki]]
-pages (but not the smilies) and the [[templates|wikitemplates]]) are licensed
+pages (but not the smilies) and the [[templates]]) are licensed
 as follows: 
 
 > Redistribution and use in source and compiled forms, with or without
diff --git a/doc/ikiwiki-calendar.mdwn b/doc/ikiwiki-calendar.mdwn
index c1f4d7267..03cbdd86c 100644
--- a/doc/ikiwiki-calendar.mdwn
+++ b/doc/ikiwiki-calendar.mdwn
@@ -43,7 +43,7 @@ An example crontab:
 
 # TEMPLATES
 
-This command uses two [[template|wikitemplates]] to generate
+This command uses two [[templates]] to generate
 the pages, `calendarmonth.tmpl` and `calendaryear.tmpl`.
 
 # AUTHOR
diff --git a/doc/ikiwiki/directive/edittemplate.mdwn b/doc/ikiwiki/directive/edittemplate.mdwn
index d731bdb47..c486e821b 100644
--- a/doc/ikiwiki/directive/edittemplate.mdwn
+++ b/doc/ikiwiki/directive/edittemplate.mdwn
@@ -21,7 +21,7 @@ something like:
 	Details:
 
 The template page can also contain [[!cpan HTML::Template]] directives,
-similar to other ikiwiki [[templates]]. Currently only one variable is
+like other ikiwiki [[templates]]. Currently only one variable is
 set: `` is replaced with the name of the page being
 created.
 
diff --git a/doc/ikiwiki/directive/pagetemplate.mdwn b/doc/ikiwiki/directive/pagetemplate.mdwn
index 8ad901c1a..401b38099 100644
--- a/doc/ikiwiki/directive/pagetemplate.mdwn
+++ b/doc/ikiwiki/directive/pagetemplate.mdwn
@@ -1,17 +1,13 @@
 The `pagetemplate` directive is supplied by the [[!iki plugins/pagetemplate desc=pagetemplate]] plugin.
 
-This directive allows a page to be displayed using a different template than
-the default `page.tmpl` template.
+This directive allows a page to be displayed using a different
+[[template|templates]] than the default `page.tmpl` template.
 
 The page text is inserted into the template, so the template controls the
 overall look and feel of the wiki page. This is in contrast to the
 [[ikiwiki/directive/template]] directive, which allows inserting templates
 _into_ the body of a page.
 
-This directive can only reference templates that are already installed
-by the system administrator, typically into the
-`/usr/share/ikiwiki/templates` directory. Example:
-
 	\[[!pagetemplate template="my_fancy.tmpl"]]
 
 [[!meta robots="noindex, follow"]]
diff --git a/doc/ikiwiki/directive/template.mdwn b/doc/ikiwiki/directive/template.mdwn
index ae71ba5b5..052ca7873 100644
--- a/doc/ikiwiki/directive/template.mdwn
+++ b/doc/ikiwiki/directive/template.mdwn
@@ -1,7 +1,11 @@
 The `template` directive is supplied by the [[!iki plugins/template desc=template]] plugin.
 
-[[Templates]] are files that can be filled out and inserted into pages in the
-wiki, by using the template directive. The directive has an `id` parameter
+The template directive allows wiki pages to be used as templates.
+These templates can be filled out and inserted into other pages in the
+wiki using the directive. The [[templates]] page lists templates
+that can be used with this directive.
+
+The directive has an `id` parameter
 that identifies the template to use. The remaining parameters are used to
 fill out the template.
 
diff --git a/doc/plugins/autoindex.mdwn b/doc/plugins/autoindex.mdwn
index d1133e4f5..7c4e40419 100644
--- a/doc/plugins/autoindex.mdwn
+++ b/doc/plugins/autoindex.mdwn
@@ -3,5 +3,5 @@
 
 This plugin searches for [[SubPages|ikiwiki/subpage]] with a missing parent
 page, and generates the parent pages. The generated page content is
-controlled by the `autoindex.tmpl` [[template|wikitemplates]], which by
+controlled by the `autoindex.tmpl` [[template|templates]], which by
 default, uses a [[map]] to list the SubPages.
diff --git a/doc/plugins/map/discussion.mdwn b/doc/plugins/map/discussion.mdwn
index 2f7b140d6..54c921b0f 100644
--- a/doc/plugins/map/discussion.mdwn
+++ b/doc/plugins/map/discussion.mdwn
@@ -1,7 +1,7 @@
 I'm wanting a [[map]] (with indentation levels) showing page _titles_
 instead of page 'names'.  As far as I can see, this is not an option with
 existing plugins - I can get a list of pages using [[inline]] and
-appropriate [[wikitemplates]], but that has no indentation and therefore
+appropriate [[templates]], but that has no indentation and therefore
 doesn't show structure well.
 
 The quick way is to modify the map plugin to have a 'titles' option.  The
diff --git a/doc/plugins/pagetemplate.mdwn b/doc/plugins/pagetemplate.mdwn
index 53f069d0d..8254e14c5 100644
--- a/doc/plugins/pagetemplate.mdwn
+++ b/doc/plugins/pagetemplate.mdwn
@@ -3,8 +3,4 @@
 
 This plugin provides the [[ikiwiki/directive/pagetemplate]]
 [[ikiwiki/directive]], which allows a page to be displayed
-using a different [[template|wikitemplates]] than the default.
-
-This plugin can only use templates that are already installed in
-`/usr/share/ikiwiki/templates` (or wherever ikiwiki is configured to look for
-them). You can choose to use any .tmpl files in that directory.
+using a different [[template|templates]] than the default.
diff --git a/doc/plugins/template.mdwn b/doc/plugins/template.mdwn
index da775f232..8d17e2825 100644
--- a/doc/plugins/template.mdwn
+++ b/doc/plugins/template.mdwn
@@ -3,5 +3,5 @@
 
 This plugin provides the [[ikiwiki/directive/template]] [[ikiwiki/directive]].
 With this plugin, you can set up templates, and cause them to be filled out
-and inserted into pages in the wiki. It's documented and existing templates
-are listed in the [[templates]] page.
+and inserted into pages in the wiki. Existing templates are listed in the
+[[templates]] page.
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 00b54bdd3..9128c7f54 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -297,7 +297,7 @@ value is ignored.
 
 	hook(type => "pagetemplate", id => "foo", call => \&pagetemplate);
 
-[[Templates|wikitemplates]] are filled out for many different things in
+[[Templates]] are filled out for many different things in
 ikiwiki, like generating a page, or part of a blog page, or an rss feed, or
 a cgi. This hook allows modifying the variables available on those
 templates. The function is passed named parameters. The "page" and
@@ -313,7 +313,7 @@ a new custom parameter to the template.
 
 	hook(type => "templatefile", id => "foo", call => \&templatefile);
 
-This hook allows plugins to change the [[template|wikitemplates]] that is
+This hook allows plugins to change the [[template|templates]] that is
 used for a page in the wiki. The hook is passed a "page" parameter, and
 should return the name of the template file to use (relative to the
 template directory), or undef if it doesn't want to change the default
diff --git a/doc/templates.mdwn b/doc/templates.mdwn
index f2b581d2f..f7b3adae5 100644
--- a/doc/templates.mdwn
+++ b/doc/templates.mdwn
@@ -1,17 +1,88 @@
-[[!meta robots="noindex, follow"]]
-[[!if test="enabled(template)"
-then="This wiki has templates **enabled**."
-else="This wiki has templates **disabled**."
-]]
+[[Ikiwiki]] uses many templates for many purposes. By editing its templates,
+you can fully customise this site.
 
-Templates are files that can be filled out and inserted into pages in the
-wiki.
+[[!if test="enabled(template)" then="""
+## The template directive
 
+The template directive allows wiki pages to be used as templates.
+These templates can be filled out and inserted into other pages in the
+wiki using the directive.
+"""]]
 [[!if test="enabled(template) and enabled(inline)" then="""
-
-These templates are available for use with the template directive.
-
 [[!inline pages="templates/* and !*/discussion" feeds=no archive=yes
 sort=title template=titlepage
 rootpage=templates postformtext="Add a new template named:"]]
 """]]
+
+[[!if test="enabled(edittemplate)" then="""
+## The edittemplate directive
+
+The edittemplate directive can be used to make new pages default to
+containing text from a template, which can be filled as out the page is
+edited.
+"""]]
+
+## Wiki templates
+
+These templates are used to build the wiki. The aim is to keep almost all
+html out of ikiwiki and in the templates.
+
+* `page.tmpl` - Used for displaying all regular wiki pages.
+* `misc.tmpl` - Generic template used for any page that doesn't
+  have a custom template.
+* `editpage.tmpl` - Create/edit page.
+* `change.tmpl` - Used to create a page describing a change made to the wiki.
+* `passwordmail.tmpl` - Not a html template, this is used to
+  generate a mail with an url the user can use to reset their password.
+* `rsspage.tmpl` - Used for generating rss feeds for [[blogs|blog]].
+* `rssitem.tmpl` - Used for generating individual items on rss feeds.
+* `atompage.tmpl` - Used for generating atom feeds for blogs.
+* `atomitem.tmpl` - Used for generating individual items on atom feeds.
+* `inlinepage.tmpl` - Used for adding a page inline in a blog
+  page.
+* `archivepage.tmpl` - Used for listing a page in a blog archive page.
+* `microblog.tmpl` - Used for showing a microblogging post inline.
+* `blogpost.tmpl` - Used for a form to add a post to a blog (and a rss/atom links)
+* `feedlink.tmpl` - Used to add rss/atom links if blogpost.tmpl is not used.
+* `aggregatepost.tmpl` - Used by the [[plugins/aggregate]] plugin to create
+  a page for a post.
+* `searchform.tmpl` - Used by the [[plugins/search]] plugin to add a search
+  form to wiki pages.
+* `searchquery.tmpl` - This is an omega template, used by the
+  [[plugins/search]] plugin.
+* `comment.tmpl` - This template is used to display a comment
+  by the [[plugins/comments]] plugin.
+* `editcomment.tmpl` - This template is the comment post form for the
+  [[plugins/comments]] plugin.
+* `commentmoderation.tmpl` - This template is used to produce the comment
+  moderation form.
+* `recentchanges.tmpl` - This template is used for listing a change
+  on the RecentChanges page.
+
+[[!if test="enabled(pagetemplate)" then="""
+## The pagetemplate directive
+
+The pagetemplate directive can allow individual pages to use a
+different template than `page.tmpl`.
+"""]]
+
+## Template locations
+
+Templates are located in `/usr/share/ikiwiki/templates` by default;
+the `templatedir` setting can be used to make another directory be
+searched first. Customized templates can also be placed inside the
+"templates/" directory in your wiki's source.
+
+## Template syntax
+
+Ikiwiki uses the HTML::Template module as its template engine. This
+supports things like conditionals and loops in templates and is pretty easy
+to learn. All you really need to know are a few things:
+
+* To insert the value of a template variable, use ``.
+* To make a block of text conditional on a variable being set use
+  `text`.
+* To use one block of text if a variable is set and a second if it's not,
+  use `textother text`
+
+[[!meta robots="noindex, follow"]]
diff --git a/doc/tips/comments_feed.mdwn b/doc/tips/comments_feed.mdwn
index 6f8137256..6d4dbb803 100644
--- a/doc/tips/comments_feed.mdwn
+++ b/doc/tips/comments_feed.mdwn
@@ -6,5 +6,5 @@ add a feed that contains all the comments posted to any page. Here's how:
 	\[[!inline pages="internal(*/comment_*)" template=comment]]
 
 The special [[ikiwiki/PageSpec]] matches all comments. The
-[[template|wikitemplates]] causes the comments to be displayed formatted
+[[template|templates]] causes the comments to be displayed formatted
 nicely.
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f6d444890..7eb404910 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -17,7 +17,7 @@ The new tag file is then complied during the change phase.
 
 *see git history of this page if you want the patch --[[smcv]]*
 
-This uses a [[template|wikitemplates]] called `autotagpage.tmpl`, here is my template file:
+This uses a [[template|templates]] called `autotagpage.tmpl`, here is my template file:
 
     \[[!inline pages="link()" archive="yes"]]
 
diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index a112cb9da..838d15c1a 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -6,7 +6,7 @@ This would allow setting:
 
 	templatedir => "$srcdir/templates",
 
-.. and then the [[wikitemplates]] are managed like other wiki files; and
+.. and then the [[templates]] are managed like other wiki files; and
 like other wiki files, a change to them automatically updates dependent
 pages.
 
diff --git a/doc/todo/html.mdwn b/doc/todo/html.mdwn
index 44f20c876..4f4542be2 100644
--- a/doc/todo/html.mdwn
+++ b/doc/todo/html.mdwn
@@ -1,6 +1,6 @@
 Create some nice(r) stylesheets.
 
 Should be doable w/o touching a single line of code, just
-editing the [[wikitemplates]] and/or editing [[style.css]].
+editing the [[templates]] and/or editing [[style.css]].
 
 [[done]] ([[css_market]] ..)
diff --git a/doc/todo/multiple_templates.mdwn b/doc/todo/multiple_templates.mdwn
index 72783c556..30fb8d6ee 100644
--- a/doc/todo/multiple_templates.mdwn
+++ b/doc/todo/multiple_templates.mdwn
@@ -1,4 +1,4 @@
-> Another useful feature might be to be able to choose a different [[template|wikitemplates]]
+> Another useful feature might be to be able to choose a different [[template|templates]]
 > file for some pages; [[blog]] pages would use a template different from the
 > home page, even if both are managed in the same repository, etc.
 
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index 2e12517ea..9cf61cc6c 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -120,10 +120,11 @@ also be configured using a setup file.
 
 * --templatedir dir
 
-  Specify the directory that the page [[templates|wikitemplates]] are stored in.
+  Specify the directory that [[templates|templates]] are stored in.
   Default is `/usr/share/ikiwiki/templates`, or another location as configured at
   build time. If the templatedir is changed, missing templates will still
-  be searched for in the default location as a fallback.
+  be searched for in the default location as a fallback. Templates can also be
+  placed in the "templates/" subdirectory of the srcdir.
 
   Note that if you choose to copy and modify ikiwiki's templates, you will need
   to be careful to keep them up to date when upgrading to new versions of
diff --git a/doc/wikitemplates.mdwn b/doc/wikitemplates.mdwn
deleted file mode 100644
index 6e5a7261d..000000000
--- a/doc/wikitemplates.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-ikiwiki uses the HTML::Template module as its template engine. This
-supports things like conditionals and loops in templates and is pretty easy
-to learn.
-
-The aim is to keep almost all html out of ikiwiki and in the templates.
-
-It ships with some basic templates which can be customised. These are
-located in `/usr/share/ikiwiki/templates` by default; the `templatedir`
-setting can be used to make another directory be searched first.
-
-* `page.tmpl` - Used for displaying all regular wiki pages.
-* `misc.tmpl` - Generic template used for any page that doesn't
-  have a custom template.
-* `editpage.tmpl` - Create/edit page.
-* `change.tmpl` - Used to create a page describing a change made to the wiki.
-* `passwordmail.tmpl` - Not a html template, this is used to
-  generate a mail with an url the user can use to reset their password.
-* `rsspage.tmpl` - Used for generating rss feeds for [[blogs|blog]].
-* `rssitem.tmpl` - Used for generating individual items on rss feeds.
-* `atompage.tmpl` - Used for generating atom feeds for blogs.
-* `atomitem.tmpl` - Used for generating individual items on atom feeds.
-* `inlinepage.tmpl` - Used for adding a page inline in a blog
-  page.
-* `archivepage.tmpl` - Used for listing a page in a blog archive page.
-* `microblog.tmpl` - Used for showing a microblogging post inline.
-* `blogpost.tmpl` - Used for a form to add a post to a blog (and a rss/atom links)
-* `feedlink.tmpl` - Used to add rss/atom links if blogpost.tmpl is not used.
-* `aggregatepost.tmpl` - Used by the [[plugins/aggregate]] plugin to create
-  a page for a post.
-* `searchform.tmpl` - Used by the [[plugins/search]] plugin to add a search
-  form to wiki pages.
-* `searchquery.tmpl` - This is an omega template, used by the
-  [[plugins/search]] plugin.
-* `comment.tmpl` - This template is used to display a comment
-  by the [[plugins/comments]] plugin.
-* `editcomment.tmpl` - This template is the comment post form for the
-  [[plugins/comments]] plugin.
-* `commentmoderation.tmpl` - This template is used to produce the comment
-  moderation form.
-* `recentchanges.tmpl` - This template is used for listing a change
-  on the RecentChanges page.
-
-The [[plugins/pagetemplate]] plugin can allow individual pages to use a
-different template than `page.tmpl`.
-
-The [[plugins/template]] plugin also uses templates, though those
-[[templates]] are typically stored as pages in the wiki, and are inserted
-into pages.
-
-The [[plugins/edittemplate]] plugin is used to make new pages default to
-containing text from a template, which can be filled as out the page is
-edited.
diff --git a/doc/wikitemplates/discussion.mdwn b/doc/wikitemplates/discussion.mdwn
deleted file mode 100644
index f97444e5f..000000000
--- a/doc/wikitemplates/discussion.mdwn
+++ /dev/null
@@ -1,46 +0,0 @@
-## Place for local templates
-Where does one put any locally modified templates for an individual ikiwiki? --Ivan Z.
-
-> You can put them whereever you like; the `templatedir` controls
-> where ikiwiki looks for them. --[[Joey]] 
-
-Thank you for your response! My question arose out of my intention to make
-custom templates for a wiki--specifically suited for the kind of  content
-it will have--so, that would mean I would want to distribute them through
-git together with other content of the wiki. So, for this case the
-separation of conceptually ONE thing (the content, the templates, and the
-config option which orders to use these templates) into THREE separate
-files/repos (the main content repo, the repo with templates, and the config
-file) is not convenient: instead of distributing a single repo, I have to
-tell people to take three things if they want to replicate this wiki. How
-would you solve this inconvenience? Perhaps, a default location of the
-templates *inside* the source repo would do?--Ivan Z.
-
-> I would avoid putting the templates in a subdirectory of the ikiwiki srcdir.
-> (I'd also avoid putting the ikiwiki setup file there.)
-> While it's safe to do either in some cases, there are configurations where
-> it's unsafe. For example, a malicious user could use attachment handling to
-> replace those files with their own, bad versions.
-> 
-> So, two ideas for where to put the templatedir and ikiwiki setup. 
-
-> * The easiest option is to put your wiki content in a subdirectory
->   ("wiki", say) and point `srcdir` at that.
->   then you can have another subdirectory for the wikitemplates,
->   and put the setup file at the top.
-> * Another option if using git would be to have a separate branch,
->   in the same git repository, that holds wikitemplates and the setup file.
->   Then you check out the repository once to make the `srcdir` available,
->   and have a second checkout, of the other branch, to make the other stuff
->   available.
-> 
-> Note that with either of these methods, you have to watch out if
-> giving other direct commit access to the repository. They could
-> still edit the setup file and templates, so only trusted users should
-> be given access. (It is, however, perfectly safe to let people edit
-> the wiki via the web, and is even safe to configure
-> [[tips/untrusted_git_push]] to such a repository.) --[[Joey]]
-
-Thanks, that's a nice and simple idea: to have a subdirectory! I'll try it. --Ivan Z.
-
-A [[!taglink wish|wishlist]]: the ikiwiki program could be improved so that it follows the same logic as git in looking for its config: it could ascend directories until it finds an `.ikiwiki/` directory with `.ikiwiki/setup` and then uses that configuration. Now I'm tired to always type `ikiwiki --setup path/to/the/setup --refresh` when working in my working clone of the sources; I'd like to simply type `ikiwiki` instead, and let it find the setup file. The default location to look for templates could also be made to be a sibling of the setup file: `.ikiwiki/templates/`. --Ivan Z.
-- 
cgit v1.2.3


From d5c5fef363564261ccba236f1d64eaa60567d514 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 23 Apr 2010 16:48:37 -0400
Subject: update

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 66aa07193..037d0d1db 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -62,3 +62,15 @@ Have started working on this.
 >>>>>> it'd either be necessary to make them be internal pages
 >>>>>> (templates/inlinepage._tmpl) or special-case them in some other way.
 >>>>>> --[[smcv]]
+
+>>>>>>> In my branch, I left in support for the templatedir, and also
+>>>>>>> /usr/share/ikiwiki/templates. So, users do not have to put their
+>>>>>>> custom templates in templates/ in the wiki. If they do, 
+>>>>>>> the templates are copied to the destdir like other non-wiki page files
+>>>>>>> are. The templates are not wiki pages, except those used by a few
+>>>>>>> things like the [[plugins/template]] plugin.
+>>>>>>> 
+>>>>>>> That seems acceptable, since users probably don't need to modify
+>>>>>>> many templates, so the clutter is small. (Especially when
+>>>>>>> compared to the other clutter the basewiki always puts in destdir.)
+>>>>>>> This could be revisted later. --[[Joey]] 
-- 
cgit v1.2.3


From 6c64ce0336240be16eeae81313e53c630cb196bc Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 23 Apr 2010 17:01:22 -0400
Subject: update news for template change

---
 debian/NEWS                                   | 32 +++++++++++++++++++--------
 doc/todo/auto_rebuild_on_template_change.mdwn |  2 ++
 template-transition-notes                     |  4 ----
 3 files changed, 25 insertions(+), 13 deletions(-)
 delete mode 100644 template-transition-notes

(limited to 'doc/todo')

diff --git a/debian/NEWS b/debian/NEWS
index 3a8705680..69967c84c 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -2,22 +2,36 @@ ikiwiki (3.20100422) unstable; urgency=low
 
   This version of ikiwiki has a lot of changes that you need to know about.
 
+  Now you can include customised versions of templates in the source
+  of your wiki. (For example, templates/page.tmpl.) When these templates
+  are changed, ikiwiki will automatically rebuild pages that use them.
+
   The --getctime switch is renamed to --gettimes, and it also gets the 
   file modification time. And it's a lot faster (when using git). But
   the really important change is, you don't have to remember to use this
   switch. Now ikiwiki will do it when it needs to.
 
-  Starting from this version, the "tagged()" pagespec only matches tags,
-  not regular wikilinks. If your wiki accidentially relied on the old,
-  buggy behavior, you might need to change its pagespecs to use "link()".
+  At last, the "tagged()" pagespec only matches tags, not regular wikilinks.
+  If your wiki accidentially relied on the old, buggy behavior, you might
+  need to change its pagespecs to use "link()".
+
+  Many of your wishes have been answered: Now tag pages can automatically be
+  created when new tags are used. This feature is enabled by default if you
+  have configured a tagbase. It can be turned on or off using the
+  tag_autocreate setting.
+
+  These changes may also affect some users:
+
+  * The title_natural sort method (as used by the inline directive, etc)
+    have been moved to the new sortnaturally plugin, which is not enabled
+    by default since it requires the Sort::Naturally perl module.
 
-  Now tag pages can automatically be created as new tags are used. This
-  feature is enabled by default if you have configured a tagbase. It
-  can be turned on or off using the tag_autocreate setting.
+  * TMPL_INCLUDE is no longer supported in any template used by ikiwiki.
+    It used to be allowed in certian templates, but not in others.
 
-  The title_natural sort method (as used by the inline directive, etc)
-  have been moved to the new sortnaturally plugin, which is not enabled
-  by default since it requires the Sort::Naturally perl module.
+  * The add_templates option has been removed from the underlay plugin.
+    If you used this option, you can instead use templates/ subdirectories
+    inside underlay directories added by the add_underlays option.
 
   Due to the above and other changes, all wikis need to be rebuilt on
   upgrade to this version. If you listed your wiki in /etc/ikiwiki/wikilist
diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 192b22f70..ea990b877 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -74,3 +74,5 @@ Have started working on this.
 >>>>>>> many templates, so the clutter is small. (Especially when
 >>>>>>> compared to the other clutter the basewiki always puts in destdir.)
 >>>>>>> This could be revisted later. --[[Joey]] 
+
+[[done]]
diff --git a/template-transition-notes b/template-transition-notes
deleted file mode 100644
index a319616f4..000000000
--- a/template-transition-notes
+++ /dev/null
@@ -1,4 +0,0 @@
-* add_templates option removed from underlay plugin
-  (can use add_underlays instead)
-* includes no longer allowed in templates
-* template_params removed (not exported API)
-- 
cgit v1.2.3


From 0a139aba823ece3166d29ff2daee0b5c9507b52f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 1 May 2010 18:27:53 -0400
Subject: htmlscrubber: Allow the html5 form attributes: placeholder autofocus,
 min, max, step.

---
 IkiWiki/Plugin/htmlscrubber.pm                     | 5 +++--
 debian/changelog                                   | 3 ++-
 doc/todo/Add_label_to_search_form_input_field.mdwn | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/htmlscrubber.pm b/IkiWiki/Plugin/htmlscrubber.pm
index b3f659f73..479e10e74 100644
--- a/IkiWiki/Plugin/htmlscrubber.pm
+++ b/IkiWiki/Plugin/htmlscrubber.pm
@@ -101,8 +101,9 @@ sub scrubber {
 				tabindex target title type valign
 				value vspace width
 
-				autoplay preload loopstart loopend end
-				playcount controls pubdate placeholder
+				autofocus autoplay preload loopstart
+				loopend end playcount controls pubdate
+				placeholder min max step
 			} ),
 			"/" => 1, # emit proper 
 XHTML
 			href => $safe_url_regexp,
diff --git a/debian/changelog b/debian/changelog
index 951caab9e..12ef08a91 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -10,7 +10,8 @@ ikiwiki (3.20100428) UNRELEASED; urgency=low
   * htmlscrubber: Also allow html5 canvas tags.
   * htmlscrubber: Round out html5 video support with the preload
     attribute and the source tag.
-  * htmlscrubber: Allow the placeholder attribute.
+  * htmlscrubber: Allow the html5 form attributes: placeholder autofocus,
+    min, max, step.
 
  -- Joey Hess   Tue, 27 Apr 2010 12:10:51 -0400
 
diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn
index 51b34927d..281ab48e2 100644
--- a/doc/todo/Add_label_to_search_form_input_field.mdwn
+++ b/doc/todo/Add_label_to_search_form_input_field.mdwn
@@ -51,4 +51,4 @@ The patch below adds a label for the field to improve usability:
 > element. already works in eg, chromium. However, ikiwiki does not use
 > html5 yet. --[[Joey]] 
 
-[[!tag wishlist html5]]
+[[!tag wishlist bugs/html5_support]]
-- 
cgit v1.2.3


From b21df5029b94c5680d8a3e5f0c1ed40a660a1594 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 2 May 2010 13:49:56 -0400
Subject: Add placeholder text in search form (in html5 mode only).

---
 IkiWiki/Plugin/google.pm                           | 1 +
 IkiWiki/Plugin/search.pm                           | 1 +
 debian/changelog                                   | 1 +
 doc/bugs/html5_support.mdwn                        | 3 ---
 doc/todo/Add_label_to_search_form_input_field.mdwn | 2 ++
 templates/googleform.tmpl                          | 3 ++-
 templates/searchform.tmpl                          | 3 ++-
 7 files changed, 9 insertions(+), 5 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/google.pm b/IkiWiki/Plugin/google.pm
index 85467fa0b..68cde261c 100644
--- a/IkiWiki/Plugin/google.pm
+++ b/IkiWiki/Plugin/google.pm
@@ -42,6 +42,7 @@ sub pagetemplate (@) {
 		if (! defined $form) {
 			my $searchform = template("googleform.tmpl", blind_cache => 1);
 			$searchform->param(url => $config{url});
+			$searchform->param(html5 => $config{html5});
 			$form=$searchform->output;
 		}
 
diff --git a/IkiWiki/Plugin/search.pm b/IkiWiki/Plugin/search.pm
index be39fdf1e..9e875c79c 100644
--- a/IkiWiki/Plugin/search.pm
+++ b/IkiWiki/Plugin/search.pm
@@ -58,6 +58,7 @@ sub pagetemplate (@) {
 		if (! defined $form) {
 			my $searchform = template("searchform.tmpl", blind_cache => 1);
 			$searchform->param(searchaction => $config{cgiurl});
+			$searchform->param(html5 => $config{html5});
 			$form=$searchform->output;
 		}
 
diff --git a/debian/changelog b/debian/changelog
index 8158429a0..c9fc2e657 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ ikiwiki (3.20100502) UNRELEASED; urgency=low
 
   * Add parameter to displaytime to specify that it is a pubdate,
     and in html5 mode, use time tag.
+  * Add placeholder text in search form (in html5 mode only).
 
  -- Joey Hess   Sun, 02 May 2010 13:22:50 -0400
 
diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn
index 386a3094a..5530b29db 100644
--- a/doc/bugs/html5_support.mdwn
+++ b/doc/bugs/html5_support.mdwn
@@ -64,11 +64,8 @@ HTML5](http://www.w3.org/TR/html5-diff/).
 > 
 > Other ideas:
 > 
-> * Add pubdate attribute to time elements as appropriate.
 > * Use aside for the sidebar? Or for the [[templates/note]] template?
 > * Use nav for the actionbar
-> * Use placeholder in the search box. Allows closing
->   [[this_todo|Add_label_to_search_form_input_field]]
 > * Use details tag instead of the javascript in the toggle plugin. 
 >   (Need to wait on browser support probably.)
 > 
diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn
index 281ab48e2..514108fba 100644
--- a/doc/todo/Add_label_to_search_form_input_field.mdwn
+++ b/doc/todo/Add_label_to_search_form_input_field.mdwn
@@ -51,4 +51,6 @@ The patch below adds a label for the field to improve usability:
 > element. already works in eg, chromium. However, ikiwiki does not use
 > html5 yet. --[[Joey]] 
 
+>> [[Done]], placeholder added, in html5 mode only.
+
 [[!tag wishlist bugs/html5_support]]
diff --git a/templates/googleform.tmpl b/templates/googleform.tmpl
index bcf1004a4..f39b46540 100644
--- a/templates/googleform.tmpl
+++ b/templates/googleform.tmpl
@@ -1,6 +1,7 @@
 

  

   
-  
+  placeholder="search" />
  

 

diff --git a/templates/searchform.tmpl b/templates/searchform.tmpl
index afae2ebf5..cb65d124c 100644
--- a/templates/searchform.tmpl
+++ b/templates/searchform.tmpl
@@ -1,5 +1,6 @@
 

 

-
+placeholder="search" />
 

 

-- 
cgit v1.2.3


From d5928778a89762b73ed6f4ddaec690d14d774537 Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Tue, 4 May 2010 02:26:56 +0200
Subject: whishlist about two-way conversion.

---
 doc/todo/two-way_convert_of_wikis.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 doc/todo/two-way_convert_of_wikis.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/two-way_convert_of_wikis.mdwn b/doc/todo/two-way_convert_of_wikis.mdwn
new file mode 100644
index 000000000..61f02a30b
--- /dev/null
+++ b/doc/todo/two-way_convert_of_wikis.mdwn
@@ -0,0 +1,15 @@
+
+[[!tag wishlist]]
+
+Ok, the vision is this: Some of you will know git-svn. I want something like
+git-svn,, but for wikis. I want to be able to do the following:
+
+1. Convert a moinmoin (or whatever) wiki to a local ikiwiki on my laptop.
+2. Edit my local copy (offline).
+3. Preview the changes with my local ikiwki installation + browser.
+4. Push the changes back to moinmoin (or whatever) wiki.
+
+I know, I know, ikiwiki wasn't designed for that, but it would be really cool,
+and useful and people ask for that kind of thing too.
+
+--[[David_Riebenbauer]]
-- 
cgit v1.2.3


From 3f925ac7351bcee9a8cbbcae881681e68087de50 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Thu, 6 May 2010 17:28:47 -0400
Subject: new todo

---
 doc/todo/comment_moderation_feed.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 doc/todo/comment_moderation_feed.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/comment_moderation_feed.mdwn b/doc/todo/comment_moderation_feed.mdwn
new file mode 100644
index 000000000..267706b1b
--- /dev/null
+++ b/doc/todo/comment_moderation_feed.mdwn
@@ -0,0 +1,9 @@
+There should be a way to generate a feed that is updated whenever a new
+comment needs moderation. Otherwise, it can be hard to remember to check
+sites, which may rarely get comments.
+
+The feed should not include the comment subject or body, but could mention
+the author. It would be especially handy if it was generated statically.
+One way would be to generate internal pages corresponding to each comment
+that needs moderation; then the feed could be constructed via a usual
+inline.
-- 
cgit v1.2.3


From 4bb245df90965898b3e572d67c4fda25b0be84c5 Mon Sep 17 00:00:00 2001
From: Changaco 
Date: Mon, 17 May 2010 16:46:28 +0000
Subject:

---
 doc/todo/multiple_template_directories.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn
index c09a9595f..6d1632b4c 100644
--- a/doc/todo/multiple_template_directories.mdwn
+++ b/doc/todo/multiple_template_directories.mdwn
@@ -11,3 +11,5 @@ ought to do the trick.
 > global dir when it cannot find a template. For me, this is good enough.
 > And it is even documented in the man page. Sigh. I guess this could be 
 > considered [[done]].  
+
+I have a use case for this, a site composed of blogs and wikis, templates divided in three categories : common, blog and wiki. The only solution I found is maintaining hard links, being able to have multiple template dirs would obviously be better. -- Changaco
-- 
cgit v1.2.3


From f864b74859d8b0197f59d7dfe7d45063dc887cd1 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Mon, 17 May 2010 17:34:40 +0000
Subject: an example of somewhere where the old functionality is actually
 needed

---
 doc/todo/multiple_template_directories.mdwn | 32 +++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn
index 6d1632b4c..0f8f5c880 100644
--- a/doc/todo/multiple_template_directories.mdwn
+++ b/doc/todo/multiple_template_directories.mdwn
@@ -13,3 +13,35 @@ ought to do the trick.
 > considered [[done]].  
 
 I have a use case for this, a site composed of blogs and wikis, templates divided in three categories : common, blog and wiki. The only solution I found is maintaining hard links, being able to have multiple template dirs would obviously be better. -- Changaco
+
+> [[plugins/underlay]] used to allow adding extra templatedirs, but Joey
+> removed that functionality when he made templates search the wiki's
+> own `templates` directory.
+>
+> You can get a 3-level hierarchy like this:
+>
+> * instance-specific overrides: $srcdir/templates
+> * common to the entire site: a directory that is the value of all
+>   instances' `templatedir` parameters
+> * common to every ikiwiki in the world: /usr/share/ikiwiki/templates
+>   (implicitly searched)
+>
+> (by "instance" I mean an instance of ikiwiki - a .setup file, basically.)
+>
+> For a more complex hierarchy you'd need the old [[plugins/underlay]]
+> functionality, i.e. you'd need to (ask Joey to) revert the patch that
+> removed it. For instance, if anyone has a hierarchy like this, then
+> they need the old functionality back in order to split the template
+> search path for the things marked `(???)`:
+>
+>     every ikiwiki in the world (/usr/share/ikiwiki/templates)
+>     \--- your site (???)
+>         \--- your blogs (???)
+>              \--- travel blog ($srcdir/templates)
+>              \--- code blog ($srcdir/templates)
+>         \--- your wikis (???)
+>              \--- travel wiki ($srcdir/templates)
+>              \--- code wiki ($srcdir/templates)
+>
+> This looks pretty hypothetical to me, though...
+> --[[smcv]]
-- 
cgit v1.2.3


From 5e515605749684f5867857885043b4e25378a374 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 17 May 2010 15:42:20 -0400
Subject: new todo

---
 doc/todo/anon_push_of_comments.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)
 create mode 100644 doc/todo/anon_push_of_comments.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/anon_push_of_comments.mdwn b/doc/todo/anon_push_of_comments.mdwn
new file mode 100644
index 000000000..bb5d04670
--- /dev/null
+++ b/doc/todo/anon_push_of_comments.mdwn
@@ -0,0 +1,6 @@
+It should be possible to use anonymous git push to post comments
+(created, say, by a ikiwiki-comment program). Currently, that is not
+allowed, because users cannot edit, or create internal page files.
+But, comments in allowed locations are an exception to that rule, and 
+that exception should be communicated somehow to `IkiWiki::Receive`.
+--[[Joey]] 
-- 
cgit v1.2.3


From 3298902443128f68e21f4ad349a7a3a9e0f03bce Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 17 May 2010 15:46:07 -0400
Subject: response

---
 doc/todo/multiple_template_directories.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn
index 0f8f5c880..fe1951d51 100644
--- a/doc/todo/multiple_template_directories.mdwn
+++ b/doc/todo/multiple_template_directories.mdwn
@@ -45,3 +45,8 @@ I have a use case for this, a site composed of blogs and wikis, templates divide
 >
 > This looks pretty hypothetical to me, though...
 > --[[smcv]]
+
+>> The reason I removed it is because the same functionality of having
+>> multiple template directories is still present. Just put them in 
+>> the templates/ subdirectory of multiple underlay directories instead.
+>> --[[Joey]]
-- 
cgit v1.2.3


From 533c8e62c5043e8e10dbd6203bb1a5ebe8a0d87e Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 17 May 2010 15:55:17 -0400
Subject: why this is hard..

---
 doc/todo/anon_push_of_comments.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/anon_push_of_comments.mdwn b/doc/todo/anon_push_of_comments.mdwn
index bb5d04670..b472ea13f 100644
--- a/doc/todo/anon_push_of_comments.mdwn
+++ b/doc/todo/anon_push_of_comments.mdwn
@@ -4,3 +4,11 @@ allowed, because users cannot edit, or create internal page files.
 But, comments in allowed locations are an exception to that rule, and 
 that exception should be communicated somehow to `IkiWiki::Receive`.
 --[[Joey]] 
+
+> Complications include: 
+> 
+> * Hard to see a way to prevent users from committing a comment that
+>   claims to be written by someone else.
+> * `checkcontent` hooks need to be run, but can't accept a comment
+>   for later moderation, since it's coming in as part of a commit.
+>   Best they could do is reject the commit.
-- 
cgit v1.2.3


From 47bc6105326ce76327f2accb6d6ae34d2cb1429e Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Mon, 17 May 2010 22:46:23 +0200
Subject: please pull

---
 doc/todo/allow_displaying_number_of_comments.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 doc/todo/allow_displaying_number_of_comments.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/allow_displaying_number_of_comments.mdwn b/doc/todo/allow_displaying_number_of_comments.mdwn
new file mode 100644
index 000000000..8e479bc85
--- /dev/null
+++ b/doc/todo/allow_displaying_number_of_comments.mdwn
@@ -0,0 +1,9 @@
+My `numcomments` Git branch adds a `NUMCOMMENTS` `TMPL_VAR`, which is
+useful to add to the `forumpage.tmpl` template to emulate (the nice
+bits of) a more usual webforum.
+
+Please review... and pull :)
+
+-- [[intrigeri]]
+
+[[patch]]
-- 
cgit v1.2.3


From 2b1bc9c7297dc4bf36f4fc91205ad13eaf1513ca Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 17 May 2010 17:13:53 -0400
Subject: review

---
 doc/todo/allow_displaying_number_of_comments.mdwn | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_displaying_number_of_comments.mdwn b/doc/todo/allow_displaying_number_of_comments.mdwn
index 8e479bc85..7e8802210 100644
--- a/doc/todo/allow_displaying_number_of_comments.mdwn
+++ b/doc/todo/allow_displaying_number_of_comments.mdwn
@@ -5,5 +5,23 @@ bits of) a more usual webforum.
 Please review... and pull :)
 
 -- [[intrigeri]]
+ 
+> How is having this variable for showing a count of the comments 
+> better (or more forum-ish) than the COMMENTSLINK variable which
+> includes a count and a link to the comments, and is already displayed
+> in inlinepage.tmpl?
+> 
+> `num_comments` will never return undef.
+> 
+> I see no need to add a second pagetemplate hook.
+> The existing one can be added to. Probably inside its `if ($shown)`
+> block.
+> 
+> It may also be a good idea to either combine the calls to `num_comments`
+> used for this and for the commentslink, 
+> or to memoize it. I'm thinking generally memoizing it may be a good idea
+> since the comments for a page will typically be counted twice when it's
+> inlined.
+> --[[Joey]] 
 
 [[patch]]
-- 
cgit v1.2.3


From 1f974b3517b3601e5014fcb0a383f980b4953a8c Mon Sep 17 00:00:00 2001
From: Changaco 
Date: Mon, 17 May 2010 23:36:16 +0000
Subject: problem solved

---
 doc/todo/multiple_template_directories.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn
index fe1951d51..b8b9651b9 100644
--- a/doc/todo/multiple_template_directories.mdwn
+++ b/doc/todo/multiple_template_directories.mdwn
@@ -50,3 +50,5 @@ I have a use case for this, a site composed of blogs and wikis, templates divide
 >> multiple template directories is still present. Just put them in 
 >> the templates/ subdirectory of multiple underlay directories instead.
 >> --[[Joey]]
+
+>>>Thanks, I didn't realize this was possible. Problem solved. -- Changaco
-- 
cgit v1.2.3


From 284038fbbf09a55ae23ebeca03f8ff4487ce7ef6 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 18 May 2010 09:23:23 +0000
Subject: tag as done

---
 doc/todo/multiple_template_directories.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn
index b8b9651b9..6a474b4f3 100644
--- a/doc/todo/multiple_template_directories.mdwn
+++ b/doc/todo/multiple_template_directories.mdwn
@@ -52,3 +52,22 @@ I have a use case for this, a site composed of blogs and wikis, templates divide
 >> --[[Joey]]
 
 >>>Thanks, I didn't realize this was possible. Problem solved. -- Changaco
+
+>>>> We can consider this [[done]], then. For reference, the solution
+>>>> to the hierarchy I mentioned above would be:
+>>>>
+>>>>     all your sites have $your_underlay as an underlay
+>>>>
+>>>>     the blogs and wikis all have $blog_underlay or $wiki_underlay
+>>>>     (as appropriate) as a higher priority underlay
+>>>>
+>>>>     every ikiwiki in the world (/usr/share/ikiwiki/templates)
+>>>>     \--- your site ($your_underlay/templates, or templatedir)
+>>>>         \--- your blogs ($blog_underlay/templates)
+>>>>              \--- travel blog ($srcdir/templates)
+>>>>              \--- code blog ($srcdir/templates)
+>>>>         \--- your wikis ($wiki_underlay/templates)
+>>>>              \--- travel wiki ($srcdir/templates)
+>>>>              \--- code wiki ($srcdir/templates)
+>>>>
+>>>> --[[smcv]]
-- 
cgit v1.2.3


From 529141779fe8492defbfa3e879c15bc81b3907dd Mon Sep 17 00:00:00 2001
From: intrigeri 
Date: Tue, 18 May 2010 16:11:45 +0200
Subject: response

---
 doc/todo/allow_displaying_number_of_comments.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_displaying_number_of_comments.mdwn b/doc/todo/allow_displaying_number_of_comments.mdwn
index 7e8802210..02d55fc9b 100644
--- a/doc/todo/allow_displaying_number_of_comments.mdwn
+++ b/doc/todo/allow_displaying_number_of_comments.mdwn
@@ -25,3 +25,6 @@ Please review... and pull :)
 > --[[Joey]] 
 
 [[patch]]
+
+>> Well, the COMMENTSLINK variable fits my needs. Sorry for
+>> the disturbance. [[done]] --[[intrigeri]]
-- 
cgit v1.2.3


From 1bce0656755344977e020a985c4c06479f035f77 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Wed, 19 May 2010 11:36:30 +0000
Subject: new versions which address some of these issues

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 10 ++++++++++
 1 file changed, 10 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index a8ee6755c..3e9f8feaa 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -91,3 +91,13 @@ Where this approach is limiting is on the kind of data that is passed to (templa
 
 One possibility could be to have the `queries` configuration allow a hash mapping query names to functions that would transform the data. Lacking that possibility, we might have to leave some predefined fields to have custom Perl-side treatment and leave custom fields to be untransformable.
 
+-----
+
+I've now updated the [[plugins/contrib/field]] plugin to have:
+
+* arrays (multi-valued fields)
+* the "linkbase" option as mentioned above (called field_tags), where the linktype is the field name.
+
+I've also updated [[plugins/contrib/ftemplate]] and [[plugins/contrib/report]] to be able to use multi-valued fields, and [[plugins/contrib/ymlfront]] to correctly return multi-valued fields when they are requested.
+
+--[[KathrynAndersen]]
-- 
cgit v1.2.3


From b6d00070a556e68d8e79eb5d64fe7a5ad2dbda18 Mon Sep 17 00:00:00 2001
From: nil 
Date: Fri, 11 Jun 2010 02:45:14 +0000
Subject: use the ikiwiki userdb outside of the ikiwiki edition access control

---
 doc/todo/htpasswd_mirror_of_the_userdb.mdwn | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)
 create mode 100644 doc/todo/htpasswd_mirror_of_the_userdb.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/htpasswd_mirror_of_the_userdb.mdwn b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn
new file mode 100644
index 000000000..0582a6f7a
--- /dev/null
+++ b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn
@@ -0,0 +1,17 @@
+[[!tag wishlist]]
+
+Ikiwiki is static, so access control for viewing the wiki must be implemented on the web server side. Managing wiki users and access together, we can currently
+
+* use [[httpauth|plugins/httpauth/]], but some [[passwordauth|plugins/passwordauth]] functionnality [[is missing|todo/httpauth_feature_parity_with_passwordauth/]];
+* use [[passwordauth|plugins/passwordauth]] plus [[an Apache `mod_perl` authentication mechanism|plugins/passwordauth/discussion/]], but this is Apache-centric and enabling `mod_perl` just for auth seems overkill.
+
+Moreover, when ikiwiki is just a part of a wider web project, we may want to use the same userdb for the other parts of this project.
+
+I think an ikiwiki plugin which would (re)generate an htpasswd version of the user/passwd base (better, two htpasswd files, one with only the wiki admins and one with everyone) each time an user is added or modified would solve this problem:
+
+* access control can be managed from the web server
+* user management is handled by the passwordauth plugin
+* htpasswd format is understood by various servers (Apache, lighttpd, nginx, ...) and languages commonly used for web development (perl, python, ruby)
+* htpasswd files can be mirrored on other machines when the web site is distributed
+
+-- [[nil]] 
-- 
cgit v1.2.3


From f9dc2bf8598033c2bc74229073323d97fe83e50a Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 14 Jun 2010 14:14:43 -0400
Subject: good idea

---
 doc/todo/htpasswd_mirror_of_the_userdb.mdwn | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/htpasswd_mirror_of_the_userdb.mdwn b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn
index 0582a6f7a..e4a411780 100644
--- a/doc/todo/htpasswd_mirror_of_the_userdb.mdwn
+++ b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn
@@ -1,13 +1,19 @@
 [[!tag wishlist]]
 
-Ikiwiki is static, so access control for viewing the wiki must be implemented on the web server side. Managing wiki users and access together, we can currently
+Ikiwiki is static, so access control for viewing the wiki must be
+implemented on the web server side. Managing wiki users and access
+together, we can currently
 
 * use [[httpauth|plugins/httpauth/]], but some [[passwordauth|plugins/passwordauth]] functionnality [[is missing|todo/httpauth_feature_parity_with_passwordauth/]];
 * use [[passwordauth|plugins/passwordauth]] plus [[an Apache `mod_perl` authentication mechanism|plugins/passwordauth/discussion/]], but this is Apache-centric and enabling `mod_perl` just for auth seems overkill.
 
-Moreover, when ikiwiki is just a part of a wider web project, we may want to use the same userdb for the other parts of this project.
+Moreover, when ikiwiki is just a part of a wider web project, we may want
+to use the same userdb for the other parts of this project.
 
-I think an ikiwiki plugin which would (re)generate an htpasswd version of the user/passwd base (better, two htpasswd files, one with only the wiki admins and one with everyone) each time an user is added or modified would solve this problem:
+I think an ikiwiki plugin which would (re)generate an htpasswd version of
+the user/passwd base (better, two htpasswd files, one with only the wiki
+admins and one with everyone) each time an user is added or modified would
+solve this problem:
 
 * access control can be managed from the web server
 * user management is handled by the passwordauth plugin
@@ -15,3 +21,9 @@ I think an ikiwiki plugin which would (re)generate an htpasswd version of the us
 * htpasswd files can be mirrored on other machines when the web site is distributed
 
 -- [[nil]] 
+
+> I think this is a good idea. Although unless the password hashes that
+> are stored in the userdb are compatible with htpasswd hashes, 
+> the htpasswd hashes will need to be stored in the userdb too. Then
+> any userdb change can just regenerate the htpasswd file, dumping out
+> the right kind of hashes. --[[Joey]] 
-- 
cgit v1.2.3


From b3e8115c95c79859c2893ac73e9f0bab0db31594 Mon Sep 17 00:00:00 2001
From: "http://www.openid.albertlash.com/openid/"
 
Date: Fri, 18 Jun 2010 20:47:31 +0000
Subject:

---
 doc/todo/Google_Sitemap_protocol.mdwn | 10 ++++++++++
 1 file changed, 10 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 057a88b72..6657c9350 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -45,3 +45,13 @@ On [Google Webmaster tools](https://www.google.com/webmasters/tools) you can sub
 [Google should grok feeds as sitemaps.](http://www.google.com/support/webmasters/bin/answer.py?answer=34654) Or rather [[plugins/inline]] should be improved to support the [sitemap protocol](http://sitemaps.org/protocol.php) natively.
 
 -- [[Hendry]]
+
+
+Took me a minute to figure this out so I figured I'd share the steps I took:
+
+* Added rss=>1 and allowrss=>1 to my setup file
+* Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
+
+
+\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+

-- 
cgit v1.2.3


From 4833f486b6ca759e1bcd8acc19e13ef4a0a6063f Mon Sep 17 00:00:00 2001
From: "http://www.openid.albertlash.com/openid/"
 
Date: Fri, 18 Jun 2010 20:48:10 +0000
Subject: don't need to escape the inline tag if its in pre tag

---
 doc/todo/Google_Sitemap_protocol.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 6657c9350..12ac8d036 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -53,5 +53,5 @@ Took me a minute to figure this out so I figured I'd share the steps I took:
 * Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
 
 
-\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+[[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
 

-- 
cgit v1.2.3


From 22478de2cb9d843e3444e0f39bac850d372887f1 Mon Sep 17 00:00:00 2001
From: privat 
Date: Tue, 22 Jun 2010 13:30:50 +0000
Subject:

---
 doc/todo/auto_publish_expire.mdwn | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 doc/todo/auto_publish_expire.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/auto_publish_expire.mdwn b/doc/todo/auto_publish_expire.mdwn
new file mode 100644
index 000000000..6f767a693
--- /dev/null
+++ b/doc/todo/auto_publish_expire.mdwn
@@ -0,0 +1,10 @@
+It could be nice to mark some page such that:
+
+* the page is automatically published on some date (i.e. build, linked, syndicated, inlined/mapped, etc.)
+* the page is automatically unpublished at some other date (i.e. removed)
+
+I know that ikiwiki is a wiki compiler so that something has to refresh the wiki periodically to enforce the rules (a cronjob for instance). It seems to me that the calendar plugin rely on something similar.
+
+The date for publishing and expiring could be set be using some new directives; an alternative could be to expand the [[plugin/meta]] plugin with [[!meta date="auto publish date"]] and [[!meta expires="auto expire date"]].
+
+--[[JeanPrivat]]
-- 
cgit v1.2.3


From cfc1c4e933b8ba77bc6c3adb60fcea40721c0a61 Mon Sep 17 00:00:00 2001
From: privat 
Date: Tue, 22 Jun 2010 15:10:59 +0000
Subject: ping

---
 doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index bb4339f88..8c689294a 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -17,6 +17,8 @@ those contents instead.
 
 >>> I made a [[git]] branch for it [[!template id=gitbranch branch="privat/multiple_sidebars" author="[[jeanprivat]]"]] --[[jeanprivat]]
 
+>>>> Ping for [[Joey]]. Do you have any comment? I could improve it if there is things you do not like. I prefer to have such a feature integrated upstream. --[[JeanPrivat]]
+
 
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
-- 
cgit v1.2.3


From bbbbf04f76dc5eb6824e5efd5f0ca128e32430ce Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 13:12:43 -0400
Subject: thoughts

---
 doc/todo/auto_publish_expire.mdwn | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_publish_expire.mdwn b/doc/todo/auto_publish_expire.mdwn
index 6f767a693..7a5a17517 100644
--- a/doc/todo/auto_publish_expire.mdwn
+++ b/doc/todo/auto_publish_expire.mdwn
@@ -8,3 +8,26 @@ I know that ikiwiki is a wiki compiler so that something has to refresh the wiki
 The date for publishing and expiring could be set be using some new directives; an alternative could be to expand the [[plugin/meta]] plugin with [[!meta date="auto publish date"]] and [[!meta expires="auto expire date"]].
 
 --[[JeanPrivat]]
+
+> This is a duplicate, and expansion, of
+> [[todo/tagging_with_a_publication_date]].
+> There, I suggest using a branch to develop
+> prepublication versions of a site, and merge from it
+> when the thing is published. 
+> 
+> Another approach I've seen used is to keep such pages in a pending/
+> directory, and move them via cron job when their publication time comes.
+> But that requires some familiarity with, and access to, cron.
+> 
+> On [[todo/tagging_with_a_publication_date]], I also suggested using meta 
+> date to set a page's date into the future,
+> and adding a pagespec that matches only pages with dates in the past,
+> which would allow filtering out the unpublished ones.
+> Sounds like you are thinking along these lines, but possibly using
+> something other than the page's creation or modification date to do it.
+> 
+> I do think the general problem with that approach is that you have to be
+> careful to prevent the unpublished pages from leaking out in any
+> inlines, maps, etc. --[[Joey]] 
+
+[[!tag wishlist]]
-- 
cgit v1.2.3


From 16ff593ab78409fc3c2482aeb2903e9a3d83b581 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 13:16:31 -0400
Subject: Revert "don't need to escape the inline tag if its in pre tag"

This reverts commit 4833f486b6ca759e1bcd8acc19e13ef4a0a6063f.

Being in a pre does not stop an inline directive from working.
---
 doc/todo/Google_Sitemap_protocol.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 12ac8d036..6657c9350 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -53,5 +53,5 @@ Took me a minute to figure this out so I figured I'd share the steps I took:
 * Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
 
 
-[[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
 

-- 
cgit v1.2.3


From 9b845ea8132f5677c7466b8747333afba54017b9 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 13:17:33 -0400
Subject: one slash is enough to escape

---
 doc/todo/Google_Sitemap_protocol.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 6657c9350..2cf7c61e3 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -53,5 +53,5 @@ Took me a minute to figure this out so I figured I'd share the steps I took:
 * Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
 
 
-\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+\[[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
 

-- 
cgit v1.2.3


From 6235167962e65733f8a120edba394a77d684278f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 13:29:46 -0400
Subject: response

---
 .../beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn   | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index 8c689294a..1f7b48764 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -19,6 +19,21 @@ those contents instead.
 
 >>>> Ping for [[Joey]]. Do you have any comment? I could improve it if there is things you do not like. I prefer to have such a feature integrated upstream. --[[JeanPrivat]]
 
+>>>>> The code is fine.
+>>>>>
+>>>>> I did think about having it examine
+>>>>> the `page.tmpl` for parameters with names like `FOO_SIDEBAR`
+>>>>> and automatically enable page `foo` as a sidebar in that case,
+>>>>> instead of using the setup file to enable. But I'm not sure about
+>>>>> that idea..
+>>>>> 
+>>>>> The full compliment of sidebars would be a header, a footer,
+>>>>> a left, and a right sidebar. It would make sense to go ahead
+>>>>> and add the parameters to `page.tmpl` so enabling each just works,
+>>>>> and add whatever basic CSS makes sense. Although I don't know
+>>>>> if I want to try to get a 3 column CSS going, so perhaps leave the
+>>>>> left sidebar out of that.
+
 
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
-- 
cgit v1.2.3


From e32bce464305fd8314d8324169a2079516548faf Mon Sep 17 00:00:00 2001
From: BerndZeimetz 
Date: Wed, 23 Jun 2010 18:44:52 +0000
Subject: It is possible to use google-sitemapgen to create google sitemaps for
 ikiwiki.

---
 doc/todo/Google_Sitemap_protocol.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 2cf7c61e3..ea8ee7f03 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -34,6 +34,9 @@ for an example.  You will probably need to strip out the metadata variables I
 >>>[xtermin.us rather than localhost](http://xtermin.us/git/?p=website.git;a=blob;f=plugins/googlesitemap.pm) is 404 now.
 >>> -- weakish
 
+
+Although it is not able to read the meta-data from files, using google-sitemapgen [works well for me](http://bzed.de/posts/2010/06/creating_a_google_sitemap_for_ikiwiki/) to create a sitemap for my ikiwiki installation. -- [[bzed|BerndZeimetz]]
+
 There is a [sitemap XML standard](http://www.sitemaps.org/protocol.php) that ikiwiki needs to generate for. 
 
 # Google Webmaster tools and RSS
-- 
cgit v1.2.3


From a4f381ace837a032bc202cc6b2a98e922d4b7cfc Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 19:44:41 -0400
Subject: git: Record the username from openid in the git author email. (This
 avoids display of ugly google openids.)

---
 IkiWiki/Plugin/git.pm                        |  5 +++++
 debian/changelog                             |  2 ++
 doc/rcs.mdwn                                 | 20 +++++++++++++-------
 doc/todo/Separate_OpenIDs_and_usernames.mdwn |  3 +++
 4 files changed, 23 insertions(+), 7 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm
index 85368606e..3e289e0c3 100644
--- a/IkiWiki/Plugin/git.pm
+++ b/IkiWiki/Plugin/git.pm
@@ -506,6 +506,11 @@ sub rcs_commit_staged (@) {
 		if (defined $u) {
 			$u=encode_utf8($u);
 			$ENV{GIT_AUTHOR_NAME}=$u;
+		}
+		if (defined $params{session}->param("username")) {
+			$u=encode_utf8($params{session}->param("username"));
+		}
+		if (defined $u) {
 			$ENV{GIT_AUTHOR_EMAIL}="$u\@web";
 		}
 	}
diff --git a/debian/changelog b/debian/changelog
index 88ed3a90b..dfa862e5b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ ikiwiki (3.20100624) UNRELEASED; urgency=low
     parameters.
   * Fixed some confusion and bugginess about whether
     rcs_getctime/rcs_getmtime were passed absolute or relative filenames.
+  * git: Record the username from openid in the git author email.
+    (This avoids display of ugly google openids.)
 
  -- Joey Hess   Wed, 23 Jun 2010 15:30:04 -0400
 
diff --git a/doc/rcs.mdwn b/doc/rcs.mdwn
index 248d93024..83c6910d0 100644
--- a/doc/rcs.mdwn
+++ b/doc/rcs.mdwn
@@ -10,13 +10,8 @@ generic that it can be adapted to work with many systems by writing a
 
 While all supported revision control systems work well enough for basic
 use, some advanced or special features are not supported in all of them.
-Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to
-set up a wiki using that revision control system. The `rcs_commit_staged`
-hook is needed to use [[attachments|plugins/attachment]] or
-[[plugins/comments]]. `rcs_getctime` may be implemented in a fast way
-(ie, one log lookup for all files), or very slowly (one lookup per file).
-And so on. The table below summarises this for each revision control
-system and links to more information about each.
+The table below summarises this for each revision control system and
+links to more information about each.
 
 [[!table data="""
 feature             |[[git]]|[[svn]]|[[bzr]]   |[[monotone]]|[[mercurial]]|[[darcs]]|[[tla]]   |[[cvs]]
@@ -30,7 +25,18 @@ auto.setup          |yes    |yes    |incomplete|yes         |incomplete   |yes
 `rcs_getmtime`      |fast   |slow   |slow      |no          |no           |no       |no        |no
 anonymous push      |yes    |no     |no        |no          |no           |no       |no        |no
 conflict handling   |yes    |yes    |yes       |buggy       |yes          |yes      |yes       |yes
+openid username     |yes    |no     |no        |no          |no           |no       |no        |no
 """]]
 
+Notes:
+
+* Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to
+  set up a wiki using that revision control system.
+* The `rcs_commit_staged` hook is needed to use [[attachments|plugins/attachment]]
+  or [[plugins/comments]].
+* `rcs_getctime` and `rcs_getmtime` may be implemented in a fast way (ie, one log
+  lookup for all files), or very slowly (one lookup per file).
+* Openid username support allows avoiding display of Google's ugly openids.
+
 There is a page with [[details]] about how the different systems work with
 ikiwiki, for the curious.
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index fcdb49f6d..60b7b6c61 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -38,10 +38,13 @@ A slightly more complex next step would be to request sreg from the provider and
 > * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
 >   instead of just a userid. (For back-compat, if the parameter is 
 >   not an object, it's a userid.) Bump ikiwiki plugin interface version.
+>   (done)
 > * Modify all RCS plugins to include the session username somewhere
 >   in the commit, and parse it back out in `rcs_recentchanges`.
+>   (done for git only so far)
 > * Modify recentchanges plugin to display the username instead of the
 >   `openiduser`.
+>   (done)
 > * Modify comment plugin to put the session username in the comment
 >   template instead of the `openiduser`.
 
-- 
cgit v1.2.3


From 9a2c56b748ec9cd9230abada56267bde1840ca39 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 20:21:44 -0400
Subject: openid nickname support finished; closing

---
 doc/todo/Separate_OpenIDs_and_usernames.mdwn | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 60b7b6c61..a4940220a 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -46,8 +46,8 @@ A slightly more complex next step would be to request sreg from the provider and
 >   `openiduser`.
 >   (done)
 > * Modify comment plugin to put the session username in the comment
->   template instead of the `openiduser`.
+>   template instead of the `openiduser`. (done)
 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 
-[[!tag wishlist]]
+[[!tag wishlist done]]
-- 
cgit v1.2.3


From 71950b2ae5ff6fd3b631c5504455cc07699b1c11 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Fri, 25 Jun 2010 02:40:25 +0000
Subject: sidebars defined by pagespec perhaps?

---
 ..._up_sidebar_to_allow_for_multiple_sidebars.mdwn | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index 1f7b48764..fdaa09f26 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -34,6 +34,8 @@ those contents instead.
 >>>>> if I want to try to get a 3 column CSS going, so perhaps leave the
 >>>>> left sidebar out of that.
 
+-------------------
+
 
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
@@ -85,4 +87,39 @@ those contents instead.
  }
 

 
+----------------------------------------
+## Further thoughts about this
+
+(since the indentation level was getting rather high.)
+
+What about using pagespecs in the config to map pages and sidebar pages together?  Something like this:
+
+
+	sidebar_pagespec => {
+	    "foo/*" => 'sidebars/foo_sidebar',
+	    "bar/* and !bar/*/*' => 'bar/bar_top_sidebar',
+	    "* and !foo/* and !bar/*" => 'sidebars/general_sidebar',
+	},
+

+
+One could do something similar for *pageheader*, *pagefooter* and *rightbar* if desired.
+
+Another thing which I find compelling - but probably because I am using [[plugins/contrib/field]] - is to be able to treat the included page as if it were *part* of the page it was included into, rather than as an included page.  I mean things like \[[!if ...]] would test against the page name of the page it's included into rather than the name of the sidebar/header/footer page.  It's even more powerful if one combines this with field/getfield/ftemplate/report, since one could make "generic" headers and footers that could apply to a whole set of pages.
+
+Header example:
+
+#{{$title}}
+\[[!ftemplate id="nice_data_table"]]
+

+
+Footer example:
+
+------------
+\[[!report template="footer_trail" trail="trailpage" here_only=1]]
+

+
+(Yes, I am already doing something like this on my own site.  It's like the PmWiki concept of GroupHeader/GroupFooter)
+
+-- [[KathrynAndersen]]
+
 [[!tag wishlist]]
-- 
cgit v1.2.3