Merge remote branch 'upstream/master' into prv/po

26 files changed, 1176 insertions, 9 deletions

diff --git a/doc/todo/Add_nicer_math_formatting.mdwn b/doc/todo/Add_nicer_math_formatting.mdwn
index 041eaee11..3a5e94a14 100644
--- a/doc/todo/Add_nicer_math_formatting.mdwn
+++ b/doc/todo/Add_nicer_math_formatting.mdwn
@@ -1,5 +1,26 @@
-It would be nice to add nicer math formatting.  I currently use the [[plugins/teximg]] plugin, but I wonder if [jsMath](http://www.math.union.edu/~dpvc/jsMath/) wouldn't be a better option.
+It would be nice to add nicer math formatting.  I currently use the
+[[plugins/teximg]] plugin, but I wonder if
+[jsMath](http://www.math.union.edu/~dpvc/jsMath/) wouldn't be a better option.
 
 [[Will]]
 
+> I've looked at jsmath (which is nicely packaged in Debian), and 
+> I agree that this is nicer than TeX images. That text-mode browsers
+> get to see LaTeX as a fallback is actually a nice feature (better
+> than nothing, right? :) That browsers w/o javascript will not be able to
+> see the math either is probably ok.
+> 
+> A plugin would probably be a pretty trivial thing to write.
+> It just needs to include the javascript files,
+> and slap a `<div class="math"> avound the user's code`, then 
+> call `jsMath.Process(document);` at the end of the page.
+> 
+> My only concern is security: Has jsMath's parser been written 
+> to be safe when processing untrusted input? Could a user abuse the 
+> parser to cause it to emit/run arbitrary javascript code?
+> I've posted a question about this to its forum:  --[[Joey]] 
+> <https://sourceforge.net/projects/jsmath/forums/forum/592273/topic/3831574> 
+
+I think [mathjax](http://www.mathjax.org/) would be the best option. This is the math rendering engine used in mathoverflow.
+
 [[!tag wishlist]]
diff --git a/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn b/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn
new file mode 100644
index 000000000..4e1df3381
--- /dev/null
+++ b/doc/todo/Improving_the_efficiency_of_match__95__glob.mdwn
@@ -0,0 +1,228 @@
+[[!template id=gitbranch branch=smcv/ready/glob-cache
+  author="[[KathrynAndersen]], [[smcv]]"]]
+[[!tag patch]]
+
+I've been profiling my IkiWiki to try to improve speed (with many pages makes speed even more important) and I've written a patch to improve the speed of match_glob.  This matcher is a good one to improve the speed of, because it gets called so many times.
+
+Here's my patch - please consider it! -- [[KathrynAndersen]]
+
+> It seems to me as though changing `glob2re` to return qr/$re/, and calling
+> `memoize(glob2re)` next to the other memoize calls, would be a less
+> verbose way to do this? --[[smcv]]
+
+>> I think so, yeah. Anyway, do you have any benchmark results handy,
+>> Kathryn?  --[[Joey]] 
+
+>>> See below.
+>>> Also, would it make more sense for glob2re to return qr/^$re$/i rather than qr/$re/?  Everything that uses glob2re seems to use
+	$foo =~ /^$re$/i
+>>> rather than /$re/ so I think that would make sense.
+>>> -- [[KathrynAndersen]]
+
+>>>> Git branch `smcv/ka-glob-cache` has Kathryn's patch. Git
+>>>> branch `smcv/memoize-glob2re` does as I suggested, which
+>>>> is less verbose than Kathryn's patch but also not as
+>>>> fast; I'm not sure why, tbh. --[[smcv]]
+
+>>>>> I think it's because my patch focuses on match_glob while the memoize patch focuses on `glob2re`, and `glob2re` is called in `filecheck`, `meta` and `po` as well as in `match_glob` and `match_user`; thus the memoized `glob2re` is dealing with a bigger set of globs to look up, and thus could be just that little bit slower. -- [[KathrynAndersen]]
+
+>>>>>> What may be going on is that glob2re is already a fairly fast
+>>>>>> function, so the overhead of memoizing it with the very generic
+>>>>>> `_memoizer` (see its source) swamps the memoization gain. Note
+>>>>>> that the few functions memoized with the Memoizer before were much
+>>>>>> more expensive, so that little overhead was acceptable then.
+>>>>>>
+>>>>>> It also may be that Kathryn's patch is slightly faster due to using
+>>>>>> the construct `$foo =~ $regexp` rather than `$foo =~ /$regexp/`
+>>>>>> (probably avoids a copy or something like that internally) --
+>>>>>> this despite checking both `exists` and `defined` on the hash, which
+>>>>>> should be reundant AFAICS.
+>>>>>>
+>>>>>> My guess is that the best of both worlds would be to move
+>>>>>> the byhand memoization to glob2re and have it return a compiled
+>>>>>> `/^/i` regexp that can be used without further modifiction in most
+>>>>>> cases. --[[Joey]] 
+
+>>>>>>> Done, see `smcv/ready/glob-cache` and `smcv/glob-cache-too-far`.
+>>>>>>>
+>>>>>>> Kathryn's patch is a significant improvement; my first patch on top of
+>>>>>>> that is a trivial cleanup that speeds it up a little, and the next two
+>>>>>>> patches (using precompiled regexes) have surprisingly little effect
+>>>>>>> (they don't slow it down either though, so either omit them or merge
+>>>>>>> them, whichever). Detailed benchmark results below.
+>>>>>>>
+>>>>>>> Moving the memoization to `glob2re` actually seems to slow things down
+>>>>>>> again - I suspect the docwiki has few enough mentions of `user()` etc.
+>>>>>>> that caching them is a waste of time, but perhaps it's not the most
+>>>>>>> representative.
+>>>>>>> --[[smcv]]
+
+[[done]] --[[Joey]] 
+
+--------------------------------------------------------------
+
+[[!toggle id="smcv-benchmark" text="current benchmarks"]]
+
+[[!toggleable id="smcv-benchmark" text="""
+master at time of branch:
+
+    time elapsed (wall):   29.6348
+    time running program:  24.9212  (84.09%)
+    time profiling (est.): 4.7136  (15.91%)
+    number of calls:       1360181
+    number of exceptions:  13
+    
+    %Time    Sec.     #calls   sec/call  F  name
+    13.24    3.2986     3408   0.000968     Text::Balanced::_match_tagged
+    10.94    2.7253    79514   0.000034     IkiWiki::PageSpec::match_glob
+     3.19    0.7952    59454   0.000013     <anon>:IkiWiki/Plugin/inline.pm:223
+
+`Improve the speed of match_glob`:
+
+    time elapsed (wall):   27.9755
+    time running program:  23.5293  (84.11%)
+    time profiling (est.): 4.4461  (15.89%)
+    number of calls:       1280875
+    number of exceptions:  13
+    
+    %Time    Sec.     #calls   sec/call  F  name
+    14.56    3.4257     3408   0.001005     Text::Balanced::_match_tagged
+     7.82    1.8403    79514   0.000023     IkiWiki::PageSpec::match_glob
+     3.27    0.7698    59454   0.000013     <anon>:IkiWiki/Plugin/inline.pm:223
+
+`match_glob: streamline glob cache slightly`:
+
+    time elapsed (wall):   27.5753
+    time running program:  23.1714  (84.03%)
+    time profiling (est.): 4.4039  (15.97%)
+    number of calls:       1280875
+    number of exceptions:  13
+    
+    %Time    Sec.     #calls   sec/call  F  name
+    14.09    3.2637     3408   0.000958     Text::Balanced::_match_tagged
+     7.74    1.7926    79514   0.000023     IkiWiki::PageSpec::match_glob
+     3.30    0.7646    59454   0.000013     <anon>:IkiWiki/Plugin/inline.pm:223
+
+`glob2re: return a precompiled, anchored case-insensitiv...`:
+
+    time elapsed (wall):   27.5656
+    time running program:  23.1464  (83.97%)
+    time profiling (est.): 4.4192  (16.03%)
+    number of calls:       1282189
+    number of exceptions:  13
+    
+    %Time    Sec.     #calls   sec/call  F  name
+    14.21    3.2891     3408   0.000965     Text::Balanced::_match_tagged
+     7.72    1.7872    79514   0.000022     IkiWiki::PageSpec::match_glob
+     3.32    0.7678    59454   0.000013     <anon>:IkiWiki/Plugin/inline.pm:223
+
+`make use of precompiled regex objects`:
+
+    time elapsed (wall):   27.5357
+    time running program:  23.1289  (84.00%)
+    time profiling (est.): 4.4068  (16.00%)
+    number of calls:       1281981
+    number of exceptions:  13
+    
+    %Time    Sec.     #calls   sec/call  F  name
+    14.17    3.2776     3408   0.000962     Text::Balanced::_match_tagged
+     7.70    1.7814    79514   0.000022     IkiWiki::PageSpec::match_glob
+     3.35    0.7756    59454   0.000013     <anon>:IkiWiki/Plugin/inline.pm:223
+
+`move memoization from match_glob to glob2re`:
+
+    time elapsed (wall):   28.7677
+    time running program:  23.9473  (83.24%)
+    time profiling (est.): 4.8205  (16.76%)
+    number of calls:       1360181
+    number of exceptions:  13
+    
+    %Time    Sec.     #calls   sec/call  F  name
+    13.98    3.3469     3408   0.000982     Text::Balanced::_match_tagged
+     8.85    2.1194    79514   0.000027     IkiWiki::PageSpec::match_glob
+     3.24    0.7750    59454   0.000013     <anon>:IkiWiki/Plugin/inline.pm:223
+
+--[[smcv]]
+"""]]
+
+--------------------------------------------------------------
+
+[[!toggle id="ka-benchmarks" text="Kathryn's benchmarks"]]
+
+[[!toggleable id="ka-benchmarks" text="""
+Benchmarks done with Devel::Profile on the same testbed IkiWiki setup.  I'm just showing the start of the profile output, since that's what's relevant.
+
+Before:
+<pre>
+time elapsed (wall):   27.4173
+time running program:  22.5909  (82.40%)
+time profiling (est.): 4.8264  (17.60%)
+number of calls:       1314729
+number of exceptions:  65
+
+%Time    Sec.     #calls   sec/call  F  name
+11.05    2.4969    62333   0.000040     IkiWiki::PageSpec::match_glob
+ 4.10    0.9261      679   0.001364     Text::Balanced::_match_tagged
+ 2.72    0.6139    59812   0.000010     IkiWiki::SuccessReason::merge_influences
+</pre>
+
+After:
+<pre>
+time elapsed (wall):   26.1843
+time running program:  21.5673  (82.37%)
+time profiling (est.): 4.6170  (17.63%)
+number of calls:       1252433
+number of exceptions:  65
+
+%Time    Sec.     #calls   sec/call  F  name
+ 7.66    1.6521    62333   0.000027     IkiWiki::PageSpec::match_glob
+ 4.33    0.9336      679   0.001375     Text::Balanced::_match_tagged
+ 2.81    0.6057    59812   0.000010     IkiWiki::SuccessReason::merge_influences
+</pre>
+
+Note that the seconds per call for match_glob in the "after" case has gone down by about a third.
+
+K.A.
+"""]]
+
+--------------------------------------------------------------
+
+[[!toggle id="ka-patch" text="Kathryn's original patch"]]
+
+[[!toggleable id="ka-patch" text="""
+
+<pre>
+diff --git a/IkiWiki.pm b/IkiWiki.pm
+index 08a3d78..c187b98 100644
+--- a/IkiWiki.pm
++++ b/IkiWiki.pm
+@@ -2482,6 +2482,8 @@ sub derel ($$) {
+ 	return $path;
+ }
+ 
++my %glob_cache;
++
+ sub match_glob ($$;@) {
+ 	my $page=shift;
+ 	my $glob=shift;
+@@ -2489,8 +2491,15 @@ sub match_glob ($$;@) {
+ 	
+ 	$glob=derel($glob, $params{location});
+ 
+-	my $regexp=IkiWiki::glob2re($glob);
+-	if ($page=~/^$regexp$/i) {
++	# Instead of converting the glob to a regex every time,
++	# cache the compiled regex to save time.
++	if (!exists $glob_cache{$glob}
++	    or !defined $glob_cache{$glob})
++	{
++	    my $re=IkiWiki::glob2re($glob);
++	    $glob_cache{$glob} = qr/^$re$/i;
++	}
++	if ($page =~ $glob_cache{$glob}) {
+ 		if (! IkiWiki::isinternal($page) || $params{internal}) {
+ 			return IkiWiki::SuccessReason->new("$glob matches $page");
+ 		}
+</pre>
+"""]]
+--------------------------------------------------------------
diff --git a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn
index 61b19d302..b3804d652 100644
--- a/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn
+++ b/doc/todo/__42__forward__42__ing_functionality_for_the_meta_plugin.mdwn
@@ -4,7 +4,7 @@ to the [[`meta`_plugin|plugins/meta]].
 > [[done]], with some changes --[[Joey]]
 
 Find the most recent version at
-<http://www.schwinge.homeip.net/~thomas/tmp/meta_forward.patch>.
+<http://schwinge.homeip.net/~thomas/tmp/meta_forward.patch>.
 
 I can't use `scrub(...)`, as that will strip out the forwarding HTML command.
 How to deal with that?
diff --git a/doc/todo/alias_directive.mdwn b/doc/todo/alias_directive.mdwn
new file mode 100644
index 000000000..71a2efc76
--- /dev/null
+++ b/doc/todo/alias_directive.mdwn
@@ -0,0 +1,72 @@
+An alias directive could work like an inverse redirect, but in a more
+maintainable way. Currently, a page might have several redirects leading to it,
+without an easy way of enumerating them. Therefore, the following directive is
+suggested for addition (possibly by means of a plugin):
+
+> The `alias` and `aliastext` directives implicitly create
+> redirect pages to the page they are used on. If two or more pages claim a
+> non-existing page to be an alias, a disambiguation page will automatically
+> generated. If an existing page is claimed as an alias, it will be prefixed
+> with a note that its topic is also an alias for other pages.
+>
+> All aliases to a page are automatically listed below the backlink and tag
+> lists at the bottom of a page by default. This can be configured globally by
+> setting the `alias_list` configuration option to `false`, or set explicitly
+> per alias by specifying `list=true` or `list=false`.
+>
+> Similar to the `taglink` directive, `aliastext` produces the alias name as
+> well as registering it.
+>
+> ## Usage example
+>
+> `Greece.mdwn`:
+>
+> >     Greece, also known as \[[!aliastext Hellas]] and officially the
+> >     \[[!aliastext "Hellenic Republic"]], is a …
+> >     
+> >     <!-- there are so many people who misspell this, let's create a redirect -->
+> >     \[[!alias Grece list=false]] 
+>
+> This page by itself will redirect from the "Hellas", "Hellenic Republic" and
+> "Grece" pages as if they both contained just:
+>
+> >     \[[!meta redir="Greece"]]
+>
+> If, on the other hand, `Hellas Planitia` also claims `[[!alias Hellas]]`, the
+> Hellas page will look like this:
+>
+> >     **Hellas** is an alias for the following pages:
+> >
+> >     * \[[Greece]]
+> >     * \[[Hellas Planitia]]
+
+The proposed plugin/directive could be extended, eg. by also including
+old-style redirects in the alias list, but that might introduce unwanted
+coupling with the meta directive.
+
+-----------------
+
+On second thought, implementing this might have similarities with
+[[todo/auto-create tag pages according to a template]] -- the auto-created
+pages would, if the way of the alias directive is followed, not create physical
+files, though, but be created just when someone edits them.
+
+If multiple plugins do such a trick, they would have to fight over who comes
+first. If, for example, we have a setup where not yet created tag pages are
+automatically generated as "\[[!inline  pages="link(<TMPL_VAR TAG>)"
+archive="yes"]]" and aliases are enabled, and a non-tag pages grabs a tag as an
+alias (as to redirect all taglinks of the tag to itself), there are two
+possibilities:
+
+* The autotag plugin comes first:
+    * autotag sees the missing tag and creates its "\[[!inline" stuff
+    * alias sees that there is already content and adds its prefix
+* The alias plugin comes first (this is the prefered way):
+    * alias sees the empty page, sees it is not contested by other alias
+      directives and creates its "\[[!meta" redirect
+    * autotag sees there is already content and doesn't do anything
+
+That issue could be handled with "priority number" on the hook, with plugins
+with a lower number being called first.
+
+[[!tag wishlist]]
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 7eb404910..16dc78fb2 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
@@ -248,4 +248,20 @@ I've tested it fairly thouroughly. --[[Joey]]
 [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)
 
+-------------------
+
+Even if this is already marked as done, I'd like to suggest an alternative
+solution:
+
+Instead of creating a file that gets checked in into the RCS, the source files
+could be left out and the output files be written as long as there is no
+physical source file (think of a virtual underlay). Something similar would be
+required to implement [[todo/alias directive]], which couldn't be easily done
+by writing to the RCS as the page's contents can change depending on which
+other pages claim it as an alias. --[[chrysn]]
+
+I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. -- 
+
+> See [[todo/transient_pages]] for progress on this. --[[smcv]]
+
 [[!tag done]]
diff --git a/doc/todo/autoindex_should_use_add__95__autofile.mdwn b/doc/todo/autoindex_should_use_add__95__autofile.mdwn
new file mode 100644
index 000000000..19c5004f8
--- /dev/null
+++ b/doc/todo/autoindex_should_use_add__95__autofile.mdwn
@@ -0,0 +1,4 @@
+`add_autofile` is a generic version of [[plugins/autoindex]]'s code,
+so the latter should probably use the former. --[[smcv]]
+
+> See [[todo/transient_pages]] for progress on this. --[[smcv]]
diff --git a/doc/todo/capitalize_title.mdwn b/doc/todo/capitalize_title.mdwn
new file mode 100644
index 000000000..3e8366dd3
--- /dev/null
+++ b/doc/todo/capitalize_title.mdwn
@@ -0,0 +1,31 @@
+Here I propose an option (with a [[patch]]) to capitalize the first letter (ucfirst) of default titles : filenames and urls can be lowercase but title are displayed with a capital first character (filename = "foo.mdwn", pagetitle = "Foo"). Note that \[[!meta title]] are unaffected (no automatic capitalization). Comments please :) --[[JeanPrivat]]
+<pre><code>
+diff --git a/IkiWiki.pm b/IkiWiki.pm
+index 6da2819..fd36ec4 100644
+--- a/IkiWiki.pm
++++ b/IkiWiki.pm
+@@ -281,6 +281,13 @@ sub getsetup () {
+                safe => 0,
+                rebuild => 1,
+        },
++       capitalize => {
++               type => "boolean",
++               default => undef,
++               description => "capitalize the first letter of page titles",
++               safe => 1,
++               rebuild => 1,
++       },
+        userdir => {
+                type => "string",
+                default => "",
+@@ -989,6 +996,10 @@ sub pagetitle ($;$) {
+                $page=~s/(__(\d+)__|_)/$1 eq '_' ? ' ' : "&#$2;"/eg;
+        }
+ 
++       if ($config{capitalize}) {
++               $page = ucfirst $page;
++       }
++
+        return $page;
+ }
+</code></pre>
diff --git a/doc/todo/configurable_tidy_command_for_htmltidy.mdwn b/doc/todo/configurable_tidy_command_for_htmltidy.mdwn
new file mode 100644
index 000000000..e317184b5
--- /dev/null
+++ b/doc/todo/configurable_tidy_command_for_htmltidy.mdwn
@@ -0,0 +1,8 @@
+[[!tag patch patch]]
+
+I was trying to get htmltidy to [play nicely with MathML][play].  Unfortunately, I couldn't construct a command line that I was happy with, but along the way I altered htmltidy to allow a configurable command line.  This seemed like a generally useful thing, so I've published my [patch][] as a Git branch.
+
+[play]: http://lists.w3.org/Archives/Public/html-tidy/2006JanMar/0052.html
+[patch]: http://www.physics.drexel.edu/~wking/code/git/git.php?p=ikiwiki.git&a=commitdiff&h=408ee89fd7c1dc70510385a7cf263a05862dda97&hb=e65ce4f0937eaf622846c02a9d39fa7aebe4af12
+
+> Thanks, [[done]] --[[Joey]] 
diff --git a/doc/todo/countdown_directive.mdwn b/doc/todo/countdown_directive.mdwn
new file mode 100644
index 000000000..61c36204c
--- /dev/null
+++ b/doc/todo/countdown_directive.mdwn
@@ -0,0 +1,5 @@
+I'd love to have a countdown directive, which would take a timestamp to count down to and generate a JavaScript timer in the page.
+
+Ideally I'd also like to either have parameters providing content to show before and after the time passes, or integration with existing conditional directives to do the same thing.
+
+[[!tag wishlist]]
diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn
index 8721277aa..77e46049f 100644
--- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn
+++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn
@@ -42,3 +42,11 @@ browsers emulate it. [[done]]
 Wouldn't it be possible to just implement an integer-valued setting for this, accessible via the "Setup" wiki page? This would require a wiki regen, but such a setting would not be changed frequently I suppose. Also, Mediawiki has this implemented as a per-user setting (two settings, actually, -- number of rows and columns of the edit area); such a per-user setting would be the best possible implementation, but I'm not sure if ikiwiki already supports per-user settings. Please consider implementing this as the current 20 rows is a great PITA for any non-trivial page.
 
 > I don't think it would need a wiki rebuild, as the textarea is generated dynamically by the CGI when you perform a CGI action, and (as far as I know) is not cooked into any static content. -- [[Jon]]
+
+>> There is no need for a configuration setting for this -- to change
+>> the default height from 20 rows to something else, you can just put
+>> something like this in your `local.css`: --[[Joey]] 
+
+	#editcontent {
+		height: 50em;
+	}
diff --git a/doc/todo/inline_raw_files.mdwn b/doc/todo/inline_raw_files.mdwn
new file mode 100644
index 000000000..100c07288
--- /dev/null
+++ b/doc/todo/inline_raw_files.mdwn
@@ -0,0 +1,61 @@
+[[!template id=gitbranch branch=wtk/master author="[[wtk]]"]]
+
+summary
+=======
+
+Extend inlining to handle raw files (files with unrecognized extensions).
+
+Also raise an error in `IkiWiki::pagetype($file)` if `$file` is blank, which avoids trying to do much with missing files, etc.
+
+I'm using the new code in my [blog][].
+
+[blog]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/yacc2dot/
+
+usage
+=====
+
+    \[[!inline pagenames="somefile.txt" template="raw" feeds="no"]]
+
+
+> But inline already supports raw files in two ways:
+> 
+> * setting raw=yes will cause a page to be inlined raw without
+>   using any template, as if it were part of the page at the location
+>   of the inline
+> * otherwise, the file becomes an enclosure in the rss feed, for use with
+>    podcasting.
+> 
+> So I don't see the point of your patch. Although since your text
+> editor seems to like to make lots of whitespace changes, it's possible
+> I missed something in the large quantity of noise introduced by it.
+> --[[Joey]]
+
+>> As I understand it, setting `raw=yes` causes the page to be inlined
+>> as if the page contents had appeared in place of the directive.  The
+>> content is then processed by whatever `htmlize()` applies to the
+>> inlining page.  I want the inlined page to be unprocessed, and
+>> wrapped in `<pre><code>...</code></pre>` (as they are on the blog
+>> post I link to above).
+>>
+>> Enclosures do not include the page contents at all, just a link to
+>> them.  I'm trying to inline the content so I can comment on it from
+>> the inlining page.
+>>
+>> Apologies for my cluttered version history, I should have branched my
+>> earlier changes off to make things clearer.  I tried to isolate my
+>> whitespace changes (fixes?) in c9ae012d245154c3374d155958fcb0b60fda57ce.
+>> 157389355d01224b2d3c3f6e4c1eb42a20ec8a90 should hold all the content
+>> changes.
+>>
+>> A list of other things globbed into my master branch that should have
+>> been separate branches:
+>>
+>> * Make it easy to select a Markdown executable for mdwn.pm.
+>> * Included an updated form of
+>>   [[Javier Rojas' linktoimgonly.pm|forum/link_to_an_image_inside_the_wiki_without_inlining_it]].
+>> * Included an updated form of
+>>   [Jason Blevins' mdwn_itex.pm](http://jblevins.org/git/ikiwiki/plugins.git/plain/mdwn_itex.pm).
+>> * Assorted minor documentation changes.
+>>
+>> --[[wtk]]
+
diff --git a/doc/todo/latex.mdwn b/doc/todo/latex.mdwn
index 4363003c1..76bb69c9e 100644
--- a/doc/todo/latex.mdwn
+++ b/doc/todo/latex.mdwn
@@ -9,6 +9,8 @@ of the ikiwiki [[/logo]].
 
 > [[users/JasonBlevins]] has also a plugin for including [[LaTeX]] expressions (by means of `itex2MML`) -- [[plugins/mdwn_itex]] (look at his page for the link). --Ivan Z.
 
+>> I've [updated](http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/mdwn_itex/) Jason's plugin for ikiwiki 3.x.  --W. Trevor King
+
 ----
 
 ikiwiki could also support LaTeX as a document type, again rendering to HTML.
diff --git a/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn
index 6ca9962ba..88c82f66c 100644
--- a/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn
+++ b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn
@@ -21,4 +21,54 @@ and decided this time it was really needed to implement this feature.
 
 --[[intrigeri]]
 
+> Ping. --[[intrigeri]]
+
 [[!tag patch]]
+
+>> (I'm not an ikiwiki committer, opinions may vary.)
+>>
+>>> In my opinion, you're an ikiwiki committer! --[[Joey]]
+>>
+>> This would be easier to review if there weren't a million merges from
+>> master; perhaps either leave a branch as-is, or rebase it, or merge
+>> only at "significant" times like after a release?
+>>
+>> I believe Joey's main objection to complex $config entries is that
+>> it's not at all clear what [[plugins/websetup]] would do with them.
+>> Would something like this make a reasonable alternative?
+>>
+>>      $config{mirrorlist} = ["nousedirs|file:///home/intrigeri/wiki",
+>>          "usedirs|http://example.com/wiki", "http://example.net"];
+>>
+>> From how I understand tainting, this:
+>>
+>>      $untainted{$_} = possibly_foolish_untaint($tainted->{$_})
+>>
+>> probably needs to untaint the key too:
+>>
+>>      my $key = possibly_foolish_untaint($_);
+>>      $untainted{$key} = possibly_foolish_untaint($tainted->{key});
+>>
+>> --[[smcv]]
+
+>>> You are fully right about the complex `$config` entries. I'll
+>>> convert this to use what you are suggesting, i.e. what we ended up
+>>> choosing for the `po_slave_languages` setting.
+>>>
+>>> About the merges in this branch: Joey told me once he did not care
+>>> about this; moreover the `--no-merges` git log option makes it
+>>> easy to filter these out. I'll try merging tagged releases only in
+>>> the future, though.
+>>>
+>>> --[[intrigeri]]
+
+>>>> FWIW, I don't care about merge commits etc because I review
+>>>> `git diff ...intrigeri/mirrorlist` -- and if I want to dig deeper
+>>>> into the why of some code, I'll probably checkout the branch and
+>>>> use git blame.
+>>>>
+>>>> I agree with what smcv said, my other concern though is that
+>>>> this is such an edge case, that supporting it just adds clutter.
+>>>> Have to wonder if it wouldn't perhaps be better to do something
+>>>> using the goto plugin and cgiurl, so that the mirror doesn't have
+>>>> to know about the configuration of the other mirror. --[[Joey]]
diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn
index 29f28ca32..556240964 100644
--- a/doc/todo/passwordauth:_sendmail_interface.mdwn
+++ b/doc/todo/passwordauth:_sendmail_interface.mdwn
@@ -35,7 +35,7 @@ in the ikiwiki source code, where emailing is done.
 OK, so I'll have a look at replacing all email handling with *Email::Send*.
 
 [[!tag patch]]
-*<http://www.thomas.schwinge.homeip.net/tmp/ikiwiki-sendmail.patch>*
+*<http://schwinge.homeip.net/~thomas/tmp/ikiwiki-sendmail.patch>*
 
 Remaining TODOs:
 
diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn
index 402f70b79..9bb9c72c4 100644
--- a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn
+++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn
@@ -43,3 +43,18 @@ Re the meta title escaping issue worked around by `change`.
 >>>>>> did not dare to. I'll try this. --[[intrigeri]]
 
 >>>>>>> Done in my po branch, please have a look. --[[intrigeri]]
+
+>>>>>>>> I've merged it. Didn't look at the po.pm changes closely;
+>>>>>>>> assume they're ok. [[done]] --[[Joey]] 
+>>>>>>>> 
+>>>>>>>> My thinking about the reordering being safe is that
+>>>>>>>> the relative ordering of scan and preprocess in scan mode hooks
+>>>>>>>> has not been defined before, so it should be ok to define it. :)
+>>>>>>>> 
+>>>>>>>> And as to possible breakage from things that assumed the old
+>>>>>>>> ordering, such a thing would need to have a scan hook and a
+>>>>>>>> preprocess in scan mode hook, and the two hooks would need to 
+>>>>>>>> populate the same data structure with conflicting information,
+>>>>>>>> in order for there to be a problem. That seems highly unlikely
+>>>>>>>> and would be pretty broken on its own. And no plugin in ikiwiki
+>>>>>>>> itself has both types of hooks. --[[Joey]]
diff --git a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn
index 0801f7fcd..5d0318ae1 100644
--- a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn
+++ b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn
@@ -9,3 +9,5 @@ files from the source repository when it has been disabled?
 >> in most cases, it is not, thanks to .gitignore or similar, but we
 >> can't be sure. So I just can't decide it is needed to call
 >> `rcs_remove` rather than a good old `unlink`. --[[intrigeri]]
+
+>>> I guess you could call `rcs_remove` followed by `unlink`. --[[Joey]] 
diff --git a/doc/todo/po:_rethink_pagespecs.mdwn b/doc/todo/po:_rethink_pagespecs.mdwn
index 50c10c5db..98c7ff655 100644
--- a/doc/todo/po:_rethink_pagespecs.mdwn
+++ b/doc/todo/po:_rethink_pagespecs.mdwn
@@ -9,3 +9,32 @@ default when locking pages.) --[[Joey]]
 > list must be restricted to pages in the master (or current?)
 > language, and the ones that should not. The only solution I can see
 > to this surprising behaviour is: documentation. --[[intrigeri]]
+
+>> Well, a sorting criteria might be that if a PageSpec is used
+>> with a specified locaction, as happens whenever a PageSpec is
+>> used on a page, then it should match only `currentlang()`. If it 
+>> is used without a location, as in the setup file, then no such limit.
+
+>>> Ok. --[[intrigeri]]
+
+>> Note that
+>> `match_currentlang` currently dies if called w/o a location -- if
+>> it instead was always true w/o a location, this would just mean that
+>> all pagespecs should have `and currentlang()` added to them. How to
+>> implement that? All I can think of doing is wrapping
+>> `pagespec_translate`.
+
+>>> Seems doable. --[[intrigeri]]
+
+>> The only case I've found where it does make sense to match other
+>> language pages is on `l10n.ikiwiki.info` when listing pages that
+>> need translation.
+>> 
+>> Otherwise, it can be documented, but that's not really enough;
+>> a user who makes a site using auto-blog.setup and enables po will
+>> get a really screwed up blog that lists translations as separate posts
+>> and needs significant work to fix. I have thought about making
+>> `match_currentlang` a stub in IkiWiki (done in my currentlang branch),
+>> so I can use it in all the PageSpecs in the example blog etc, but I
+>> can't say I love the idea.
+>> --[[Joey]] 
diff --git a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
index c4e78ca0b..d55fc0aa8 100644
--- a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
+++ b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
@@ -5,9 +5,14 @@ features and thus makes it rather hard to give an ikiwiki site a consistent
 look. If you browse the templates provided in the tarball, you'll notice that
 more than one of them contain the `<html>` tag, which is unnecessary.
 
+> Note that is no longer true, and I didn't have to do such an intrusive
+> change to fix it either. --[[Joey]]
+
 Maybe it's just me, I also find HTML::Template cumbersome to use, due in part
 to its use of capital letters.
 
+> Its entirely optional use of capital letters? --[[Joey]]
+
 Finally, the software seems unmaintained: the mailing list and searchable
 archives linked from
 <http://html-template.sourceforge.net/html_template.html#frequently%20asked%20questions>
@@ -58,3 +63,25 @@ Yes, Template::Toolkit is very powerful. But I think it's somehow overkill for a
 I'd have to agree that Template::Toolkit is overkill and personally I'm not a fan, but it is very popular (there is even a book) and the new version (3) is alleged to be much more nimble than current version.  --[[ajt]]
 
 HTML::Template's HTML-like markup prevents me from editing templates in KompoZer or other WYSIWYG HTML editors.  The editor tries to render the template markup rather than display it verbatim, and large parts of the template become invisible.  A markup syntax that doesn't confuse editors (such as Template::Toolkit's "[% FOO %]") may promote template customization.  The ability to replace the template engine would be within the spirit of ikiwiki's extensibility. --Rocco
+
+
+I agree that being able to replace the template toolkit would be a great piece of modularity, and one I would use. If I could use the slot-based filling and the conditional logic from Template::Toolkit, we could build much more flexible inline and archivepage templates that would look different depending on where in the wiki we use them. Some of this can currently be accomplished with separate templates for each use case and a manual call to the right template in the !inline directive, but this is limited, cumbersome, and makes it difficult to reuse bits of formatting by trapping all of that information in multiple template files. -Ian
+
+> I don't wish HTML::Template to be *replaced* by Template::Toolkit - as
+> others have said above, it's overkill for my needs.  However, I also
+> agree that HTML::Template has its own problems too.  The idea of making
+> the template system modular, with a choice of which backend to use - I
+> really like that idea. It would enable me to use some other template
+> system I like better, such as Text::Template or Text::NeatTemplate. But I
+> think it would be a lot of work to implement, though perhaps no more work
+> than making the revision-control backend modular, I guess.  One would
+> need to write an IkiWiki template interface that didn't care what the
+> backend was, and yet is somehow still flexible enough to take advantage
+> of special features of different backends.  There are an *awful lot* of
+> things that use templates - not just the `pagetemplate` and `template`
+> plugins, but a number of others which have specialized templates of their
+> own. -- [[KathrynAndersen]]a
+
+>> A modular template system in ikiwiki is unlikely, as template objects
+>> are part of the API,  notably the `pagetemplate` hook. Unless the other
+>> system has a compatible template object. --[[Joey]] 
diff --git a/doc/todo/selective_more_directive.mdwn b/doc/todo/selective_more_directive.mdwn
new file mode 100644
index 000000000..2a9998205
--- /dev/null
+++ b/doc/todo/selective_more_directive.mdwn
@@ -0,0 +1,28 @@
+I'm setting up a blog for NaNoWriMo and other story-writing, which means long posts every day. I want to have excerpts on the front page, which link to the full length story posts. I also want a dedicated page for each story which inlines the story in full and in chronological order. I can use the "more" directive to achieve this effect on the front page but then it spoils the story page. My solution was to add a pages= parameter to the more directive to make it more selective.
+
+    --- /usr/share/perl5/IkiWiki/Plugin/more.pm     2010-10-09 00:09:24.000000000 +0000
+    +++ .ikiwiki/IkiWiki/Plugin/more.pm    2010-11-01 20:24:59.000000000 +0000
+    @@ -26,7 +26,10 @@
+     
+            $params{linktext} = $linktext unless defined $params{linktext};
+     
+    -       if ($params{page} ne $params{destpage}) {
+    +       if ($params{page} ne $params{destpage} &&
+    +           (! exists $params{pages} ||
+    +            pagespec_match($params{destpage}, $params{pages},
+    +                  location => $params{page}))) {
+                    return "\n".
+                           htmllink($params{page}, $params{destpage}, $params{page},
+                                    linktext => $params{linktext},
+
+I can now call it as 
+
+    \[[!more pages="index" linktext="Chapter 1" text="""
+    etc
+    """]]
+
+I'm not entirely happy with the design, since I would rather put this information in the inline directive instead of in every story post. Unfortunately I found no way to pass parameters from the inline directive to the inlined page.
+
+-- [[dark]]
+
+> Me neither, but nor do I see a better way, so [[applied|done]]. --[[Joey]] 
diff --git a/doc/todo/support_link__40__.__41___in_pagespec.mdwn b/doc/todo/support_link__40__.__41___in_pagespec.mdwn
index 79809662a..653db1ff2 100644
--- a/doc/todo/support_link__40__.__41___in_pagespec.mdwn
+++ b/doc/todo/support_link__40__.__41___in_pagespec.mdwn
@@ -11,3 +11,11 @@ IkiWiki.pm is the best way to do it".
 > I implemented this suggestion in the simplest possible way, [[!taglink patch]] available [[here|http://git.oblomov.eu/ikiwiki/patch/f4a52de556436fdee00fd92ca9a3b46e876450fa]].
 > An alternative approach, very similar, would be to make the empty page parameter mean current page (e.g. `link()` would mean pages linking here). The patch would be very similar.
 > -- GB
+
+>> Thanks for this, and also for your recent spam-fighting.
+>> Huh, I was right about changing derel, didn't realize it would be
+>> so obvious a change. :) Oh well, I managed to complicate it
+>> some in optimisation pass.. ;)
+>>
+>> Note that your git-daemon on git.oblomov.eu seems down.
+>> I pulled the patch from gitweb, [[done]] --[[Joey]]
diff --git a/doc/todo/transient_pages.mdwn b/doc/todo/transient_pages.mdwn
new file mode 100644
index 000000000..642114d97
--- /dev/null
+++ b/doc/todo/transient_pages.mdwn
@@ -0,0 +1,110 @@
+On [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]]
+suggests:
+
+> Instead of creating a file that gets checked in into the RCS, the
+> source files could be left out and the output files be written as
+> long as there is no physical source file (think of a virtual underlay).
+> Something similar would be required to implement alias directive,
+> which couldn't be easily done by writing to the RCS as the page's
+> contents can change depending on which other pages claim it as an alias.
+
+`add_autofile` could be adapted to do this, or a similar API could be
+added.
+
+This would also be useful for autoindex, as suggested on
+[[plugins/autoindex/discussion]]. I'd also like to use it for
+[[plugins/contrib/album]].
+
+One refinement I'd suggest is that if the transient page is edited,
+its transient contents are evaluated and used as the initial
+content for the edit box; after that, it'd become a static page. --[[smcv]]
+
+--------------------------
+
+[[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]]
+[[!tag patch]]
+
+I think this branch is now enough to be useful. It adds the following:
+
+If the `transient` plugin is loaded, `$srcdir/.ikiwiki/transient` is added
+as an underlay.
+
+Pages with the default extension in the transient underlay are automatically
+deleted if a page of the same name is created in the srcdir (or an underlay
+closer to the srcdir in stacking order).
+
+`tag` enables `transient`, and if `tag_autocreate_commit` is set to 0
+(default 1), autocreated tags are written to the transient underlay.
+
+`autoindex` uses autofiles. It also enables `transient`, and if
+`autoindex_commit` is set to 0 (default 1), autoindexes are written to
+the transient underlay.
+
+autoindex ignores pages in the transient underlay when deciding whether
+to generate an index.
+
+Not done yet:
+
+`remove` can't remove transient pages: this turns out to be harder than
+I'd hoped, because I don't want to introduce a vulnerability in the
+non-regular-file detection...
+
+Transient tags that don't match any pages aren't deleted: I'm not sure
+that that's a good idea anyway, though. Similarly, transient autoindexes
+of directories that become empty aren't deleted.
+
+Recent changes and aggregated files could conceivably go in the transient
+underlay too.
+
+--------------------------
+
+## An earlier version
+
+I had a look at implementing this. It turns out to be harder than I thought
+to have purely in-memory pages (several plugins want to be able to access the
+source file as a file), but I did get this proof-of-concept branch
+to write tag and autoindex pages into an underlay.
+
+This loses the ability to delete the auto-created pages (although they don't
+clutter up git this way, at least), and a lot of the code in autoindex is
+probably now redundant, so this is probably not quite ready for merge, but
+I'd welcome opinions.
+
+Usage: set `tag_underlay` and/or `autoindex_underlay` to an absolute path,
+which you must create beforehand. I suggest *srcdir* + `/.ikiwiki/transient`.
+
+Refinements that could be made if this approach seems reasonable:
+
+* make these options boolean, and have the path always be `.ikiwiki/transient`
+* improve the `remove` plugin so it also deletes from this special underlay
+
+>> Perhaps it should be something more generic, so that other plugins could use it (such as "album" mentioned above).
+>> The `.ikiwiki/transient` would suit this, but instead of saying "tag_underlay" or "autoindex_underlay" have "use_transient_underlay" or something like that?
+>> Or to make it more flexible, have just one option "transient_underlay" which is set to an absolute path, and if it is set, then one is using a transient-underlay.
+>> --[[KathrynAndersen]]
+
+>>> What I had in mind was more like `tag_autocreate_transient => 1` or
+>>> `autoindex_transient => 1`; you might conceivably want tags to be
+>>> checked in but autoindices to be transient, and it's fine for each
+>>> plugin to make its own decision. Going from that to one boolean
+>>> (or just always-transient if people don't think that's too
+>>> astonishing) would be trivial, though.
+>>>
+>>> I don't think relocating the transient underlay really makes sense,
+>>> except for prototyping: you only want one, and `.ikiwiki` is as good
+>>> a place as any (ikiwiki already needs to be able to write there).
+>>>
+>>> For [[plugins/contrib/album]] I think I'd just make the photo viewer
+>>> pages always-transient - you can always make a transient page
+>>> permanent by editing it, after all.
+>>>
+>>> Do you think this approach has enough potential that I should
+>>> continue to hack on it? Any thoughts on the implementation? --[[smcv]]
+
+>>>> Ah, now I understand what you're getting at. Yes, it makes sense to put transient pages under `.ikiwiki`.
+>>>> I haven't looked at the code, but I'd be interested in seeing whether it's generic enough to be used by other plugins (such as `album`) without too much fuss.
+>>>> The idea of a transient underlay gives us a desirable feature for free: that if someone edits the transient page, it is made permanent and added to the repository.
+>>>>
+>>>> I think the tricky thing with removing these transient underlay pages is the question of how to prevent whatever auto-generated the pages in the first place from generating them again - or, conversely, how to force whatever auto-generated those pages to regenerate them if you've changed your mind.
+>>>> I think you'd need something similar to `will_render` so that transient pages would be automatically removed if whatever auto-generated them is no longer around.
+>>>> -- [[KathrynAndersen]]
diff --git a/doc/todo/untrusted_git_push_hooks.mdwn b/doc/todo/untrusted_git_push_hooks.mdwn
new file mode 100644
index 000000000..313078ce5
--- /dev/null
+++ b/doc/todo/untrusted_git_push_hooks.mdwn
@@ -0,0 +1,12 @@
+Re the canrename, canremove, and canedit hooks:
+
+Of the three, only canremove is currently checked during an untrusted
+git push (a normal git push is assumed to be from a trusted user and
+bypasses all checks).
+
+It would probably make sense to add the canedit hook to the checks done
+there. Calling the canrename hook is tricky, because after all, git does
+not record explicit file moves.
+
+The checkcontent hook is another hook not currently called there, that
+probably should be.
diff --git a/doc/todo/use_secure_cookies_for_ssl_logins.mdwn b/doc/todo/use_secure_cookies_for_ssl_logins.mdwn
new file mode 100644
index 000000000..194db2f36
--- /dev/null
+++ b/doc/todo/use_secure_cookies_for_ssl_logins.mdwn
@@ -0,0 +1,36 @@
+[[!template id=gitbranch branch=smcv/ready/sslcookie-auto author="[[smcv]]"]]
+[[!tag patch]]
+
+At the moment `sslcookie => 0` never creates secure cookies, so if you log in
+with SSL, your browser will send the session cookie even over plain HTTP.
+Meanwhile `sslcookie => 1` always creates secure cookies, so you can't
+usefully log in over plain http.
+
+This branch adds `sslcookie => 0, sslcookie_auto => 1` as an option; this
+uses the `HTTPS` environment variable, so if you log in over SSL you'll
+get a secure session cookie, but if you log in over HTTP, you won't.
+(The syntax for the setup file is pretty rubbish - any other suggestions?)
+
+> Does this need to be a configurable option at all? The behavior could
+> just be changed in the sslcookie = 0 case. It seems sorta reasonable
+> that, once I've logged in via https, I need to re-login if I then
+> switch to http.
+
+>> Even better. I've amended the branch to have this behaviour, which
+>> turns it into a one-line patch. --[[smcv]]
+
+> And, if your change is made, the sslcookie option could probably itself
+> be dropped too -- at least I don't see a real use case for it if ikiwiki
+> is more paranoid about cookies by default.
+
+>> I haven't done that; it might make sense to do so, but I think it'd be
+>> better to leave it in as a safety-catch (or in case someone's
+>> using a webserver that doesn't put `$HTTPS` in the environment). --s
+
+> Might be best to fix
+> [[todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both]]
+> first, so that dual https/http sites can better be set up. --[[Joey]]
+
+>> Thanks for merging that! :-) --s
+
+[[merged|done]] --[[Joey]] 
diff --git a/doc/todo/use_templates_for_the_img_plugin.mdwn b/doc/todo/use_templates_for_the_img_plugin.mdwn
new file mode 100644
index 000000000..1cee1b535
--- /dev/null
+++ b/doc/todo/use_templates_for_the_img_plugin.mdwn
@@ -0,0 +1,29 @@
+[[!template id=gitbranch branch=jmtd/img_use_template author="[[Jon]]"]]
+
+Not finished! :-)
+
+The patches in <http://github.com/jmtd/ikiwiki/tree/img_use_template> convert the `img.pm` plugin to use a template (by default, `img.tmpl`, varied using a `template=` parameter) rather than hard-code the generated HTML.
+
+I originally thought of this to solve the problem outlined in [[bugs/can't mix template vars inside directives]], before I realised I could wrap the `img` call in my pages with a template to achieve the same thing.  I therefore sat on it.
+
+However, I since thought of another use for this, and so started implementing it. (note to self: explain this other use)
+
+----
+
+Ok, I have managed to achieve what I wanted with stock ikiwiki, this branch might not have any more life left in it (but it has proven an interesting experiment to see how much logic could be moved from `img.pm` into a template relatively easily. Although the template is not terribly legible.)
+
+My ikiwiki page has a picture on the front page.  I've changed that picture just once, but I would like to change it again from time to time.  I also want to keep a "gallery", or at least a list, of previous pictures, and perhaps include text alongside each picture, but not on the front page.
+
+I've achieved this as follows
+
+ * each index picture gets a page under "indexpics".
+ * the "indexpics" page has a raw inline to include them all[1]
+ * the front page has more-or-less the same inline, with show=1
+ * each index picture page has a [[plugins/conditional]]:
+   * if you are being included, show the resized picture only, and link the picture to the relevant indexpic page
+   * else, show the picture with the default link to a full-size image, and include explanatory text.
+ * most of the boilerplate is hidden inside a template
+
+It is not quite as I envisaged it: the explanatory text would probably make sense on the indexpics "gallery" page, but since that includes the page, the wrong trouser-leg of the conditional is used.  But it works quite well.  Introducing a new index picture involves creating an appropriate page under indexpics and the rest happens automatically.
+
+[1] lie #1: the pagespec is a lot more complex as it has to exclude raw image filetypes
diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
index 5f17e3ae0..f7938b061 100644
--- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
+++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
@@ -12,20 +12,312 @@ It would be good if relative paths could be used instead, so the transport metho
 > "../../", and "../". The only absolute links are to CGIs and the w3c DTD.
 > --[[Joey]]
 
->> The problem is within the CGI script. The links within the HTML page are all absolute, including links to the css file.
->> Having a http links within a HTML page retrieved using https upset most browsers (I think). Also if I push cancel on the edit page in https, I end up at at http page. -- Brian May
+>> The problem is within the CGI script. The links within the HTML page are all
+>> absolute, including links to the css file. Having a http links within a HTML
+>> page retrieved using https upset most browsers (I think). Also if I push cancel
+>> on the edit page in https, I end up at at http page. -- Brian May
 
 >>> Ikiwiki does not hardcode http links anywhere. If you don't want
 >>> it to use such links, change your configuration to use https
 >>> consistently. --[[Joey]]
 
-Errr... That is not a solution, that is a work around. ikiwiki does not hard code the absolute paths, but absolute paths are hard coded in the configuration file. If you want to serve your website so that the majority of users can see it as http, including in rss feeds (this allows proxy caches to cache the contents and has reduced load requirements), but editing is done via https for increased security, it is not possible. I have some ideas how this can be implemented (as ikiwiki has the absolute path to the CGI script and the absolute path to the destination, it should be possible to generate a relative path from one to the other), although some minor issues still need to be resolved. -- Brian May
+Errr... That is not a solution, that is a work around. ikiwiki does not hard
+code the absolute paths, but absolute paths are hard coded in the configuration
+file. If you want to serve your website so that the majority of users can see
+it as http, including in rss feeds (this allows proxy caches to cache the
+contents and has reduced load requirements), but editing is done via https for
+increased security, it is not possible. I have some ideas how this can be
+implemented (as ikiwiki has the absolute path to the CGI script and the
+absolute path to the destination, it should be possible to generate a relative
+path from one to the other), although some minor issues still need to be
+resolved. -- Brian May
 
-I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems surprising, as the change.tmpl file uses &lt;TMPL_VAR BASEURL&gt;
-which seems to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL set? -- Brian May
+I noticed the links to the images on <http://ikiwiki.info/recentchanges/> are
+also absolute, that is <http://ikiwiki.info/wikiicons/diff.png>; this seems
+surprising, as the change.tmpl file uses &lt;TMPL_VAR BASEURL&gt; which seems
+to do the right thing in page.tmpl, but not for change.tmpl. Where is BASEURL
+set? -- Brian May
 
 > The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]]
 
-So I'm facing this same issue. I have a wiki which needs to be accessed on three different URLs(!) and the hard coding of the URL from the setup file is becoming a problem for me. Is there anything I can do here? --[[Perry]]
+So I'm facing this same issue. I have a wiki which needs to be accessed on
+three different URLs(!) and the hard coding of the URL from the setup file is
+becoming a problem for me. Is there anything I can do here? --[[Perry]]
+
+> I remain puzzled by the problem that Brian is discussing. I don't see
+> why you can't just set the cgiurl and url to a https url, and serve
+> the site using both http and https.
+> 
+> Just for example, <https://kitenet.net/> is an ikiwiki, and it is accessible
+> via https or http, and if you use https, links will remain on https (except
+> for links using the cgi, which I could fix by changing the cgiurl to https).
+> 
+> I think it's possible ikiwiki used to have some
+> absolute urls that have been fixed since Brian filed the bug. --[[Joey]]  
 
 [[wishlist]]
+
+----
+
+[[!toggle id="smcv-https" text="Some discussion of a rejected implementation, smcv/https."]]
+[[!toggleable id="smcv-https" text="""
+
+[[!template id=gitbranch branch=smcv/https author="[[smcv]]"]]
+
+For a while I've been using a configuration where each wiki has a HTTP and
+a HTTPS mirror, and updating one automatically updates the other, but
+that seems unnecessarily complicated. My `https` branch adds `https_url`
+and `https_cgiurl` config options which can be used to provide a HTTPS
+variant of an existing site; the CGI script automatically detects whether
+it was accessed over HTTPS and switches to the other one.
+
+This required some refactoring, which might be worth merging even if
+you don't like my approach:
+
+* change `IkiWiki::cgiurl` to return the equivalent of `$config{cgiurl}` if
+  called with no parameters, and change all plugins to indirect through it
+  (then I only need to change that one function for the HTTPS hack)
+
+* `IkiWiki::baseurl` already has similar behaviour, so change nearly all
+  references to the `$config{url}` to call `baseurl` (a couple of references
+  specifically wanted the top-level public URL for Google or Blogspam rather
+  than a URL for the user's browser, so I left those alone)
+
+--[[smcv]]
+
+> The justification for your patch seems to be wanting to use a different
+> domain, like secure.foo.com, for https? Can you really not just configure
+> both url and cgiurl to use `https://secure.foo.com/...` and rely on
+> relative links to keep users of `http://insecure.foo.com/` on http until
+> they need to use the cgi? 
+
+>> My problem with that is that uses of the CGI aren't all equal (and that
+>> the CA model is broken). You could put CGI uses in two classes:
+>>
+>> - websetup and other "serious" things (for the sites I'm running, which
+>>   aren't very wiki-like, editing pages is also in this class).
+>>   I'd like to be able to let privileged users log in over
+>>   https with httpauth (or possibly even a client certificate), and I don't
+>>   mind teaching these few people how to do the necessary contortions to
+>>   enable something like CACert.
+>>
+>> - Random users making limited use of the CGI: do=goto, do=404, and
+>>   commenting with an OpenID. I don't think it's realistic to expect
+>>   users to jump through all the CA hoops to get CACert installed for that,
+>>   which leaves their browsers being actively obstructive, unless I either
+>>   pay the CA tax (per subdomain) to get "real" certificates, or use plain
+>>   http.
+>>
+>> On a more wiki-like wiki, the second group would include normal page edits.
+>>
+>>> I see your use case. It still seems to me that for the more common
+>>> case where CA tax has been paid (getting a cert that is valid for
+>>> multiple subdomains should be doable?), having anything going through the
+>>> cgiurl upgrade to https would be ok. In that case, http is just an
+>>> optimisation for low-value, high-aggregate-bandwidth type uses, so a
+>>> little extra https on the side is not a big deal. --[[Joey]]
+>>
+>> Perhaps I'm doing this backwards, and instead of having the master
+>> `url`/`cgiurl` be the HTTP version and providing tweakables to override
+>> these with HTTPS, I should be overriding particular uses to plain HTTP...
+>>
+>> --[[smcv]]
+>>> 
+>>> Maybe, or I wonder if you could just use RewriteEngine for such selective
+>>> up/downgrading. Match on `do=(edit|create|prefs)`. --[[Joey]]
+
+> I'm unconvinced.
+> 
+> `Ikiwiki::baseurl()."foo"` just seems to be asking for trouble,
+> ie being accidentially written as `IkiWiki::baseurl("foo")`,
+> which will fail when foo is not a page, but some file.
+
+>> That's a good point. --s
+
+> I see multiple places (inline.pm, meta.pm, poll.pm, recentchanges.pm)
+> where it will now put the https url into a static page if the build
+> happens to be done by the cgi accessed via https, but not otherwise.
+> I would rather not have to audit for such problems going forward.
+
+>> Yes, that's a problem with this approach (either way round). Perhaps
+>> making it easier to run two mostly-synched copies like I was previously
+>> doing is the only solution... --s
+
+"""]]
+
+----
+
+[[!template id=gitbranch branch=smcv/ready/localurl author="[[smcv]]"]]
+[[!tag patch]]
+
+OK, here's an alternative approach, closer in spirit to what was initially
+requested. I included a regression test for `urlto`, `baseurl` and `cgiurl`,
+now that they have slightly more complex behaviour.
+
+The idea is that in the common case, the CGI and the pages will reside on the
+same server, so they can use "semi-absolute" URLs (`/ikiwiki.cgi`, `/style.css`,
+`/bugs/done`) to refer to each other. Most redirects, form actions, links etc.
+can safely use this form rather than the fully-absolute URL.
+
+The initial version of the branch had config options `local_url` and
+`local_cgiurl`, but they're now automatically computed by checking
+whether `url` and `cgiurl` are on the same server with the the same URL
+scheme. In theory you could use things like `//static.example.com/wiki/`
+and `//dynamic.example.com/ikiwiki.cgi` to preserve choice of http/https
+while switching server, but I don't know how consistently browsers
+support that.
+
+"local" here is short for "locally valid", because these URLs are neither
+fully relative nor fully absolute, and there doesn't seem to be a good name
+for them...
+
+I've tested this on a demo website with the CGI enabled, and it seemed to
+work nicely (there might be bugs in some plugins, I didn't try all of them).
+The branch at [[todo/use secure cookies for SSL logins]] goes well with
+this one.
+
+The `$config{url}` and `$config{cgiurl}` are both HTTP, but if I enable
+`httpauth`, set `cgiauthurl` to a HTTPS version of the same site and log
+in via that, links all end up in the HTTPS version.
+
+New API added by this branch:
+
+* `urlto(x, y, 'local')` uses `$local_url` instead of `$config{url}`
+
+  > Yikes. I see why you wanted to keep it to 3 parameters (4 is too many,
+  > and po overrides it), but I dislike overloading the third parameter
+  > like that.
+  > 
+  > There are fairly few calls to `urlto($foo, $bar)`, so why not
+  > make that always return the semi-local url form, and leave the third
+  > parameter for the cases that need a true fully-qualified url.
+  > The new form for local urls will typically be only a little bit longer,
+  > except in the unusual case where the cgiurl is elsewhere. --[[Joey]]
+
+  >> So, have urlto(x, y) use `$local_url`? There are few calls, but IMO
+  >> they're for the most important things - wikilinks, img, map and
+  >> other ordinary hyperlinks. Using `$local_url` would be fine for
+  >> webserver-based use, but it does stop you browsing your wiki's
+  >> HTML over `file:///` (unless you set that as the base URL, but
+  >> then you can't move it around), and stops you moving simple
+  >> outputs (like the docwiki!) around.
+  >>
+  >> I personally think breaking the docwiki is enough to block that.
+  >>
+  >>> Well, the docwiki doesn't have an url configured at all, so I assumed
+  >>> it would need to fall back to current behavior in that case. I had
+  >>> not thought about browsing wiki's html files though, good point.
+  >>
+  >> How about this?
+  >>
+  >> * `urlto($link, $page)` with `$page` defined: relative
+  >> * `urlto($link, undef)`: local, starts with `/`
+  >> * `urlto($link)`: also local, as a side-effect
+  >> * `urlto($link, $anything, 1)` (but idiomatically, `$anything` is
+  >>   normally undef): absolute, starts with `http[s]://`
+  >>
+  >> --[[smcv]]
+  >> 
+  >>> That makes a great deal of sense, bravo for actually removing
+  >>> parameters in the common case while maintaining backwards
+  >>> compatability! --[[Joey]]
+  >>>
+  >>>> Done in my `localurl` branch; not tested in a whole-wiki way
+  >>>> yet, but I did add a regression test. I've used
+  >>>> `urlto(x, undef)` rather than `urlto(x)` so far, but I could
+  >>>> go back through the codebase using the short form if you'd
+  >>>> prefer. --[[smcv]]
+  >>> 
+  >>> It does highlight that it would be better to have a
+  >>> `absolute_urlto($link)` (or maybe `absolute(urlto($link))` )
+  >>> rather than the 3 parameter form. --[[Joey]]
+  >>>
+  >>> Possibly. I haven't added this.
+
+* `IkiWiki::baseurl` has a new second argument which works like the
+  third argument of `urlto`
+
+  > I assume you have no objection to this --[[smcv]]
+
+  >> It's so little used that I don't really care if it's a bit ugly.
+  >> (But I assume changes to `urlto` will follow through here anyway.)
+  >> --[[Joey]] 
+
+  >>> I had to use it a bit more, as a replacement for `$config{url}`
+  >>> when doing things like referencing stylesheets or redirecting to
+  >>> the top of the wiki.
+  >>>
+  >>> I ended up redoing this without the extra parameter. Previously,
+  >>> `baseurl(undef)` was the absolute URL; now, `baseurl(undef)` is
+  >>> the local path. I know you objected to me using `baseurl()` in
+  >>> an earlier branch, because `baseurl().$x` looks confusingly
+  >>> similar to `baseurl($x)` but has totally different semantics;
+  >>> I've generally written it `baseurl(undef)` now, to be more
+  >>> explicit. --[[smcv]]
+
+* `IkiWiki::cgiurl` uses `$local_cgiurl` if passed `local_cgiurl => 1`
+
+  > Now changed to always use the `$local_cgiurl`. --[[smcv]]
+
+* `IkiWiki::cgiurl` omits the trailing `?` if given no named parameters
+  except `cgiurl` and/or `local_cgiurl`
+
+  > I assume you have no objection to this --[[smcv]]
+  > 
+  >> Nod, although I don't know of a use case. --[[Joey]]
+
+  >>> The use-case is that I can replace `$config{cgiurl}` with
+  >>> `IkiWiki::cgiurl()` for things like the action attribute of
+  >>> forms. --[[smcv]]
+
+Fixed bugs:
+
+* I don't think anything except `openid` calls `cgiurl` without also
+  passing in `local_cgiurl => 1`, so perhaps that should be the default;
+  `openid` uses the `cgiurl` named parameter anyway, so there doesn't even
+  necessarily need to be a way to force absolute URLs? Any other module
+  that really needs an absolute URL could use
+  `cgiurl(cgiurl => $config{cgiurl}, ...)`,
+  although that does look a bit strange
+
+  > I agree that makes sense. --[[Joey]]
+
+  >> I'm not completely sure whether you're agreeing with "perhaps do this"
+  >> or "that looks too strange", so please disambiguate:
+  >> would you accept a patch that makes `cgiurl` default to a local
+  >> (starts-with-`/`) result? If you would, that'd reduce the diff. --[[smcv]]
+
+  >>> Yes, I absolutely think it should default to local. (Note that
+  >>> if `absolute()` were implemented as suggested above, it could also
+  >>> be used with cgiurl if necessary.) --[[Joey]]
+
+  >>>> Done (minus `absolute()`). --[[smcv]]
+
+Potential future things:
+
+* It occurs to me that `IkiWiki::cgiurl` could probably benefit from being
+  exported? Perhaps also `IkiWiki::baseurl`?
+
+  > Possibly, see [[firm_up_plugin_interface]]. --[[Joey]]
+
+  >> Not really part of this branch, though, so wontfix (unless you ask me
+  >> to do so). --[[smcv]]
+
+* Or, to reduce use of the unexported `baseurl` function, it might make
+  sense to give `urlto` a special case that references the root of the wiki,
+  with a trailing slash ready to append stuff: perhaps `urlto('/')`,
+  with usage like this?
+
+        do_something(baseurl => urlto('/', undef, local)`);
+        do_something_else(urlto('/').'style.css');
+        IkiWiki::redirect(urlto('/', undef, 1));
+
+  > AFACIS, `baseurl` is only called in 3 places so I don't think that's
+  > needed. --[[Joey]] 
+
+  >> OK, wontfix. For what it's worth, my branch has 6 uses in IkiWiki
+  >> core code (IkiWiki, CGI, Render and the pseudo-core part of editpage)
+  >> and 5 in plugins, since I used it for things like redirection back
+  >> to the top of the wiki --[[smcv]]
+
+[[merged|done]] --[[Joey]] 
diff --git a/doc/todo/web_reversion.mdwn b/doc/todo/web_reversion.mdwn
new file mode 100644
index 000000000..736d674fe
--- /dev/null
+++ b/doc/todo/web_reversion.mdwn
@@ -0,0 +1,73 @@
+Goal: Web interface to allow reverting of changes.
+
+Interface: 
+
+At least at first, it will be exposed via the recentchanges
+page, with revert icons next to each change. We may want a dynamic 
+per-page interface that goes back more than 100 changes later.
+
+Limiting assumptions:
+
+* No support for resolving conflicts in reverts; such a revert would just
+  fail and not happen.
+* No support for reset-to-this-point; initially the interface would only
+  revert a single commit, and if a bunch needed to go, the user would have
+  to drive that one at a time.
+
+Implementation plan: 
+
+* `rcs_revert` hook that takes a revision to revert.
+* CGI: `do=revert&rev=foo`
+* recentchanges plugin adds above to recentchanges page
+* prompt user to confirm (to avoid spiders doing reverts),
+  check that user is allowed to make the change, commit reversion,
+  and refresh site.
+
+Peter Gammie has done an initial implementation of the above.
+[[!template id=gitbranch branch=peteg/revert author="[[peteg]]"]]
+
+>> It is on a separate branch now. --[[peteg]]
+
+> Review: --[[Joey]] 
+> 
+> The revert commit will not currently say what web user did the revert.
+> This could be fixed by doing a --no-commit revert first and then using
+> rcs_commit_staged.
+>> Fixed, I think. --[[peteg]]
+>
+> So I see one thing I completly forgot about is `check_canedit`. Avoiding users
+> using reverting to make changes they would normally not be allowed to do is
+> tricky. I guess that a easy first pass would be to only let admins do it.
+> That would be enough to get the feature out there..
+> 
+> I'm thinking about having a `rcs_preprevert`. It would take a rev and look
+> at what changes reverting it would entail, and return the same data
+> structure that `rcs_recieve` does. This could be done by using `git revert
+> --no-commit`, and then examining the changes, and then `git reset` to drop
+> them.
+>> We can use the existing `git_commit_info` with the patch ID - no need to touch the working directory. -- [[peteg]]
+> 
+> Then the code that is currently in IkiWiki/Receive.pm, that calls
+> `check_canedit` and `check_canremove` to test the change, can be
+> straightforwardly refactored out, and used for checking reverts too.
+>> Wow, that was easy. :-) -- [[peteg]]
+> 
+> (The data from `rcs_preprevert` could also be used for a confirmation
+> prompt -- it doesn't currently include enough info for diffs, but at
+> least could have a list of changed files.)
+>
+> Note that it's possible for a git repo to have commits that modify wiki
+> files in a subdir, and code files elsewhere. `rcs_preprevert` should
+> detect changes outside the wiki dir, and fail, like `rcs_receive` does.
+>> Taken care of by refactoring `rcs_receive` in `git.pm`
+>> I've tested it lightly in my single-user setup. It's a little nasty that the `attachment` plugin
+>> gets used to check whether attachments are allowed -- there really should be a hook for that.
+>>> I agree, but have not figured out a way to make a hook work yet.
+>>> --[[Joey]] 
+>>
+>> Please look it over and tell me what else needs fixing... -- [[peteg]]
+
+>>> I have made my own revert branch and put a few^Wseveral fixes in there.
+>>> All merged to master now! --[[Joey]] 
+
+[[done]]