Merge branch 'master' into po

Conflicts:
	debian/changelog

29 files changed, 346 insertions, 24 deletions

diff --git a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn
index 8ecdf36d0..e5ac391c3 100644
--- a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn
+++ b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn
@@ -83,4 +83,4 @@ regenerate this one against that).
 	-- 
 	1.5.2.2
 
-[[!tag patch]]
+[[!tag patch patch/core plugins/inline]]
diff --git a/doc/todo/Add_space_before_slash_in_parent_links.mdwn b/doc/todo/Add_space_before_slash_in_parent_links.mdwn
index 40a334032..9eb8e5364 100644
--- a/doc/todo/Add_space_before_slash_in_parent_links.mdwn
+++ b/doc/todo/Add_space_before_slash_in_parent_links.mdwn
@@ -8,6 +8,11 @@ This [[patch]] adds a space before the forward-slash in the the parent links. Th
 
 >>> Yes, please.  This seems to be something a lot of people want to customize.  (I certainly do -- a forward slash only looks natural to Unix users)  --[[sabr]]
 
+>> Joey, would I be right to summarize your position on this as "people who
+>> want to change the text of the templates should maintain their own version
+>> of the `.tmpl` files"? It's not clear to me how this todo item could be
+>> closed in a way acceptable to you, except perhaps as WONTFIX. --[[smcv]]
+
 Before:
 
     ikiwiki/ todo/ Add space before slash in parent links
diff --git a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn
index 5b9cc8742..17f45dda6 100644
--- a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn
+++ b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn
@@ -67,3 +67,15 @@ Patch:
 >>> Adding a new `canlogin` hook looks like overkill to me.  [[Joey]], how
 >>> about making registration of the `auth` hook mandatory for all plugins
 >>> making sense of the "Preferences" link? --[[Lunar]]
+
+>>>> Hmm, using the `auth` hook existance does seem like a nice solution.
+>>>> While splitting the preferences code out into its own plugin is
+>>>> easily enough done, it has the minor problem of being yet another
+>>>> file nearly all ikiwikis will have to load, and also, prefs would
+>>>> have to be disabled manually. So I like that using the hook would
+>>>> cause it to auto-disable if nothing uses it. It's a bit ugly that
+>>>> passwordauth doesn't need an auth hook (it could be reorged to
+>>>> use it instead of formbuilder, maybe) and would probably just have an
+>>>> empty one. Thanks for the idea. --[[Joey]]  [[done]]
+
+>>>>> Thanks for implementing it! --[[Lunar]]
diff --git a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn
index 95c38f794..bf8de16cd 100644
--- a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn
+++ b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn
@@ -1,5 +1,8 @@
 This patch adds function bestdir() which returns best directory from the directory structure. This is in addition to the bestlink() function which is there in IkiWiki.pm 
 
+> Um, what is this for? :-) It would probably be a lot easier to review if it
+> had documentation, and/or a plugin that used it. --[[smcv]]
+
 -------
 
     Index: IkiWiki.pm
@@ -45,4 +48,4 @@ This patch adds function bestdir() which returns best directory from the directo
 ---- 
 -[[users/arpitjain]]
 
-[[!tag patch]]
+[[!tag patch patch/core]]
diff --git a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn
index 89167c084..4bc828e6e 100644
--- a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn
+++ b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn
@@ -1,4 +1,4 @@
-[[!tag patch]]
+[[!tag patch plugins/calendar]]
 
 Here's my next version of the patch - still a work in progress.
 
diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
new file mode 100644
index 000000000..492a8d747
--- /dev/null
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -0,0 +1,73 @@
+[[!tag plugins/meta patch]]
+
+I'd like to define [[plugins/meta]] values to apply across all pages
+site-wide unless the pages define their own: default values for meta
+definitions essentially.
+
+Here's a patch to achieve this (also in the "defaultmeta" branch of
+my github ikiwiki fork):
+
+    diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm
+    index b229592..3132257 100644
+    --- a/IkiWiki/Plugin/meta.pm
+    +++ b/IkiWiki/Plugin/meta.pm
+    @@ -13,6 +13,7 @@ sub import {
+     	hook(type => "needsbuild", id => "meta", call => \&needsbuild);
+     	hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1);
+     	hook(type => "pagetemplate", id => "meta", call => \&pagetemplate);
+    +	hook(type => "scan", id => "meta", call => \&scan);
+     }
+     
+     sub getsetup () {
+    @@ -302,6 +303,15 @@ sub match {
+     	}
+     }
+     
+    +sub scan() {
+    +	my %params = @_;
+    +	my $page = $params{page};
+    +    foreach my $type (map { s/^meta_//; $_ } grep /^meta_/, keys %config) {
+    +		$pagestate{$page}{meta}{$type} = $config{"meta_$type"}
+    +			unless defined $pagestate{$page}{meta}{$type};
+    +	}
+    +}
+    +
+     package IkiWiki::PageSpec;
+     
+     sub match_title ($$;@) {
+    diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn
+    index 000f461..200c4b2 100644
+    --- a/doc/ikiwiki/directive/meta.mdwn
+    +++ b/doc/ikiwiki/directive/meta.mdwn
+    @@ -12,6 +12,12 @@ also specifies some additional sub-parameters.
+     The field values are treated as HTML entity-escaped text, so you can include
+     a quote in the text by writing `"` and so on.
+     
+    +You can also define site-wide defaults for meta values by including them
+    +in your setup file, e.g.
+    +
+    +	meta_copyright => "Copyright 2007 by Joey Hess",
+    +	meta_license   => "GPL v2+",
+    +
+     Supported fields:
+     
+     * title
+
+-- [[Jon]]
+
+> This doesn't support multiple-argument meta directives like
+> `link=x rel=y`, or meta directives with special side-effects like
+> `updated`.
+>
+> The first could be solved (if you care) by a syntax like this:
+>
+>     meta_defaults => [
+>         { copyright => "© me" },
+>         { link => "about:blank", rel => "silly", },
+>     ]
+>
+> The second could perhaps be solved by invoking `meta::preprocess` from within
+> `scan` (which might be a simplification anyway), although this is complicated
+> by the fact that some (but not all!) meta headers are idempotent.
+> 
+> --[[smcv]]
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 f60fc3d6e..f1d33114f 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: <http://madduck.net/blog/2008.01.06:new-blog/> and <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/autocreatetagpage/>
 
-[[!tag wishlist]]
+[[!tag wishlist plugins/tag patch]]
 
 I would love to see this as well. -- dato
 
diff --git a/doc/todo/backlinks_result_is_lossy.mdwn b/doc/todo/backlinks_result_is_lossy.mdwn
new file mode 100644
index 000000000..7b64a4f2c
--- /dev/null
+++ b/doc/todo/backlinks_result_is_lossy.mdwn
@@ -0,0 +1,10 @@
+[[!tag patch patch/core]]
+
+IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a
+lossy transformation (to get it in the form that page templates want), making
+it more difficult to use in other contexts (like pagestats).
+
+A commit on my `among` branch splits it into IkiWiki::backlink_pages
+(which returns the keys of $backlinks{$page}, and might be suitable for
+exporting) and IkiWiki::backlinks (which calls backlink_pages, then performs
+the same lossy transformation as before on the result).
diff --git a/doc/todo/blogpost_plugin.mdwn b/doc/todo/blogpost_plugin.mdwn
index bb91ffd02..69df27271 100644
--- a/doc/todo/blogpost_plugin.mdwn
+++ b/doc/todo/blogpost_plugin.mdwn
@@ -153,4 +153,4 @@ Index: IkiWiki.pm
  our $version='unknown'; # VERSION_AUTOREPLACE done by Makefile, DNE
 </pre>
 
-[[!tag patch]]
+[[!tag patch patch/core]]
diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn
index e3b295123..e302a49ed 100644
--- a/doc/todo/enable-htaccess-files.mdwn
+++ b/doc/todo/enable-htaccess-files.mdwn
@@ -12,7 +12,7 @@
                     qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//],
            wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/,
 
-[[!tag patch]]
+[[!tag patch patch/core]]
 
 This lets the site administrator have a `.htaccess` file in their underlay
 directory, say, then get it copied over when the wiki is built. Without
@@ -39,6 +39,13 @@ access and such .htaccess files should not be accessible through wiki cgi. Of co
 
 > See [[!debbug 447267]] for a patch for this.
 
+>> It looks to me as though this functionality won't be included in ikiwiki
+>> unless someone who wants it takes responsibility for updating the patch
+>> from that Debian bug to be applicable to current versions, so that there's a
+>> setup file parameter for extra filenames to allow, defaulting to none
+>> (i.e. a less simplistic patch than the one at the top of this page).
+>> Joey, is this an accurate summary? --[[smcv]]
+
 ---
 
 bump! I would like to see some form of this functionality included in ikiwiki. I use a patched version, but
@@ -47,4 +54,8 @@ but I use ikiwiki with a very small group of people collaborating so svn/web acc
 and htaccess is for limiting access to some areas of wiki.   
 It should be off by default of course. --Max
 
-[[!tag patch]]
+---
++1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]]
+
+---
++1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]]
diff --git a/doc/todo/format_escape.mdwn b/doc/todo/format_escape.mdwn
index 574883d1b..762f16646 100644
--- a/doc/todo/format_escape.mdwn
+++ b/doc/todo/format_escape.mdwn
@@ -97,7 +97,7 @@ I've created an updated [patch](http://www.idletheme.org/code/patches/ikiwiki-fo
 --Ryan Koppenhaver
 
 ## Original patch
-[[!tag patch]]
+[[!tag patch patch/core plugins/rst]]
 
 <pre>
 Index: debian/changelog
diff --git a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn
index a6a6ec1e1..7cf37fbb9 100644
--- a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn
+++ b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn
@@ -12,7 +12,7 @@ while the default stays as it is now.
 > INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not
 > adding new variables where MakeMaker already has them. --[[Joey]]
 
-[[!tag patch]]
+[[!tag patch patch/core]]
 
 <pre>
 
diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn
new file mode 100644
index 000000000..336ae38d6
--- /dev/null
+++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn
@@ -0,0 +1,14 @@
+A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds
+the following parameter to the [[ikiwiki/directive/inline]] directive:
+
+> * `pagenames` - If given instead of `pages`, this is interpreted as a
+>    space-separated list of links to pages (with the same
+>   [[ikiwiki/SubPage/LinkingRules]] as in a [[ikiwiki/WikiLink]]), and they are inlined
+>   in exactly the order given: the `sort` and `pages` parameters cannot be used
+>   in conjunction with this one.
+
+This is on my [[wishlist]] for my [[plugins/contrib/album]] plugin, which currently
+uses it internally (as it has already collected the pages in order). It could also
+be useful for other things, like [[todo/wikitrails]]. --[[smcv]]
+
+[[!tag plugins/inline]]
diff --git a/doc/todo/inline_postform_autotitles.mdwn b/doc/todo/inline_postform_autotitles.mdwn
index 5005208be..b3366f60e 100644
--- a/doc/todo/inline_postform_autotitles.mdwn
+++ b/doc/todo/inline_postform_autotitles.mdwn
@@ -1,5 +1,4 @@
-[[!tag wishlist]]
-[[!tag patch]]
+[[!tag wishlist patch plugins/inline]]
 
 for postforms in inlines of pages which follow a certain scheme, it might not
 be required to set the title for each individual post, but to automatically set
diff --git a/doc/todo/language_definition_for_the_meta_plugin.mdwn b/doc/todo/language_definition_for_the_meta_plugin.mdwn
index 4ac4e2e25..8c4b45141 100644
--- a/doc/todo/language_definition_for_the_meta_plugin.mdwn
+++ b/doc/todo/language_definition_for_the_meta_plugin.mdwn
@@ -81,4 +81,16 @@ This may be useful for sites with a few pages in different languages, but no ful
 > Please resolve lang somewhere reusable rather than within meta plugin: It is certainly usable outside
 > the scope of the meta plugin as well. --[[JonasSmedegaard]]
 
+>> I don't see any problem with having this in meta? meta is on by default, and
+>> other plugins are free to use it or even depend on it (e.g. inline does).
+>>
+>> My only comments on this patch beyond what Joey said are that the page
+>> language could usefully go into `$pagestate{$page}{meta}{lang}` for other
+>> plugins to be able to see it (is that what you meant?), and that
+>> restricting to 2 characters is too restrictive (HTML 4.01 mentions
+>> `en`, `en-US` and `i-navajo` as possible language codes).
+>> This slightly complicates parsing the locale to get the default language:
+>> it'll need `tr/_/-/` after the optional `.encoding` is removed.
+>> --[[smcv]]
+
 [[!tag wishlist patch plugins/meta translation]]
diff --git a/doc/todo/meta_rcsid.mdwn b/doc/todo/meta_rcsid.mdwn
index 158edea6e..9e112317f 100644
--- a/doc/todo/meta_rcsid.mdwn
+++ b/doc/todo/meta_rcsid.mdwn
@@ -1,4 +1,4 @@
-The following patch adds an 'rcsid' parameter to the Meta plugin, to allow inclusion 
+The following patch adds an 'rcsid' parameter to the [[!taglink plugins/Meta]] plugin, to allow inclusion 
 of CVS/SVN-style keywords (like '$Id$', etc.) from the source file in the page template.
 
 > So the idea is you'd write something like:
diff --git a/doc/todo/missingparents.pm.mdwn b/doc/todo/missingparents.pm.mdwn
index c5f2ab535..cecac7a94 100644
--- a/doc/todo/missingparents.pm.mdwn
+++ b/doc/todo/missingparents.pm.mdwn
@@ -258,4 +258,4 @@ Index: IkiWiki.pm
  	my $page=shift;
 </pre>
 
-[[!tag patch]]
+[[!tag patch patch/core]]
diff --git a/doc/todo/more_class__61____34____34___for_css.mdwn b/doc/todo/more_class__61____34____34___for_css.mdwn
index 4712c12b3..cace27d63 100644
--- a/doc/todo/more_class__61____34____34___for_css.mdwn
+++ b/doc/todo/more_class__61____34____34___for_css.mdwn
@@ -15,6 +15,8 @@ Here's the one-liner:
 
 > applied --[[Joey]]
 
+----
+
 The following adds a div element with class="trailer" around the meta-information
 added after an inlined page (namely: the post date, the tags, and the actions):
 
@@ -42,7 +44,7 @@ added after an inlined page (namely: the post date, the tags, and the actions):
 > gets confused by these nested div's and puts p's around one of them, generating
 > broken html. If you can come up with a way to put in the div that passes
 > the test suite, or a fix to markdown, I will accept it, but the above patch
-> fails the test suite. --[[Joey]] 
+> fails the test suite. --[[Joey]]
 
 >> Just a note...  This discrepancy doesn't exist in [pandoc](http://code.google.com/p/pandoc/) as
 >> demonstrated in the relevant [page](http://code.google.com/p/pandoc/wiki/PandocVsMarkdownPl).
@@ -64,6 +66,16 @@ added after an inlined page (namely: the post date, the tags, and the actions):
 >>>> to at least get into debian testing before I make ikiwiki depend on it
 >>>> though. --[[Joey]]
 
+>> This Markdown issue seems to have been worked around by the optimization
+>> in which \[[!inline]] is replaced with a placeholder, and the
+>> placeholder is later replaced by the HTML. Meanwhile, this patch
+>> has been obsoleted by applying a similar one (wrapping things in a div
+>> with class inlinefooter). That was the last remaining unapplied patch
+>> on this page, so I think this whole page can be considered [[done]].
+>> --[[smcv]]
+
+----
+
 I'd like a class attribute on the `<span>` tag surrounding wikilinks
 that refer to non-existent pages, in Ikiwiki.pm:htmllink, so that such
 broken links can be styled more dramatically with CSS. --Jamey
diff --git a/doc/todo/pagestats_among_a_subset_of_pages.mdwn b/doc/todo/pagestats_among_a_subset_of_pages.mdwn
new file mode 100644
index 000000000..1c1656b4e
--- /dev/null
+++ b/doc/todo/pagestats_among_a_subset_of_pages.mdwn
@@ -0,0 +1,26 @@
+[[!tag patch plugins/pagestats]]
+
+My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that
+to provide pagestats for links from a subset of pages. From the docs included
+in the patch:
+
+> The optional `among` parameter limits counting to pages that match a
+> [[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog
+> entries, you could use:
+>
+>     \[[!pagestats pages="tags/*" among="blog/posts/*"]]
+>
+> or to display a cloud of tags related to Linux, you could use:
+> 
+>     \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]]
+
+I use this on my tag pages on one site, with the following template:
+
+    \[[!pagestats pages="tags/* and !tags/<TMPL_VAR raw_tag>
+        and !tags/photogallery"
+      among="tagged(<TMPL_VAR raw_tag>)"]]
+
+    \[[!inline pages="tagged(<TMPL_VAR raw_tag>)"
+      archive="yes" quick="yes" reverse="yes" timeformat="%x"]]
+
+--[[smcv]]
diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn
index 9598af234..29f28ca32 100644
--- a/doc/todo/passwordauth:_sendmail_interface.mdwn
+++ b/doc/todo/passwordauth:_sendmail_interface.mdwn
@@ -1,4 +1,4 @@
-[[!tag wishlist]]
+[[!tag wishlist plugins/passwordauth]]
 
 For sending out password reminder emails, the [[plugins/passwordauth]] plugin currently uses
 the *[Mail::Sendmail](http://search.cpan.org/perldoc?Mail::Sendmail)* module.
@@ -52,3 +52,10 @@ Remaining TODOs:
 > lost it. --[[Joey]]
 
 Resent.  --[[tschwinge]]
+
+> Debian now has Mail::Sender, Mail::SendEasy, and Email::Sender
+> (which, according to its dpkg description, "replaces the old and sometimes
+> problematic Email::Send library, which did a decent job at handling very
+> simple email sending tasks, but was not suitable for serious use, for a
+> variety of reasons"). Are any of those any better? It's unfortunate that
+> there doesn't seem to be a clear "best practice"... --[[smcv]]
diff --git a/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn
new file mode 100644
index 000000000..3d4338a78
--- /dev/null
+++ b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn
@@ -0,0 +1,29 @@
+A feature I originally requested on
+[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]:
+
+    Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser
+    
+    On various sites I have two IkiWiki instances running from the same
+    repository: one accessible via http and only accepting openid logins,
+    and one accessible via authenticated https and only accepting httpauth.
+    Ideally, the https version should still pretty-print OpenIDs seen in
+    git history.
+
+--[[smcv]]
+
+> I wonder if an option is the best approach. Maybe it would be better to
+> simply move `openiduser` into `userlink`, and thus always support openid
+> usernames whether the plugin is enabled or not. --[[Joey]]
+
+>> OK, implemented that as 'smcv/always-openid'; if you don't think that's
+>> bloating the IkiWiki core too much, please consider merging. The poll on
+>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID
+>> logins, so I think recognising OpenIDs can reasonably be considered core
+>> functionality! --[[smcv]]
+
+>>> That seemed easier than expected, [[done]].
+>>> (I do wonder if the call to openiduser still needs to be evaled --
+>>> it was probably only evaled before in case it was not available, but
+>>> I have not carefully checked it to make sure it doesn't ever die. --[[Joey]] 
+
+[[!tag patch]]
diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn
index 0ef8a7847..61458d972 100644
--- a/doc/todo/should_optimise_pagespecs.mdwn
+++ b/doc/todo/should_optimise_pagespecs.mdwn
@@ -79,4 +79,21 @@ I can think about reducung the size of my wiki source and making it available on
 > 
 > --[[Joey]]
 
-[[!tag wishlist]]
+>> I've been looking at optimizing ikiwiki for a site using
+>> [[plugins/contrib/album]] (which produces a lot of pages) and it seems
+>> that checking which pages depend on which pages does take a significant
+>> amount of time. The optimize-depends branch in my git repository
+>> avoids using `pagespec_merge()` for this (indeed it's no longer used
+>> at all), and instead represents dependencies as a list of pagespecs
+>> rather than a single pagespec. This does turn out to be faster, although
+>> not as much as I'd like. --[[smcv]]
+
+>>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]]
+
+>>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`).
+>>>> I think I might have solved some of the problems mentioned there,
+>>>> actually - `pagespec_merge` no longer needs to exist in my branch (although
+>>>> I haven't actually deleted it), because the "or" operation is now done in
+>>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]]
+
+[[!tag wishlist patch patch/core]]
diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn
index b051361a8..9d9ec9697 100644
--- a/doc/todo/source_link.mdwn
+++ b/doc/todo/source_link.mdwn
@@ -4,6 +4,11 @@ How about a direct link from the page header to the source of the latest version
 
 I just implemented this.  There is one [[patch]] to the default page template, and a new plugin.  -- [[Will]]
 
+> The use of sessioncgi here seems undesirable: on wikis where anonymity is
+> not allowed, you'll be asked to log in. Couldn't you achieve the same thing
+> by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does?
+> --[[smcv]]
+
 ----
 
     diff --git a/templates/page.tmpl b/templates/page.tmpl
diff --git a/doc/todo/support_for_plugins_written_in_other_languages.mdwn b/doc/todo/support_for_plugins_written_in_other_languages.mdwn
index 8476d1b44..006b6fd5e 100644
--- a/doc/todo/support_for_plugins_written_in_other_languages.mdwn
+++ b/doc/todo/support_for_plugins_written_in_other_languages.mdwn
@@ -1,4 +1,4 @@
-ikiwiki should support writing plugins in other languages
+ikiwiki should support [[writing plugins in other languages|plugins/write/external]]
 
 > [[done]] !!
 
diff --git a/doc/todo/tmplvars_plugin.mdwn b/doc/todo/tmplvars_plugin.mdwn
index 644cf23aa..2fe819682 100644
--- a/doc/todo/tmplvars_plugin.mdwn
+++ b/doc/todo/tmplvars_plugin.mdwn
@@ -2,6 +2,29 @@ A simple plugin to allow per-page customization of a template by passing paramat
 
 [[!tag patch]]
 
+> The implementation looks fine to me (assuming it works with current ikiwiki),
+> apart from the "XXX" already noted in the patch. The design could reasonably
+> be considered premature generalization, though - how often do you actually
+> need to define new tmplvars?
+>
+> As for the page/destpage/preview thing, it would be good if the preprocess
+> hook could distinguish between software-supplied and user-supplied
+> parameters (the [[plugins/tag]] plugin could benefit from this too). Perhaps
+> the IkiWiki core could be modified so that
+> `hook(type => "preprocess", splitparams => 1, ...)` would invoke preprocess
+> with { page => "foo", destpage => "bar", ... } as a special first argument,
+> and the user-supplied parameters as subsequent arguments? Then plugins like
+> tag could use:
+>
+>     my $ikiparams = shift;
+>     my %params = @_;
+>
+>     add_tags($ikiparams->{page}, keys %params);
+>
+> --[[smcv]]
+
+----
+
     #!/usr/bin/perl
     package IkiWiki::Plugin::tmplvars;
 
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index 3a761731b..80aaf3c39 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -1,3 +1,5 @@
+[[!tag patch patch/core]]
+
 I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so on several wikis.  However, as far as I can tell, ikiwiki has no functionality which can represent dependencies between bugs and allow pagespecs to select based on dependencies.  For instance, I can't write a pagespec which selects all bugs with no dependencies on bugs not marked as done.  --[[JoshTriplett]]
 
 > I started having a think about this.  I'm going to start with the idea that expanding
diff --git a/doc/todo/unaccent_url_instead_of_encoding.mdwn b/doc/todo/unaccent_url_instead_of_encoding.mdwn
index 1be150a82..d74b632bd 100644
--- a/doc/todo/unaccent_url_instead_of_encoding.mdwn
+++ b/doc/todo/unaccent_url_instead_of_encoding.mdwn
@@ -6,4 +6,4 @@ This is a one liner change, but requires a bit of reordering in the code.
 
 [[cstamas]]
 
-[[!tag wishlist patch]]
+[[!tag wishlist patch patch/core]]
diff --git a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn
index b28469993..d292a1184 100644
--- a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn
+++ b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn
@@ -33,6 +33,12 @@ ManojSrivastava
 > > directory,  which is not very easy for a plain ol' user.  Not everyone is the
 > >  sysadmin of their own machines with access to system dirs. --ManojSrivastava
 
+>>> It seems worth mentioning here that the `libdir` configuration parameter
+>>> lets you install additional plugins in a user-controlled directory
+>>> (*libdir*`/IkiWiki/Plugin`), avoiding needing root; indeed, a full local
+>>> ikiwiki installation without any involvement from the sysadmin is
+>>> [[possible|tips/DreamHost]]. --[[smcv]]
+
 <pre>
                 varioki => {'motto'    => '"Manoj\'s musings"',
                         'arrayvar' => '[0, 1, 2, 3]',
diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn
index 327e61491..9dbbb6bc8 100644
--- a/doc/todo/wikitrails/discussion.mdwn
+++ b/doc/todo/wikitrails/discussion.mdwn
@@ -1,9 +1,3 @@
-This sounds like a more general version of what I want for
-one-photo-per-page galleries, where each page has previous|up|next links
-(like this plugin) and the index page has a list or grid of thumbnails
-(\[[!inline]] with a specially modified template perhaps). I'll watch this
-with interest! --[[smcv]]
-
 This is a nice idea, I do have my gripes about the imeplementation.
 
 Assuming that the index's list is in mdwn format is not ideal. I guess the
@@ -22,3 +16,65 @@ breadcrums to be automatically inserted at the top of every page on the
 trail. (You'd have to use a directive to define the index for that to work.)
 
 --[[Joey]]
+
+----
+
+Revisiting this, after effectively reimplementing a small version of it
+in [[plugins/contrib/album]]: it occurs to me that might be a more
+"ikiwiki-like" way we could get this functionality.
+
+In the index page, you either want an [[ikiwiki/directive/inline]], or
+a list of links. In the former case, maybe we could extend inline like
+this:
+
+    \[[!inline ... blah blah ... trail=yes]]
+
+to make it remember the pages it inlined, in order, in the pagestate;
+in the latter case, we could replace the wikilinks with a directive,
+an operation something like this in diff notation:
+
+    - \[[one]] - the unit
+    - \[[two]] - the base of binary
+    - \[[three|3]] - is a crowd
+    + \[[!trailitem one]] - the unit
+    + \[[!trailitem two]] - the base of binary
+    + \[[!trailitem three|3]] - is a crowd
+
+and have that directive remember the pages in order.
+
+In both cases, a scan() hook could clear the list before starting to
+scan, then the inline or trailitem preprocessor directive could run in
+the scan stage as well as the render stage (in the case of inline,
+there'd be a very early return if trail=yes was not given, and
+an early return after collecting and sorting the pages if not
+actually rendering).
+
+This would mean that the contents of the trail, and a list of
+trails in which each page can be found, would already be in
+the pagestate by the time any page was rendered, so we'd be able
+to use them for output, either in a pagetemplate() hook or
+a \[[!trail]] preprocessor directive.
+
+This way, my album plugin could be turned inside out: instead
+of precomputing the pages to be inlined, then using
+[[pagenames|todo/inline plugin: specifying ordered page names]]
+to get them into the inline, it could just do the inline, then
+incorporate the output of \[[!trail]] into the template rendered
+for \[[!albumimage]] on each viewer page. (Also, the viewers
+wouldn't necessarily need to reference the album, only the other
+way round.)
+
+Using a pagetemplate() hook to stuff the next/previous links
+into page.tmpl would actually be a bit unfortunate for \[[!album]],
+because that plugin definitely wants to style the next/previous
+links as a thumbnail, which means there'd have to be a way to
+affect the style - perhaps by arranging for album's pagetemplate
+hook to run *after* trail's, or perhaps by having trail's
+pagetemplate hook disable itself for pages that contain
+a \[[!trail]] directive.
+
+I have now implemented this at [[plugins/contrib/trail]].
+What do you think? I'm still not sure how it would relate
+to [[plugins/contrib/album]], but if trail is reviewed
+and approved in principle, I'll try to adapt album as
+outlined above. --[[smcv]]