From a8bcb59273fcb6b0053aac293df15ef9c746ca1a Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawkickHAzX_uVJMd_vFJjae6SLs2G38URPU"
 <Kalle@web>
Date: Thu, 26 Jun 2014 18:38:33 -0400
Subject: [PATCH 01/75] trail plugin unexpected interdependencies

---
 doc/plugins/trail/discussion.mdwn | 34 +++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn
index 6c0b790b9..6a0f55968 100644
--- a/doc/plugins/trail/discussion.mdwn
+++ b/doc/plugins/trail/discussion.mdwn
@@ -103,3 +103,37 @@ Some later changes to trail:
 --[[smcv]]
 
 > Applied --[[Joey]] 
+
+----
+
+### Trail plugin creates unexpected interdependencies?
+*(ikiwiki master branch 2014-06-06 also tested with 3.20140228 release)*
+
+I noticed the problem when using the [[/plugins/contrib/album]] plugin but a bit of testing revealed that the [[trail]] plugin, which is used by [[/plugins/contrib/album]] may be the cause of the problem.
+
+On a site with the following structure where all albumN.mdwn files have the `\[[!inline  pages="page(./album01/*)" trail="yes"]]` directive set. All albumN pages and imgN pages get rebuilt whenever any one of the albumN or imgN pages are changed and the command  `ikiwiki --setup wiki.setup --refresh --verbose`
+ is issued.
+
+    /index.mdwn                        Contains no links maps or inlines
+    |-album01.mdwn                 [[!inline  pages="page(./album01/*)" trail="yes"]]
+    |-album01/
+    | |-imgA.mdwn
+    | |-imgB.mdwn
+    |
+    |-album02.mdwn                 [[!inline  pages="page(./album02/*)" trail="yes"]]
+    |-album02/
+    | |-imgC.mdwn
+    | |-imgD.mdwn
+    |
+    |-album03.mdwn                 [[!inline  pages="page(./album03/*)" trail="yes"]]
+    |-album03/
+    | |-imgE.mdwn
+    | |-imgF.mdwn
+
+Changing the index.mdwn page also triggers a full rebuild of all pages with [[trail]] directives. My sites tend to look like the above but with double digit numbers of files in at each level. Changing any file then means a full rebuild of a rather complex site which takes a long time.
+
+My setup and test may very well have mistakes but perhaps someone using the trail plugin could check (using the --verbose flag) if all their trails get rebuild when changing only one. I also find it curious that changes to the parent index.mdwn page triggers the same behaviour.
+
+I have removed a similar comment from the album discussion.
+
+ --[[kjs]]

From 13c390389a6f5d76840da205d89d10355542eaf7 Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawkickHAzX_uVJMd_vFJjae6SLs2G38URPU"
 <Kalle@web>
Date: Thu, 26 Jun 2014 18:40:23 -0400
Subject: [PATCH 02/75] Problem was related to trail rather than album plugin

---
 doc/plugins/contrib/album/discussion.mdwn | 32 -----------------------
 1 file changed, 32 deletions(-)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 0b8c7b1a5..7174fa929 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -594,37 +594,5 @@ What would be good is if the album directive could have a "show" parameter which
 > although I don't know how useful it would be; if it isn't passed, the
 > default should be 0 (unlimited). --[[smcv]]
 
-----
-
-## bug?: all albums and pages become interdependent 
-*(ikiwiki master branch 2014-06-06 and smcv album4 branch)*
-
-On a site with the following structure where all album$n.mdwn files have the ``[[!album]]`` directive set. All albums and albumviewers get rebuilt whenever any one of the pages is touched and the command ``ikiwiki --setup debug.setup --refresh --verbose`` is issued.
-
-    /index.mdwn
-    |-album01.mdwn
-    |-album01/
-    | |-imgA.jpg
-    | |-imgB.jpg
-    |
-    |-album02.mdwn
-    |-album02/
-    | |-imgC.jpg
-    | |-imgD.jpg
-    |
-    |-album03.mdwn
-    |-album03/
-    | |-imgE.jpg
-    | |-imgF.jpg
-
-This happens even if the indexpage has no links and when the tree is one level deeper than above with a folder between the index and each ``album$0n`` tuple. Touching index.mdwn rebuilds for instance imgF viewer and output like for example the following as a result of changing ``album01.mdwn`` and issuing ``ikiwiki --setup debug.setup --refresh --verbose``
-
-    building album02/imgC, its previous or next page has changed
-    building album03/imgE, its previous or next page has changed
-    building album02.mdwn, which depends on album02/imgC
-
-In other words using the album plugin means all changes trigger full rebuilds (as far as I can tell). With my workflow this hasn't been much of an issue as my sites are static and updated maximum once a week but it does make comments unfeasible.
-
-Perhaps there is something in my setup that triggers this problem? If anyone has an ikiwiki album installation where ``--refresh`` limits the scope of the rebuild to just one album I'd be interested to hear. See <http://img.kalleswork.net> for an live website that has this problem. I've tested a simpler debug site without any customization as well. --[[kjs]]
 
 

From 7d6dc4ef55a983365f3c6764ae3a2f26df70f666 Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@web>
Date: Fri, 27 Jun 2014 07:49:26 -0400
Subject: [PATCH 03/75] Comment of algorithm formatting

---
 doc/forum/Formatting_algorithms.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/forum/Formatting_algorithms.mdwn b/doc/forum/Formatting_algorithms.mdwn
index 4fc82c94f..19153947e 100644
--- a/doc/forum/Formatting_algorithms.mdwn
+++ b/doc/forum/Formatting_algorithms.mdwn
@@ -44,3 +44,9 @@ I start writing many algorithms :-)
 > 
 > I think it would be great if someone [[wrote a
 > plugin for something nicer|todo/Add_nicer_math_formatting]]. -- [[Jon]]
+
+>> [[plugins/teximg]] is fine for math (al least for GUI browsers, I didn't try with w3m etc.),
+>> but what I'm looking for is a solution for formatting **algorithms**. If teximg can help
+>> with that, great, otherwise there's the 3 workarounds I mentioned above.
+>>
+>> Do you have any ideas not mentioned? :-)

From 42da98f368c68ce7f5fc8aa945231f22ef08bf85 Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@web>
Date: Fri, 27 Jun 2014 07:50:13 -0400
Subject: [PATCH 04/75] Add signature I forgot

---
 doc/forum/Formatting_algorithms.mdwn | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/forum/Formatting_algorithms.mdwn b/doc/forum/Formatting_algorithms.mdwn
index 19153947e..c7f4aaa76 100644
--- a/doc/forum/Formatting_algorithms.mdwn
+++ b/doc/forum/Formatting_algorithms.mdwn
@@ -50,3 +50,5 @@ I start writing many algorithms :-)
 >> with that, great, otherwise there's the 3 workarounds I mentioned above.
 >>
 >> Do you have any ideas not mentioned? :-)
+>>
+>> -- [[fr33domlover]]

From 117a01bdcb984b0b9b2dbf1fef7f90c1113ff85c Mon Sep 17 00:00:00 2001
From: Christopher Baines <mail@cbaines.net>
Date: Fri, 27 Jun 2014 23:35:03 +0100
Subject: [PATCH 05/75] Reorder the content of the album page

---
 doc/plugins/contrib/album.mdwn | 90 +++++++++++++++++-----------------
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn
index 7344a158e..ce3c10184 100644
--- a/doc/plugins/contrib/album.mdwn
+++ b/doc/plugins/contrib/album.mdwn
@@ -11,6 +11,51 @@ This plugin automatically enables the [[filecheck]], [[img]], [[inline]],
 [[trail]] and [[transient]] plugins. The [[meta]] plugin is also
 recommended.
 
+## Demo
+
+* [HTML page of thumbnails](http://ikialbum.hosted.pseudorandom.co.uk/album/)
+  as an entry point to the album
+* Each thumbnail links to
+  [a "viewer" HTML page](http://ikialbum.hosted.pseudorandom.co.uk/album/img_0120/)
+  with a full size image, optional next/previous thumbnail links, and
+  optional [[plugins/comments]]
+
+## Installation
+
+[[!template id=gitbranch branch=smcv/album4 author="[[Simon_McVittie|smcv]]"]]
+
+Available from [[smcv]]'s git repository, in the `album4` branch.
+I've called it `album` to distinguish it from
+[[contrib/gallery|plugins/contrib/gallery]], although `gallery` might well be
+a better name for this functionality.
+
+(The Summer of Code [[plugins/contrib/gallery]] plugin does the
+next/previous UI in Javascript using Lightbox, which means that
+individual photos can't be bookmarked in a meaningful way, and
+the best it can do as a fallback for non-Javascript browsers
+is to provide a direct link to the image.)
+
+Updated, April 2012: rebased onto the version of [[trail]] that got merged
+
+### Manual installation
+
+First, you need a version of ikiwiki with the [[trail]] plugin merged in
+(version 3.20120203 or later).
+
+Manual installation requires these files (use the "raw" link in gitweb
+to download):
+
+* [album.pm](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/IkiWiki/Plugin/album.pm)
+  in an `IkiWiki/Plugin` subdirectory of your configured `plugindir`
+* [albumviewer.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumviewer.tmpl),
+  [albumitem.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumitem.tmpl),
+  [albumnext.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumnext.tmpl) and
+  [albumprev.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumprev.tmpl),
+   in your configured `templatedir`, or a `templates` subdirectory of your wiki repository
+* the album-related bits from the end of the
+  [stylesheet](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/doc/style.css)
+  (put them in your local.css)
+
 ## Changing the templates
 
 When a viewer page is generated or inlined into an album, the template can
@@ -44,51 +89,6 @@ template:
 
 	\[[!inline pages="..." sort="-age" template="albumitem"]]
 
-----
-
-[[!template id=gitbranch branch=smcv/album4 author="[[Simon_McVittie|smcv]]"]]
-
-Available from [[smcv]]'s git repository, in the `album4` branch.
-I've called it `album` to distinguish it from
-[[contrib/gallery|plugins/contrib/gallery]], although `gallery` might well be
-a better name for this functionality.
-
-(The Summer of Code [[plugins/contrib/gallery]] plugin does the
-next/previous UI in Javascript using Lightbox, which means that
-individual photos can't be bookmarked in a meaningful way, and
-the best it can do as a fallback for non-Javascript browsers
-is to provide a direct link to the image.)
-
-Updated, April 2012: rebased onto the version of [[trail]] that got merged
-
-## Manual installation
-
-First, you need a version of ikiwiki with the [[trail]] plugin merged in
-(version 3.20120203 or later).
-
-Manual installation requires these files (use the "raw" link in gitweb
-to download):
-
-* [album.pm](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/IkiWiki/Plugin/album.pm)
-  in an `IkiWiki/Plugin` subdirectory of your configured `plugindir`
-* [albumviewer.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumviewer.tmpl),
-  [albumitem.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumitem.tmpl),
-  [albumnext.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumnext.tmpl) and
-  [albumprev.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumprev.tmpl),
-   in your configured `templatedir`, or a `templates` subdirectory of your wiki repository
-* the album-related bits from the end of the
-  [stylesheet](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/doc/style.css)
-  (put them in your local.css)
-
-## Demo
-
-* [HTML page of thumbnails](http://ikialbum.hosted.pseudorandom.co.uk/album/)
-  as an entry point to the album
-* Each thumbnail links to
-  [a "viewer" HTML page](http://ikialbum.hosted.pseudorandom.co.uk/album/img_0120/)
-  with a full size image, optional next/previous thumbnail links, and
-  optional [[plugins/comments]]
-
 ## Bugs
 
 * `thumbnailsize` doesn't actually work, they're always 96x96.

From 8ab611c6cfb289035f5a19c247f18720e677823e Mon Sep 17 00:00:00 2001
From: Christopher Baines <mail@cbaines.net>
Date: Sat, 28 Jun 2014 10:23:09 +0100
Subject: [PATCH 06/75] Update repository location

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

diff --git a/doc/git.mdwn b/doc/git.mdwn
index c6a8dee7c..e71fa57d7 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -78,7 +78,7 @@ think about merging them. This is recommended. :-)
 * anderbubble `git://civilfritz.net/ikiwiki.git`
 * frioux `git://github.com/frioux/ikiwiki`
 * llipavsky `git://github.com/llipavsky/ikiwiki`
-* [[cbaines]] `git://github.com/cbaines/ikiwiki.git`
+* [[cbaines]] `git://git.cbaines.net/ikiwiki`
 * [[mhameed]] `git://github.com/mhameed/ikiwiki.git`
 * [[spalax]] `git://github.com/paternal/ikiwiki.git` ([[browse|https://github.com/paternal/ikiwiki]])
 

From ccc58d9773edf4323bf6acb95425851b55687e45 Mon Sep 17 00:00:00 2001
From: Christopher Baines <mail@cbaines.net>
Date: Sat, 28 Jun 2014 10:49:56 +0100
Subject: [PATCH 07/75] Add an altered album demo

---
 doc/plugins/contrib/album.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn
index ce3c10184..d6e79d7c5 100644
--- a/doc/plugins/contrib/album.mdwn
+++ b/doc/plugins/contrib/album.mdwn
@@ -20,6 +20,15 @@ recommended.
   with a full size image, optional next/previous thumbnail links, and
   optional [[plugins/comments]]
 
+### Altered Demo
+
+[[!template id=gitbranch branch=cbaines/album]]
+This uses the album plugin, with some altered css, and with the css applied to
+all of the themes.
+
+* [Simple album, rendered using mutiple themes](http://cbaines.net/projects/ikiwiki/album/dest/basic)
+  using the ikiwiki logo.
+
 ## Installation
 
 [[!template id=gitbranch branch=smcv/album4 author="[[Simon_McVittie|smcv]]"]]

From eff5f02e24ae055a208a279efb81aee4a66abcd0 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sun, 29 Jun 2014 20:06:26 +0200
Subject: [PATCH 08/75] refreshing three pending patches

---
 .../linkmap_displays_underscore_escapes.mdwn  |  2 ++
 doc/bugs/pythonproxy-utf8_again.mdwn          | 20 +++++++++++++++++++
 doc/bugs/svg_and_pdf_conversion_fails.mdwn    |  5 +++++
 3 files changed, 27 insertions(+)

diff --git a/doc/bugs/linkmap_displays_underscore_escapes.mdwn b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
index 66bffc159..62cfb3471 100644
--- a/doc/bugs/linkmap_displays_underscore_escapes.mdwn
+++ b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
@@ -19,3 +19,5 @@ the output will look much better (at least in my wikis) with the "[[bugs/pagetit
 
 the patch is stored in [[the patch.pl]] as created by git-format-patch, and can
 be pulled from the abovementioned branch.
+
+> update 2014-06-29: branch still merges cleanly and works. --[[chrysn]]
diff --git a/doc/bugs/pythonproxy-utf8_again.mdwn b/doc/bugs/pythonproxy-utf8_again.mdwn
index 96b060003..14d5cb98e 100644
--- a/doc/bugs/pythonproxy-utf8_again.mdwn
+++ b/doc/bugs/pythonproxy-utf8_again.mdwn
@@ -14,3 +14,23 @@ version, but i'm pretty sure it was already broken after the abovementioned
 patch.
 
 -- [[chrysn]]
+
+> update 2014-06-29: the problem persists, but i found it is not trivial to
+> reproduce. to demonstrate, use this test plugin:
+>
+>    #!/usr/bin/env python
+>    # -*- coding: utf-8 -*-
+>    
+>    from proxy import IkiWikiProcedureProxy
+>    
+>    def preprocess(self, proxy, *args):
+>        return repr(self.rpc('pagetype', 'schön'))
+>    
+>    proxy = IkiWikiProcedureProxy(__name__)
+>    proxy.hook('preprocess', preprocess, id='testdirective')
+>    proxy.run()
+>
+> note that when the 'schön' is stored in a variable, the exception changes --
+> it seems to me that the issue is related to the way exceptions are encoded.
+>
+> the suggested patch still applies and solves the issue. --[[chrysn]]
diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
index 41637c51d..da241b4bc 100644
--- a/doc/bugs/svg_and_pdf_conversion_fails.mdwn
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -20,3 +20,8 @@ that needs special care or breaks something i don't use; this way, my patches
 should be safe for inclusion.
 
 --[[chrysn]]
+
+> update 2014-06-29: the patch still applies and fixes the issue. in the
+> meantime, i noticed that the desired effect doesn't happen when no explicit
+> size is set. as scalable graphics don't necessarily have a natural size
+> anyway, i don't consider that a showstopper. --[[chrysn]]

From 90f1f3ff0d510d288ee5275ad6d3a771ba82b213 Mon Sep 17 00:00:00 2001
From: "89.67.253.159" <89.67.253.159@web>
Date: Sun, 29 Jun 2014 16:47:01 -0400
Subject: [PATCH 09/75] poll vote (Accept only OpenID for logins)

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

diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn
index 42d5a52b1..34d5bb777 100644
--- a/doc/news/openid.mdwn
+++ b/doc/news/openid.mdwn
@@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an
 OpenID, and see how OpenID works for you. And let me know your feelings about
 making such a switch. --[[Joey]]
 
-[[!poll 74 "Accept only OpenID for logins" 21 "Accept only password logins" 49 "Accept both"]]
+[[!poll 75 "Accept only OpenID for logins" 21 "Accept only password logins" 49 "Accept both"]]

From 3ac1a1b6373dda8846997847c9f31ca13da2fc52 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" <smcv@web>
Date: Sun, 29 Jun 2014 18:03:33 -0400
Subject: [PATCH 10/75] respond to cbaines

---
 doc/plugins/contrib/album/discussion.mdwn | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 7174fa929..9d172a277 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -1,3 +1,5 @@
+## installation queries from brush
+
 thanks for this plugin.  it might help me in my application, which is to provide album/galleries which can be edited (ie. new images added, taken away, etc.) through web interface.
 
 > That's my goal eventually, too. Perhaps you can help to
@@ -594,5 +596,23 @@ What would be good is if the album directive could have a "show" parameter which
 > although I don't know how useful it would be; if it isn't passed, the
 > default should be 0 (unlimited). --[[smcv]]
 
+## cbaines' branch
 
+Regarding the CSS changes: I'll try to have a look soon, work out
+what actually changed (since you re-ordered the CSS, so it isn't
+immediately obvious from the diff), and integrate some or all of your
+changes. Since Joey shows no signs of wanting to merge it, and "out of tree"
+installation is currently a pain, I might split out the CSS changes into a
+separate `ikiwiki/album.css` so that the only thing that needs to be merged
+into style.css and each theme (or into local.css) is an appropriate
+`@import` rule.
 
+Regarding commit `Change the default thumbnail size`: as far as I
+understand it, `size => 96x96` is meant to set the image size to
+be as large as possible given these constraints: width ≤ 96px,
+height ≤ 96px, and the original aspect ratio is preserved. So I
+would hope that 96x96 doesn't distort the thumbnails. What distortion
+are you seeing, and which versions of Imagemagick and Perlmagick
+are you using?
+
+--[[smcv]]

From 7fbc154c8ad90973d3ce2c03175f3125cd17552e Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" <smcv@web>
Date: Sun, 29 Jun 2014 18:08:21 -0400
Subject: [PATCH 11/75] the most common ikiwiki CSS trap

---
 doc/plugins/contrib/album/discussion.mdwn | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 9d172a277..fc4fd32f4 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -604,9 +604,16 @@ immediately obvious from the diff), and integrate some or all of your
 changes. Since Joey shows no signs of wanting to merge it, and "out of tree"
 installation is currently a pain, I might split out the CSS changes into a
 separate `ikiwiki/album.css` so that the only thing that needs to be merged
-into style.css and each theme (or into local.css) is an appropriate
+into style.css (or into local.css) is an appropriate
 `@import` rule.
 
+It shouldn't be necessary to add the album stuff to each individual
+theme's style.css unless you actually want an actiontabs album and
+a blueview album to be styled differently, because the IkiWiki Makefile
+concatenates them: for instance, `/usr/share/ikiwiki/themes/actiontabs/style.css`
+is the output of `cat doc/style.css themes/actiontabs/style.css`. So adding it
+to `style.css` should be enough?
+
 Regarding commit `Change the default thumbnail size`: as far as I
 understand it, `size => 96x96` is meant to set the image size to
 be as large as possible given these constraints: width ≤ 96px,

From 345db2f3cf865ffd444457d7fad92f465d3fa164 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" <smcv@web>
Date: Sun, 29 Jun 2014 18:08:40 -0400
Subject: [PATCH 12/75] disambiguate

---
 doc/plugins/contrib/album/discussion.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index fc4fd32f4..58c0e640f 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -612,7 +612,7 @@ theme's style.css unless you actually want an actiontabs album and
 a blueview album to be styled differently, because the IkiWiki Makefile
 concatenates them: for instance, `/usr/share/ikiwiki/themes/actiontabs/style.css`
 is the output of `cat doc/style.css themes/actiontabs/style.css`. So adding it
-to `style.css` should be enough?
+to `doc/style.css` should be enough?
 
 Regarding commit `Change the default thumbnail size`: as far as I
 understand it, `size => 96x96` is meant to set the image size to

From b2252dafd2d6dd3eedf51bbfe2f834f2eb42966a Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" <smcv@web>
Date: Sun, 29 Jun 2014 18:19:54 -0400
Subject: [PATCH 13/75] update

---
 doc/plugins/contrib/album.mdwn | 33 +++++++++++++--------------------
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/doc/plugins/contrib/album.mdwn b/doc/plugins/contrib/album.mdwn
index d6e79d7c5..c2f991d5a 100644
--- a/doc/plugins/contrib/album.mdwn
+++ b/doc/plugins/contrib/album.mdwn
@@ -31,9 +31,9 @@ all of the themes.
 
 ## Installation
 
-[[!template id=gitbranch branch=smcv/album4 author="[[Simon_McVittie|smcv]]"]]
+[[!template id=gitbranch branch=smcv/album5 author="[[Simon_McVittie|smcv]]"]]
 
-Available from [[smcv]]'s git repository, in the `album4` branch.
+Available from [[smcv]]'s git repository, in the `album5` branch.
 I've called it `album` to distinguish it from
 [[contrib/gallery|plugins/contrib/gallery]], although `gallery` might well be
 a better name for this functionality.
@@ -44,7 +44,8 @@ individual photos can't be bookmarked in a meaningful way, and
 the best it can do as a fallback for non-Javascript browsers
 is to provide a direct link to the image.)
 
-Updated, April 2012: rebased onto the version of [[trail]] that got merged
+Updated, June 2014: integrated changes from [[KathrynAndersen]],
+Lukas Lipavsky and kjs
 
 ### Manual installation
 
@@ -54,15 +55,15 @@ First, you need a version of ikiwiki with the [[trail]] plugin merged in
 Manual installation requires these files (use the "raw" link in gitweb
 to download):
 
-* [album.pm](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/IkiWiki/Plugin/album.pm)
+* [album.pm](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/IkiWiki/Plugin/album.pm)
   in an `IkiWiki/Plugin` subdirectory of your configured `plugindir`
-* [albumviewer.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumviewer.tmpl),
-  [albumitem.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumitem.tmpl),
-  [albumnext.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumnext.tmpl) and
-  [albumprev.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/templates/albumprev.tmpl),
+* [albumviewer.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumviewer.tmpl),
+  [albumitem.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumitem.tmpl),
+  [albumnext.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumnext.tmpl) and
+  [albumprev.tmpl](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/templates/albumprev.tmpl),
    in your configured `templatedir`, or a `templates` subdirectory of your wiki repository
 * the album-related bits from the end of the
-  [stylesheet](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album4:/doc/style.css)
+  [stylesheet](http://git.pseudorandom.co.uk/smcv/ikiwiki.git/blob/album5:/doc/style.css)
   (put them in your local.css)
 
 ## Changing the templates
@@ -100,14 +101,6 @@ template:
 
 ## Bugs
 
-* `thumbnailsize` doesn't actually work, they're always 96x96.
-  [[KathrynAndersen]] suggested a fix on the [[discussion]] page;
-  search for her name and look for a context diff.
-
-* The album index is limited to 10 images. kjs suggested a fix on
-  the [[discussion]] page: the plugin should pass `show => 0`
-  to `preprocess_inline`.
-
 * There's currently a hard-coded list of extensions that are treated as
   images: `png`, `gif`, `jpg`, `jpeg` or `mov` files. More image and video
   types could be added in future.
@@ -134,9 +127,9 @@ template:
 
 * The generated viewer page should extract as much metadata as possible from
   the photo's EXIF tags (creation/modification dates, author, title, caption,
-  copyright). [[smcv]] has a half-written implementation which runs
-  `scanimage` hooks, and has an `exiftool` plugin using [[!cpan Image::ExifTool]]
-  as a reference implementation of that hook.
+  copyright). [[smcv]] once had a half-written implementation which runs
+  `scanimage` hooks, and an `exiftool` plugin using [[!cpan Image::ExifTool]]
+  as a reference implementation of that hook, but has lost that code somewhere :-(
 
 * There should be an option to reduce the size of photos and write them into
   an underlay (perhaps just the transient underlay), for this workflow:

From a4d3db605a921b6c99d1b5082450090e31911afc Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 05:41:06 -0400
Subject: [PATCH 14/75] link to older bug; practical issues exist

---
 ...quiring_description_when_editing_page.mdwn | 23 +++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn b/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn
index 4fe591a48..bb8524841 100644
--- a/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn
+++ b/doc/todo/allow_option_for_requiring_description_when_editing_page.mdwn
@@ -1 +1,24 @@
 allow option for requiring description when editing page. This is so if a commit to an rcs is used, the commit message will not be blank.
+
+> Duplicate of [[todo/Allow_web_edit_form_comment_field_to_be_mandatory]] where
+> Joey indicated that he didn't want this in ikiwiki core, but would
+> accept a plugin that did it.
+>
+> Expanding on what Joey said there a little, the problem I have with
+> *requiring* a commit message is that solving a social problem
+> by technical means rarely works. If you can't persuade users
+> to obey a policy like "provide a nonempty commit message", then
+> you can't persuade them to obey a policy like "provide a *useful*
+> nonempty commit message" either. I used to work on a project
+> whose Bugzilla had been configured or patched to require a comment
+> whenever you changed a field (e.g. priority, cc, ...) and in
+> practice that just led to a lot of wasted time when people tried
+> to triage bugs quickly, and a lot of comments whose text was
+> ".", " ", or on at least one occasion, ☃
+> (U+2603 SNOWMAN).
+>
+> If your chosen RCS has a technical constraint that the commit
+> message must be non-empty (and will just not work otherwise),
+> that's another matter; I'd say that in that situation
+> it's appropriate for its plugin to replace empty commit
+> messages with "." or gettext("update") or something. --smcv

From c10c6c1c4db528877113ea808dbecb1cd3cd4682 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 05:49:44 -0400
Subject: [PATCH 15/75] review, suggest a change

---
 doc/bugs/pythonproxy-utf8_again.mdwn | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/doc/bugs/pythonproxy-utf8_again.mdwn b/doc/bugs/pythonproxy-utf8_again.mdwn
index 14d5cb98e..b5564d6c1 100644
--- a/doc/bugs/pythonproxy-utf8_again.mdwn
+++ b/doc/bugs/pythonproxy-utf8_again.mdwn
@@ -34,3 +34,15 @@ patch.
 > it seems to me that the issue is related to the way exceptions are encoded.
 >
 > the suggested patch still applies and solves the issue. --[[chrysn]]
+
+>> In this patch band:
+>>
+>>     -        xml = _IkiWikiExtPluginXMLRPCHandler._read(in_fd).decode('utf8')
+>>     +        response = _IkiWikiExtPluginXMLRPCHandler._read(in_fd)
+>>     +        if isinstance(response, unicode):
+>>     +            xml = response.encode('utf8')
+>>
+>> I think you mean `response.decode`, not `response.encode`.
+>>
+>> Other than that it looks good to me. I like the use of `repr` in debug
+>> messages. --[[smcv]]

From 358c1633766d7ed12fac60f060c234e8a8bc658a Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 06:12:13 -0400
Subject: [PATCH 16/75] fixed elsewhere?

---
 ...in_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
index b81dd78cd..ec22f0c78 100644
--- a/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
+++ b/doc/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL.mdwn
@@ -2,6 +2,8 @@ On some ikiwikis that I run, I get the following error on OpenID logins:
 
     no_identity_server: Could not determine ID provider from URL.
 
+> Is this fixed now that [[!debbug 738493]] has been fixed? --[[smcv]]
+
 I seem recall having that error before, and fixing it, but it always seems to come back and I forget how to fix it. So I'll just open this bug and document it if i can figure it out... -- [[users/anarcat]]
 
 The Perl module manual says:

From 526d9f131b838458df054b7cf34a8d7b42288d12 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 06:15:39 -0400
Subject: [PATCH 17/75] escape inline directives correctly

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

diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn
index 6a0f55968..ac07f8640 100644
--- a/doc/plugins/trail/discussion.mdwn
+++ b/doc/plugins/trail/discussion.mdwn
@@ -115,17 +115,17 @@ On a site with the following structure where all albumN.mdwn files have the `\[[
  is issued.
 
     /index.mdwn                        Contains no links maps or inlines
-    |-album01.mdwn                 [[!inline  pages="page(./album01/*)" trail="yes"]]
+    |-album01.mdwn                 \[[!inline  pages="page(./album01/*)" trail="yes"]]
     |-album01/
     | |-imgA.mdwn
     | |-imgB.mdwn
     |
-    |-album02.mdwn                 [[!inline  pages="page(./album02/*)" trail="yes"]]
+    |-album02.mdwn                 \[[!inline  pages="page(./album02/*)" trail="yes"]]
     |-album02/
     | |-imgC.mdwn
     | |-imgD.mdwn
     |
-    |-album03.mdwn                 [[!inline  pages="page(./album03/*)" trail="yes"]]
+    |-album03.mdwn                 \[[!inline  pages="page(./album03/*)" trail="yes"]]
     |-album03/
     | |-imgE.mdwn
     | |-imgF.mdwn

From cedbb3f0af9edc401231c6d8f91d7d897b28e5c0 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 06:21:06 -0400
Subject: [PATCH 18/75] moreinfo?

---
 doc/plugins/trail/discussion.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn
index ac07f8640..d37e5f7f9 100644
--- a/doc/plugins/trail/discussion.mdwn
+++ b/doc/plugins/trail/discussion.mdwn
@@ -137,3 +137,18 @@ My setup and test may very well have mistakes but perhaps someone using the trai
 I have removed a similar comment from the album discussion.
 
  --[[kjs]]
+
+> I would expect changing imgE.mdwn to rebuild album03.mdwn (because album03
+> inlines imgE) and vice versa (because imgE uses album03's \[[!meta title]]).
+>
+> I would not expect changing imgE.mdwn or album03.mdwn to affect album02
+> or imgC.
+>
+> I would also not expect changing index.mdwn to rebuild anything else
+> unless there is a valid dependency reason to do so.
+>
+> Can you reproduce this problem in a wiki that does not contain anything
+> private, and publish its git repo somewhere? (I realise photo galleries
+> tend to be more personal/private than typical wikis, so you don't
+> necessarily want to link the real thing - that's why my album demos
+> tend to use dummy data). --[[smcv]]

From 4e83442e6c50c212c236928b176442a7e320fab7 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 16:44:41 -0400
Subject: [PATCH 19/75] design-taste opinions?

---
 ...ical_name_for_equivalent_of_SQL_limit.mdwn | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn

diff --git a/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn b/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn
new file mode 100644
index 000000000..68d753f03
--- /dev/null
+++ b/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn
@@ -0,0 +1,37 @@
+In [[todo/Option_linktext_for_pagestats_directive]] I wrote:
+
+> It's unfortunate that map and pagestats have different meanings for
+> the show parameter. I'm tempted to propose a patch that adds something
+> like limit (by analogy with SQL) or max as the canonical name for the
+> "number of things to match" parameter, at which point a non-numeric show
+> could mean [what [[spalax]] proposed].
+
+It isn't immediately obvious whether `show` should be used like
+`\[[!map show=title]]` or like `\[[!inline show=10]]`. I can't think of
+any better names for the "which property to display" parameter that don't
+have the problem of being a synonym for show so you can't easily tell which
+is which, and I think that suggests that it might be better to rename the
+"number of items to display" parameter instead.
+
+This would allow recycling the name `show` so that a non-numeric
+value is interpreted analogous to `\[[!map show=title]]`,
+for instance to solve [[todo/Option_linktext_for_pagestats_directive]].
+
+If a committer (I think that just means Joey?) would review it, I'd be happy
+to put together a patch that adds the chosen name to all the directives
+that currently interpret `show` to mean "number of items", preferring the
+new name but retaining compatibility for a numeric `show`.
+
+Some possibilities (using inline as my example directive here):
+
+* `\[[!inline limit=10]]` like SQL `select * from foo limit 10`
+* `\[[!inline max-count=10]]` like `git log --max-count=10`
+* `\[[!inline max=10]]`
+* `\[[!inline n=10]]`, `\[[!inline num=10]]`, `\[[!inline number=10]]`
+
+Which of those do Joey/other contributors prefer?
+
+Or if keeping `show=10` is preferred, what should be the conventional name
+for functionality like `\[[!map show=title]]`?
+
+I personally like the idea of `\[[!inline limit=10]]`. --[[smcv]]

From 02bde3811e8801ae1168a653963bce084f2ea91f Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Mon, 30 Jun 2014 16:46:03 -0400
Subject: [PATCH 20/75] another possibility

---
 .../pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn   | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn b/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn
index 68d753f03..daa520d71 100644
--- a/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn
+++ b/doc/todo/pick_a_new_canonical_name_for_equivalent_of_SQL_limit.mdwn
@@ -28,6 +28,7 @@ Some possibilities (using inline as my example directive here):
 * `\[[!inline max-count=10]]` like `git log --max-count=10`
 * `\[[!inline max=10]]`
 * `\[[!inline n=10]]`, `\[[!inline num=10]]`, `\[[!inline number=10]]`
+* `\[[!inline count=10]]`
 
 Which of those do Joey/other contributors prefer?
 

From 68b88d4b22317d2abd63221e2e396dd9bd243ac0 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Tue, 1 Jul 2014 04:35:53 -0400
Subject: [PATCH 21/75] branch updated

---
 ...uld_support_uuid__44___date_variables.mdwn | 24 +++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
index 4f83c8bf5..b85f3298b 100644
--- a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
+++ b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
@@ -46,3 +46,27 @@ Changes to the structure of `$pagestate{$registering_page}{edittemplate}{$pagesp
 >> v3/v5 UUIDs, please describe it and I'll try to suggest some
 >> better way based on that, maybe global configuration in `$config`.
 >> --[[smcv]]
+
+>>> [[!template id=gitbranch branch=smcv/ready/edittemplate
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/edittemplate
+  author="Jonathon Anderson, [[smcv]]"]]
+>>> Here is a version of that branch that I would merge if I could.
+>>> Changes since Jonathon's version:
+>>>
+>>> * only generate a UUID if needed
+>>> * read `/proc/sys/kernel/random/uuid` instead of using [[!cpan UUID::Tiny]]
+>>>   if available, to avoid the dependency on at least Linux
+>>> * remove v3/v5 UUID support since I don't really see the point,
+>>>   and if included, it would need a migration path for `$pagestate`
+>>> * use RFC 3339 time format for `time` to make the timezone unambiguous
+>>> * add `html_time` which is the output of `IkiWiki::displaytime`, e.g.
+>>>   a `<time>` element on HTML5 wikis
+>>>
+>>> I'm not entirely sure what the use-case is for `formatted_time`,
+>>> so perhaps either `html_time` or `formatted_time` should be
+>>> removed; but it's not as if they really cost anything.
+>>>
+>>> There doesn't seem to be any strong convention for how we name
+>>> timestamp variables/objects, so I left the naming as it was.
+>>>
+>>> --[[smcv]]

From f26ee53e27d8343d076e636b3b8fc0c9f0ca9fc1 Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawlDmtJxA-EOa5mzqOgIHU9VKGLRSsL_Hxw"
 <Ramsey@web>
Date: Wed, 2 Jul 2014 13:16:49 -0400
Subject: [PATCH 22/75]

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

diff --git a/doc/theme_market.mdwn b/doc/theme_market.mdwn
index e9bdaa056..701e616ca 100644
--- a/doc/theme_market.mdwn
+++ b/doc/theme_market.mdwn
@@ -11,3 +11,5 @@ Feel free to add your own [[theme|themes]] here, but first consider writing a si
  * **[[Night city theme|http://anarcat.ath.cx/night_city/README/]]**, contributed by [[anarcat]], see an example [[on his homepage|http://anarcat.ath.cx/]]
 
  * **[[Bootstrap theme|http://anonscm.debian.org/gitweb/?p=users/jak/website.git;a=summary]]**, contributed by [[JAK LINUX|http://jak-linux.org/about/]], based on [[Twitter Bootstrap|http://twitter.github.com/bootstrap/]]
+
+ * **[[Bootstrap 3|https://github.com/ramseydsilva/ikiwiki-bootstrap-theme]]**, contributed by [[Ramsey D'silva|http://ramseydsilva.com]], based on [[Twitter Bootstrap 3|http://getbootstrap.com]]

From 1e2e6eeb2b4dbf908368ba08639878814015cdfc Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawlDmtJxA-EOa5mzqOgIHU9VKGLRSsL_Hxw"
 <Ramsey@web>
Date: Wed, 2 Jul 2014 13:20:43 -0400
Subject: [PATCH 23/75]

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

diff --git a/doc/theme_market.mdwn b/doc/theme_market.mdwn
index 701e616ca..4ac41cb0a 100644
--- a/doc/theme_market.mdwn
+++ b/doc/theme_market.mdwn
@@ -12,4 +12,4 @@ Feel free to add your own [[theme|themes]] here, but first consider writing a si
 
  * **[[Bootstrap theme|http://anonscm.debian.org/gitweb/?p=users/jak/website.git;a=summary]]**, contributed by [[JAK LINUX|http://jak-linux.org/about/]], based on [[Twitter Bootstrap|http://twitter.github.com/bootstrap/]]
 
- * **[[Bootstrap 3|https://github.com/ramseydsilva/ikiwiki-bootstrap-theme]]**, contributed by [[Ramsey D'silva|http://ramseydsilva.com]], based on [[Twitter Bootstrap 3|http://getbootstrap.com]]
+ * **[[Bootstrap 3|https://github.com/ramseydsilva/ikiwiki-bootstrap-theme]]**, contributed by [[ramsey]], based on [[Twitter Bootstrap 3|http://getbootstrap.com]]

From ee72b1e03294b0efbfbf107de6046a68947293a8 Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawkickHAzX_uVJMd_vFJjae6SLs2G38URPU"
 <Kalle@web>
Date: Wed, 2 Jul 2014 17:53:10 -0400
Subject: [PATCH 24/75] repo links and test site for trail depends bug

---
 doc/plugins/trail/discussion.mdwn | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/doc/plugins/trail/discussion.mdwn b/doc/plugins/trail/discussion.mdwn
index d37e5f7f9..731b8c790 100644
--- a/doc/plugins/trail/discussion.mdwn
+++ b/doc/plugins/trail/discussion.mdwn
@@ -152,3 +152,21 @@ I have removed a similar comment from the album discussion.
 > tend to be more personal/private than typical wikis, so you don't
 > necessarily want to link the real thing - that's why my album demos
 > tend to use dummy data). --[[smcv]]
+
+>> I was expecting the same depends pattern you describe.
+>> My photo wikis are mostly public so I've set up a publicly accessible repo 
+>> (update-server-info type, git clone the first link below), a low-res copy of 
+>> the underlay and a quick sanitized setup file.
+
+>>* [[http://www.kalleswork.net/downloads/stockholm/.git]]
+>>* [[http://www.kalleswork.net/downloads/stockholm.underlay.tar.gz]]
+>>* [[http://www.kalleswork.net/downloads/stockholm.setup]]
+
+>> It might be a bit unwieldly and the site itself at [[http://stockholm.kalleswork.net]] 
+>> uses a few tweaks to the album templates and css, but I don't currently 
+>> have access to the machine where I setup a cleaner debug wiki to test. 
+>> (travelling atm). The images will likely be distorted due to the up scaling 
+>> bug in the [[img]] plugin but other than that it should work.
+
+>> Let me know if you need anything else. Would be great to hear it works
+>> as expected for everyone else ;) --[[kjs]]

From a6f4dcd4959f0b460f8e10480d67e8bdf50efafa Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Thu, 3 Jul 2014 04:36:51 +0200
Subject: [PATCH 25/75] respond to smcv's comment

---
 doc/bugs/pythonproxy-utf8_again.mdwn | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/doc/bugs/pythonproxy-utf8_again.mdwn b/doc/bugs/pythonproxy-utf8_again.mdwn
index b5564d6c1..fa702a22c 100644
--- a/doc/bugs/pythonproxy-utf8_again.mdwn
+++ b/doc/bugs/pythonproxy-utf8_again.mdwn
@@ -18,17 +18,17 @@ patch.
 > update 2014-06-29: the problem persists, but i found it is not trivial to
 > reproduce. to demonstrate, use this test plugin:
 >
->    #!/usr/bin/env python
->    # -*- coding: utf-8 -*-
->    
->    from proxy import IkiWikiProcedureProxy
->    
->    def preprocess(self, proxy, *args):
->        return repr(self.rpc('pagetype', 'schön'))
->    
->    proxy = IkiWikiProcedureProxy(__name__)
->    proxy.hook('preprocess', preprocess, id='testdirective')
->    proxy.run()
+>     #!/usr/bin/env python
+>     # -*- coding: utf-8 -*-
+>     
+>     from proxy import IkiWikiProcedureProxy
+>     
+>     def preprocess(self, proxy, *args):
+>         return repr(self.rpc('pagetype', 'schön'))
+>     
+>     proxy = IkiWikiProcedureProxy(__name__)
+>     proxy.hook('preprocess', preprocess, id='testdirective')
+>     proxy.run()
 >
 > note that when the 'schön' is stored in a variable, the exception changes --
 > it seems to me that the issue is related to the way exceptions are encoded.
@@ -46,3 +46,9 @@ patch.
 >>
 >> Other than that it looks good to me. I like the use of `repr` in debug
 >> messages. --[[smcv]]
+
+>>> afaict, encode is fine there -- the relevant methods in python2 are
+>>> `unicode.encode` which gives a `str`, and `str.decode` which usually gives
+>>> a `unicode`. (i'd happily ditch python2 and port all plugins to python3,
+>>> where this is all easier, but my [[todo/vCard rendering]] still uses an
+>>> ancient module.) --[[chrysn]]

From fb4cf0790ad93791040a99d6e183cfae274dd7f2 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Thu, 3 Jul 2014 15:03:01 -0400
Subject: [PATCH 26/75] comment (not a review yet)

---
 doc/bugs/linkmap_displays_underscore_escapes.mdwn | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/doc/bugs/linkmap_displays_underscore_escapes.mdwn b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
index 62cfb3471..abcbfb9ed 100644
--- a/doc/bugs/linkmap_displays_underscore_escapes.mdwn
+++ b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
@@ -17,6 +17,17 @@ the attached [[!taglink patch]] fixes this; from its commit message:
 
 the output will look much better (at least in my wikis) with the "[[bugs/pagetitle function does not respect meta titles]]" issue fixed.
 
+> I agree that it's (likely to be) a bug to not use `pagetitle()`. I
+> haven't reviewed this particular implementation yet but I'll try to
+> do that soon.
+>
+> I don't think it's correct for `pagetitle()` to output `\[[!meta title]]`
+> though, as discussed on the linked bug: it appears in an assortment of
+> contexts where the full formal title of the page seems inappropriate.
+> If you want linkmap to use `\[[!meta title]]`, I think it would be
+> better to give it a `show` parameter, like `\[[!map]]` has?
+> --[[smcv]]
+
 the patch is stored in [[the patch.pl]] as created by git-format-patch, and can
 be pulled from the abovementioned branch.
 

From 7760b8c72878336d45d00ce456697a3a250b7761 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Thu, 3 Jul 2014 21:54:30 +0200
Subject: [PATCH 27/75] reply to smcv's comment

---
 doc/bugs/linkmap_displays_underscore_escapes.mdwn | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/bugs/linkmap_displays_underscore_escapes.mdwn b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
index abcbfb9ed..75b917163 100644
--- a/doc/bugs/linkmap_displays_underscore_escapes.mdwn
+++ b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
@@ -28,6 +28,9 @@ the output will look much better (at least in my wikis) with the "[[bugs/pagetit
 > better to give it a `show` parameter, like `\[[!map]]` has?
 > --[[smcv]]
 
+>> sounds good; i'll have a look at it the next time i touch the linkmap
+>> plugin. the patch at hand would be a starting point for that. --[[chrysn]]
+
 the patch is stored in [[the patch.pl]] as created by git-format-patch, and can
 be pulled from the abovementioned branch.
 

From 6660fd643bf3b65745d62b24cb16fef1b5205207 Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@kitenet.net>
Date: Thu, 3 Jul 2014 16:21:47 -0400
Subject: [PATCH 28/75] Add google back to openid selector. Apparently this has
 gotten a stay of execution until April 2015. (It may continue to work until
 2017.)

---
 debian/changelog                                          | 7 +++++++
 underlays/openid-selector/ikiwiki/openid/openid-jquery.js | 5 +++++
 2 files changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 5675670a8..11ad07712 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ikiwiki (3.20140614) UNRELEASED; urgency=medium
+
+  * Add google back to openid selector. Apparently this has gotten a stay
+    of execution until April 2015. (It may continue to work until 2017.)
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 03 Jul 2014 16:19:40 -0400
+
 ikiwiki (3.20140613) unstable; urgency=medium
 
   * only_committed_changes could fail in a git repository merged
diff --git a/underlays/openid-selector/ikiwiki/openid/openid-jquery.js b/underlays/openid-selector/ikiwiki/openid/openid-jquery.js
index 1df419fb8..0400ae6bb 100644
--- a/underlays/openid-selector/ikiwiki/openid/openid-jquery.js
+++ b/underlays/openid-selector/ikiwiki/openid/openid-jquery.js
@@ -6,6 +6,11 @@ This code is licenced under the New BSD License.
 */
 
 var providers_large = {
+    google: {
+        name: 'Google',
+        icon: 'ikiwiki/openid/goa-account-google.png',
+        url: 'https://www.google.com/accounts/o8/id'
+    },
     verisign: {
         name: 'Verisign',
         icon: 'ikiwiki/openid/verisign.png',

From 6d90e56c8dbb1e380f0e621305fd014767e9364b Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Thu, 3 Jul 2014 17:49:02 -0400
Subject: [PATCH 29/75] remove patch tag, the patch here was merged

---
 doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
index b641f2db2..0d40d232a 100644
--- a/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
+++ b/doc/bugs/syslog_fails_with_non-ASCII_wikinames.mdwn
@@ -18,10 +18,15 @@ Yet I am not sure how to fix that kind of problem in Perl... --[[anarcat]]
 > 
 >     Error: Wide character in syswrite at /usr/lib/perl/5.14/Sys/Syslog.pm line 485.
 > 
-> I have improved a little the error handling in log_message() so that we see *something* when syslog fails, see the branch documented above. I can also confirm that  reverting [[todo/syslog_should_show_wiki_name]] fixes the bug. Finally, I have a unit test that reproduces the problem in git, and a working [[!taglink patch]] for the bug, again in git.
+> I have improved a little the error handling in log_message() so that we see *something* when syslog fails, see the branch documented above. I can also confirm that  reverting [[todo/syslog_should_show_wiki_name]] fixes the bug. Finally, I have a unit test that reproduces the problem in git, and a working patch for the bug, again in git.
 > 
 > > One last note: I noticed that this problem also happens elsewhere in ikiwiki. For example, the [[plugins/notifyemail]] plugin will silently fail to send notifications if the pages contain unicode. The [[plugins/notifychanges]] plugin I am working on (in [[todo/option to send only the diff in notifyemail]]) seems to be working around the issue so far, but there's no telling which similar problem are out there.
 
->> [[I'd merge it|/users/smcv/yesplease]]. --[[smcv]]
+>> I'd merge it. --[[smcv]]
 
 >>> I've merged it, but I don't feel it fixes this bug. --[[Joey]]
+
+>>>> (I removed the patch tag to take it off the patches list.)
+>>>>
+>>>> What else is needed? Systematic classification of outputs into
+>>>> those that do and don't cope with Unicode? --[[smcv]]

From e740ff3a4be827f1289ce855d704704db7a60feb Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:11:48 -0400
Subject: [PATCH 30/75] positive review

---
 doc/bugs/linkmap_displays_underscore_escapes.mdwn | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/bugs/linkmap_displays_underscore_escapes.mdwn b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
index 75b917163..41ea070a2 100644
--- a/doc/bugs/linkmap_displays_underscore_escapes.mdwn
+++ b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
@@ -17,9 +17,7 @@ the attached [[!taglink patch]] fixes this; from its commit message:
 
 the output will look much better (at least in my wikis) with the "[[bugs/pagetitle function does not respect meta titles]]" issue fixed.
 
-> I agree that it's (likely to be) a bug to not use `pagetitle()`. I
-> haven't reviewed this particular implementation yet but I'll try to
-> do that soon.
+> [[Looks good to me|users/smcv/yesplease]].
 >
 > I don't think it's correct for `pagetitle()` to output `\[[!meta title]]`
 > though, as discussed on the linked bug: it appears in an assortment of

From 14337f60c951112ccf3138719628bb6be41917c9 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:16:35 -0400
Subject: [PATCH 31/75] rename users/smcv/yesplease.mdwn to
 users/smcv/ready.mdwn

---
 doc/users/smcv/{yesplease.mdwn => ready.mdwn} | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename doc/users/smcv/{yesplease.mdwn => ready.mdwn} (100%)

diff --git a/doc/users/smcv/yesplease.mdwn b/doc/users/smcv/ready.mdwn
similarity index 100%
rename from doc/users/smcv/yesplease.mdwn
rename to doc/users/smcv/ready.mdwn

From 92821be5402cd2fa74a037cb28619ee4a7a2e6e1 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:16:35 -0400
Subject: [PATCH 32/75] update for rename of users/smcv/yesplease.mdwn to
 users/smcv/ready.mdwn

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

diff --git a/doc/users/smcv.mdwn b/doc/users/smcv.mdwn
index a4eb564ce..9835049c3 100644
--- a/doc/users/smcv.mdwn
+++ b/doc/users/smcv.mdwn
@@ -7,4 +7,4 @@ My repository containing ikiwiki branches:
 * gitweb: http://git.pseudorandom.co.uk/smcv/ikiwiki.git
 * anongit: git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git
 
-Recently tried to [[help with the review backlog|yesplease]].
+Recently tried to [[help with the review backlog|users/smcv/ready]].

From b948d1a1b376a8172e64ea61662dbb0d7a089586 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:16:36 -0400
Subject: [PATCH 33/75] update for rename of users/smcv/yesplease.mdwn to
 users/smcv/ready.mdwn

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

diff --git a/doc/bugs/preprocessing_loop_control_too_tight.mdwn b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
index 807d6b7ef..7cf92af57 100644
--- a/doc/bugs/preprocessing_loop_control_too_tight.mdwn
+++ b/doc/bugs/preprocessing_loop_control_too_tight.mdwn
@@ -18,6 +18,6 @@ index 75c9579..ad0f8b0 100644
 
 [[!tag patch]]
 
-> [[Seems reasonable|users/smcv/yesplease]] --smcv
+> [[Seems reasonable|users/smcv/ready]] --smcv
 
 >> [[done]] --[[Joey]]

From c0440d31f9e220dabcf4d58ff6bb85539c798fbc Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:16:36 -0400
Subject: [PATCH 34/75] update for rename of users/smcv/yesplease.mdwn to
 users/smcv/ready.mdwn

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

diff --git a/doc/todo/support_linking_to_cgit.mdwn b/doc/todo/support_linking_to_cgit.mdwn
index ab6172ad1..ae7d23ce9 100644
--- a/doc/todo/support_linking_to_cgit.mdwn
+++ b/doc/todo/support_linking_to_cgit.mdwn
@@ -36,7 +36,7 @@ the substitution of `\[[file]]` in `diffurl` and `historyurl`?
 >>>> \[[file_less_escaped]], and I can't think of one.
 >>>>
 >>>> I don't have commit access to ikiwiki.info, but if I did,
->>>> [[I'd merge this|/users/smcv/yesplease]]. --[[smcv]]
+>>>> [[I'd merge this|/users/smcv/ready]]. --[[smcv]]
 
 >>>>> [[merged|done]] --[[Joey]]
 

From f2426594d22619e41323fdf4fc44fc5bdaab2a13 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:16:36 -0400
Subject: [PATCH 35/75] update for rename of users/smcv/yesplease.mdwn to
 users/smcv/ready.mdwn

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

diff --git a/doc/todo/expose_html_language_and_direction.mdwn b/doc/todo/expose_html_language_and_direction.mdwn
index f321e4f52..65032fabf 100644
--- a/doc/todo/expose_html_language_and_direction.mdwn
+++ b/doc/todo/expose_html_language_and_direction.mdwn
@@ -9,7 +9,7 @@ This means:
 
 The [[patch]] is currently being used on http://addons.nvda-project.org and seems to work well. --[[mhameed]]
 
-> I don't have commit access, but it [[seems reasonable|/users/smcv/yesplease]].
+> I don't have commit access, but it [[seems reasonable|/users/smcv/ready]].
 > --[[smcv]]
 
 >> [[done]]] --[[Joey]]

From 696c1ccaa461e0ed2129acc4eddc1a2d023b4a2c Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:16:37 -0400
Subject: [PATCH 36/75] update for rename of users/smcv/yesplease.mdwn to
 users/smcv/ready.mdwn

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

diff --git a/doc/bugs/linkmap_displays_underscore_escapes.mdwn b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
index 41ea070a2..14164d076 100644
--- a/doc/bugs/linkmap_displays_underscore_escapes.mdwn
+++ b/doc/bugs/linkmap_displays_underscore_escapes.mdwn
@@ -17,7 +17,7 @@ the attached [[!taglink patch]] fixes this; from its commit message:
 
 the output will look much better (at least in my wikis) with the "[[bugs/pagetitle function does not respect meta titles]]" issue fixed.
 
-> [[Looks good to me|users/smcv/yesplease]].
+> [[Looks good to me|users/smcv/ready]].
 >
 > I don't think it's correct for `pagetitle()` to output `\[[!meta title]]`
 > though, as discussed on the linked bug: it appears in an assortment of

From bdf4feb1f29fadde8a51c49db76e548521629583 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:18:41 -0400
Subject: [PATCH 37/75] rename to be more appropriate for my own branches

---
 doc/users/smcv/ready.mdwn | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/doc/users/smcv/ready.mdwn b/doc/users/smcv/ready.mdwn
index b100b374e..ed8aa2618 100644
--- a/doc/users/smcv/ready.mdwn
+++ b/doc/users/smcv/ready.mdwn
@@ -1,7 +1,10 @@
 A tag for patches that I would merge if I had commit access to ikiwiki,
 in the hope that it's a useful shortlist for committers to look at.
-They're mirrored in my git repository under the `ready/*` namespace.
+Two categories:
+
+* my own branches, in my git repository under the `ready/*` namespace
+* other people's branches, mirrored in my git repo in the same namespace
 
 [[!inline pages="(todo/* or bugs/*) and link(patch) and !link(bugs/done) and
-   !link(todo/done) and link(users/smcv/yesplease) and !*/Discussion"
+   !link(todo/done) and link(users/smcv/ready) and !*/Discussion"
    archive="yes"]]

From 4650207a286591420c340fdf366a417f673596a8 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:27:37 -0400
Subject: [PATCH 38/75] add branch URLs, tag as ready

---
 ..._autocreated_tagbase_is_not_transient_autoindexed.mdwn | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index 702608831..ba2092f42 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -6,9 +6,11 @@
 
 Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-test/rendered/tag/index.html` exist?
 
-[[!tag patch]]
-[[!template id=gitbranch branch=smcv/ready/autoindex author=smcv]]
-[[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv]]
+[[!tag patch user/smcv/ready]]
+[[!template id=gitbranch branch=smcv/ready/autoindex author=smcv
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex]]
+[[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv
+  browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex-more-often]]
 
 > To have a starting point to (maybe) change this, my `ready/autoindex`
 > branch adds a regression test for the current behaviour, both with

From 6daf1f6f3ce9adee3bf3ba327064ad0d6df39038 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:28:17 -0400
Subject: [PATCH 39/75] correct tag

---
 ...nsient_autocreated_tagbase_is_not_transient_autoindexed.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index ba2092f42..b0d88ec6d 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -6,7 +6,7 @@
 
 Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-test/rendered/tag/index.html` exist?
 
-[[!tag patch user/smcv/ready]]
+[[!tag patch users/smcv/ready]]
 [[!template id=gitbranch branch=smcv/ready/autoindex author=smcv
   browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/autoindex]]
 [[!template id=gitbranch branch=smcv/ready/autoindex-more-often author=smcv

From 7c8344b008c19eac9891bcb2b47d03df1beec1a5 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 04:30:00 -0400
Subject: [PATCH 40/75] ready

---
 .../edittemplate_should_support_uuid__44___date_variables.mdwn  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
index b85f3298b..e88f0cc9d 100644
--- a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
+++ b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
@@ -50,7 +50,7 @@ Changes to the structure of `$pagestate{$registering_page}{edittemplate}{$pagesp
 >>> [[!template id=gitbranch branch=smcv/ready/edittemplate
   browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/edittemplate
   author="Jonathon Anderson, [[smcv]]"]]
->>> Here is a version of that branch that I would merge if I could.
+>>> Here is a version of that branch that I [[would merge|users/smcv/ready]] if I could.
 >>> Changes since Jonathon's version:
 >>>
 >>> * only generate a UUID if needed

From 2c18086a74ead49dddf6a50e56faf3cb7fdb9f0c Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 05:24:06 -0400
Subject: [PATCH 41/75] review

---
 doc/todo/calendar_autocreate.mdwn | 103 ++++++++++++++++++++++++++++++
 1 file changed, 103 insertions(+)

diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index 6cb15df47..26466bca6 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -14,3 +14,106 @@ won't be offended if you correct stuff you consider awkward):
 [[!template  id=gitbranch branch=spalax/calendar-autocreate browse="https://github.com/paternal/ikiwiki/tree/calendar-autocreate" author="[[Louis|spalax]]"]]
 
 --[[Louis|spalax]]
+
+> An attempt at a review (although note that I don't have commit access,
+> so my opinion is not final):
+>
+> Should `calendar_autocreate_commit` really default to 1? I would personally
+> expect that any new features that synthesize new pages should not commit
+> them by default - I'd prefer to avoid cluttering git history with generated
+> pages. (Indeed, should the option even exist?)
+>
+> I'd personally do the conditional in gencalendaryear more like:
+>
+> [[!format perl """
+return unless $config{calendar_autocreate};
+"""]]
+>
+> to reduce the indentation depth of the more interesting code.
+>
+> The recursion to generate missing years:
+>
+> [[!format perl """
+if (not exists $wikistate{calendar}{minyear}) {
+        $wikistate{calendar}{minyear} = $year;
+} elsif ($wikistate{calendar}{minyear} > $year) {
+        gencalendaryear($year + 1);
+        $wikistate{calendar}{minyear} -= 1;
+}
+"""]]
+>
+> does seem to be correct on closer examination, but it took me a while
+> to work out that it would actually do the right thing by recursing:
+>
+> * generate 2005
+>   * recurse to generate 2006
+>     * recurse to generate 2007
+>       * recurse to generate 2008
+>         * recurse to generate 2009
+>           * recurse to try to generate 2010 (no effect)
+>         * minyear = minyear - 1 = 2010 - 1 = 2009
+>       * minyear = minyear - 1 = 2009 - 1 = 2008
+>     * minyear = minyear - 1 = 2008 - 1 = 2007
+>   * minyear = minyear - 1 = 2007 - 1 = 2006
+> * minyear = minyear - 1 = 2006 - 1 = 2005
+>
+> I think it might be clearer (as well as less
+> recursion-happy) to use iteration:
+>
+> * generate 2005
+>   * recurse to generate 2006
+>   * ...
+>   * recurse to generate 2009
+> * minyear = 2005
+>
+> something like this:
+>
+> [[!format perl """
+sub gencalendaryear {
+        my $year = shift;
+        my %params = @_;
+        ...
+        # generate this year
+        ...
+        # Filling potential gaps in years [...] years 2006 to 2009.
+        return if $params{norecurse};
+        if (not exists $wikistate{calendar}{minyear}) {
+                $wikistate{calendar}{minyear} = $year;
+        } elsif ($wikistate{calendar}{minyear} > $year) {
+                foreach my $other ($year + 1 .. $wikistate{calendar}{minyear} - 1) {
+                        gencalendar($year, norecurse => 1);
+                }
+                $wikistate{calendar}{minyear} = $year;
+        }
+        # ... and the opposite for maxyear
+}
+"""]]
+>
+> I'm not sure about generating missing years at all, though: if the
+> generation is entirely dynamic, and there were no posts at all during
+> a particular year (or month for that matter), shouldn't we just skip
+> the year/month? That seems to be what e.g. Wordpress does.
+>
+> This piece of ikiwiki-calendar functionality is lost:
+>
+> [[!format diff """
+- ... It also refreshes the wiki, updating the calendars to
+-highlight the current day. This command is typically run at midnight from
+-cron.
+"""]]
+>
+> If I understand correctly, the highlight will be on the day at which
+> the wiki was last refreshed, which seems arbitrary and confusing.
+> If ikiwiki-calendar is not used, I'd say there should just not be a
+> highlight for today (although I'm not sure how best to implement that -
+> perhaps a config option representing "I am going to use ikiwiki-calendar").
+>
+> [[!format diff """
+-\[[!template id=plugin name=calendar author="\[[ManojSrivastava]]"]]
+-\[[!tag type/widget]]
+"""]]
+>
+> Why did you remove that? It's useful information about the plugin
+> which I think ought to stay.
+>
+> --[[smcv]]

From 9550d2c92c296e32c40e36c87d7b34492c7749c3 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 05:35:57 -0400
Subject: [PATCH 42/75] yes please

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

diff --git a/doc/todo/upload__95__figure.mdwn b/doc/todo/upload__95__figure.mdwn
index 52034c21b..d8dd65921 100644
--- a/doc/todo/upload__95__figure.mdwn
+++ b/doc/todo/upload__95__figure.mdwn
@@ -8,3 +8,13 @@ Unfortunately, Github shows [[raw code|https://github.com/paternal/ikiwiki/blob/
 
 --[[Louis|spalax]]
 
+> Unfortunately SVG can contain embedded JavaScript, so anyone who can
+> upload arbitrary SVG to this wiki can execute JavaScript in its security
+> context, leading to stealing login cookies and other badness. GitHub
+> won't display arbitrary user-supplied SVG for the same reasons.
+>
+> I've seen various attempts to sanitize SVG via a whitelist, but it's
+> just too large a specification to be confident that you're right, IMO.
+>
+> This particular SVG [[looks good to me|users/smcv/ready]] and I've
+> mirrored it in my own git repo. --[[smcv]]

From 9f49766ff0da3fd4675c89e111581714c32395c6 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 05:40:29 -0400
Subject: [PATCH 43/75] review desired

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

diff --git a/doc/todo/document_dependency_influences_in_code.mdwn b/doc/todo/document_dependency_influences_in_code.mdwn
index 18afb3df2..dd6cb8112 100644
--- a/doc/todo/document_dependency_influences_in_code.mdwn
+++ b/doc/todo/document_dependency_influences_in_code.mdwn
@@ -1,6 +1,6 @@
 [[!template id=gitbranch branch=smcv/ready/document-success-reason author="[[smcv]]"
 browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/document-success-reason]]
-[[!tag patch]]
+[[!tag patch users/smcv/ready]]
 
 Whenever I look at dependency calculation, for instance to solve
 [[bugs/editing gitbranch template is really slow]], it takes me a while to

From a6d4b11fe36e06a7beaa6a99395356ffe39668db Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 05:41:06 -0400
Subject: [PATCH 44/75]

---
 .../possible_to_post_comments_that_will_not_be_displayed.mdwn   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn b/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn
index 488fa0066..bb6cd17d3 100644
--- a/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn
+++ b/doc/bugs/possible_to_post_comments_that_will_not_be_displayed.mdwn
@@ -1,6 +1,6 @@
 [[!template id=gitbranch branch=smcv/ready/comments author="[[smcv]]"
 browse="http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/comments"]]
-[[!tag patch]]
+[[!tag patch users/smcv/ready]]
 
 The ability to post comments depends on several factors:
 

From 291bd2e10910d3c218898177898e9fbe4fcca279 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 05:41:54 -0400
Subject: [PATCH 45/75]

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

diff --git a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
index 057a50f0c..c7d0ffbe2 100644
--- a/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
+++ b/doc/bugs/editing_gitbranch_template_is_really_slow.mdwn
@@ -33,7 +33,7 @@ of the problem is that it evaluates the pagespec
 > [[!template id=gitbranch branch=smcv/ready/perf
 author="[[Simon McVittie|smcv]]"
 browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/perf]]
-> [[!tag patch]]
+> [[!tag patch users/smcv/ready]]
 >
 > Previously, if a page like `plugins/trail` contained a conditional like
 >

From 4dd55b984fa93db23646eb4c84511afec38601f0 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 05:51:05 -0400
Subject: [PATCH 46/75] I think this is ready

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

diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index aae75a304..98d1cf235 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -198,7 +198,7 @@ Please, let me know what to do to avoid this kind of error.
 
 [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
   browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
-[[!tag patch]]
+[[!tag patch users/smcv/ready]]
 Branch and directive renamed to `ready/templatebody` as chrysn suggested.
 It's on-by-default now (or will be if that branch is merged).
 Joey, any chance you could review this?

From f36514d27f4975fcb38926f53b557c680cbb38fb Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 06:07:28 -0400
Subject: [PATCH 47/75] semi-review; any chance of tests?

---
 doc/bugs/svg_and_pdf_conversion_fails.mdwn | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
index da241b4bc..c159da5ad 100644
--- a/doc/bugs/svg_and_pdf_conversion_fails.mdwn
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -25,3 +25,21 @@ should be safe for inclusion.
 > meantime, i noticed that the desired effect doesn't happen when no explicit
 > size is set. as scalable graphics don't necessarily have a natural size
 > anyway, i don't consider that a showstopper. --[[chrysn]]
+
+>> This all looks good in principle, but I would like to do a more detailed
+>> review, and test it with "real ImageMagick" in case its behaviour differs
+>> from GraphicsMagick.
+>>
+>> An automated regression test for the desired behaviour in `t/` would
+>> be great. There are SVGs and PNGs in the docwiki already; there are no
+>> JPEGs or PDFs, but perhaps you could add a trivially small example
+>> of each to `t/`? Imitating `t/tag.t` or `t/trail.t`, and skipping the
+>> test if the required modules are missing like `t/podcast.t` does,
+>> seems like it would work best.
+>>
+>> I agree that everything not in an interoperable web format should be
+>> converted to PNG when it's scaled down, but yes, that's more likely
+>> to be a breaking change, so it seems best to do that as a separate
+>> branch. In practice I think this means JPEG -> JPEG and everything
+>> else -> PNG, since JPEG is commonly used for photos and photo-like
+>> images that don't compress well under lossless compression. --[[smcv]]

From 75b66e02bc151196364dea524b6076aa74f4d791 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 06:18:04 -0400
Subject: [PATCH 48/75] potential user-annoyance issue

---
 ...mail_fails_with_some_openid_providers.mdwn | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn b/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn
index 9ff36b98d..dd5016619 100644
--- a/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn
+++ b/doc/bugs/notifyemail_fails_with_some_openid_providers.mdwn
@@ -67,3 +67,25 @@ Any other ideas? --[[anarcat]]
 > Note: it seems that my email *is* given by my OpenID provider, no idea why this is not working, but the fix proposed in my branch works. --[[anarcat]]
 
 >> Note: this is one of two patches i need to apply at every upgrade. The other being [[can__39__t_upload_a_simple_png_image:_prohibited_by_allowed__95__attachments___40__file_MIME_type_is_application__47__octet-stream...]]. --[[anarcat]]
+
+>>> Is there any sort of check that the owner of the given email address
+>>> wants to receive email from us, or way for the owner of that email
+>>> address to stop getting the emails?
+>>>
+>>> With passwordauth, if someone maliciously subscribes my email
+>>> address to high-traffic pages or something (by using it as the
+>>> email address of their wiki login), I can at least use
+>>> password-recovery to hijack their account and unsubscribe myself.
+>>> If they're signing in with an OpenID not associated with my
+>>> email address and then changing the email address in the userdb
+>>> to point to me, I don't think I can do that.
+>>>
+>>> With OpenID, I think we're just trusting that the OpenID provider
+>>> wouldn't give us an unverified email address, which also seems
+>>> a little unwise.
+>>>
+>>> It might be better to give ikiwiki a concept of verifying an
+>>> email address (the usual send-magic-token flow) and only be
+>>> willing to send notifications to a verified address?
+>>>
+>>> --[[smcv]]

From d3bf41a4192bd2b66f9d77b81002646caa7c00ce Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 06:49:13 -0400
Subject: [PATCH 49/75] more thoughts about evaluating pagespecs "too soon"

---
 .../conditional_preprocess_during_scan.mdwn   | 55 +++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/doc/bugs/conditional_preprocess_during_scan.mdwn b/doc/bugs/conditional_preprocess_during_scan.mdwn
index 1ba142331..739be8286 100644
--- a/doc/bugs/conditional_preprocess_during_scan.mdwn
+++ b/doc/bugs/conditional_preprocess_during_scan.mdwn
@@ -55,3 +55,58 @@ reprocessed is done so in the same conditions as the original call.
 >> with vicious conditional dependency circles that would break/unbreak
 >> depending on which pass we are in. And I believe this is an intrinsic
 >> limitation of the system, which cannot be solved at all.
+
+>>> One way forward that I can think of for this issue is to
+>>> have a way to tell `\[[!if]]` which answer it should assume for
+>>> scanning purposes, so it would assume that answer when running
+>>> in the scan phase, and really evaluate the pagespec when running
+>>> in the render phase. For instance:
+>>>
+>>>     \[[!if test="enabled(foo)" scan_assume=yes then="""
+>>>     \[[!foo]]
+>>>     """]]
+>>>
+>>> could maybe scan \[[!foo]] unconditionally.
+>>>
+>>> This makes me wonder whether `\[[!if]]` was too general: by having
+>>> the full generality of pagespecs, it reduces its possible uses to
+>>> "those contexts where pagespecs work".
+>>>
+>>> Another possibility might be to have "complex" pagespecs and sort
+>>> orders (those whose correct answer requires scanning to have completed,
+>>> like `link()` and sorting by `meta(title)`) throw an error when used in
+>>> the scan phase, but simple pagespecs like `enabled()` and `glob()`, and
+>>> simple sort orders like `title` and `path`, could continue to work?
+>>> My `wip-too-soon` work-in-progress branch is heading in this direction,
+>>> although it currently makes `pagespec_match` fail completely and does
+>>> not even allow "simple" pagespecs and sort orders.
+>>>
+>>> At the moment, if a pagespec cannot be evaluated, `\[[!if]]` will
+>>> produce neither the `then` clause nor the `else` clause. This could
+>>> get pretty confusing if it is run during the scan phase and produces
+>>> an error, then run during the render phase and succeeds: if you had,
+>>> say,
+>>>
+>>>     \[[!if run_during_scan=1 test="link(foo)" then="""
+>>>     there is a link to foo
+>>>     \[[!tag there_is_a_link_to_foo]]
+>>>     """ else="""
+>>>     there is no link to foo
+>>>     \[[!tag there_is_no_link_to_foo]]
+>>>     """]]
+>>>
+>>> then the resulting page would contain one of the snippets of text,
+>>> but its metadata would contain neither of the tags. Perhaps the plugin
+>>> would have to remember that it failed during the scan phase, so that
+>>> it could warn about the failure during the render phase instead of,
+>>> or in addition to, producing its normal output?
+>>>
+>>> Of the conditional-specific tests, `included()` and `destpage(glob)`
+>>> can never match during scan.
+>>>
+>>> Does anyone actually use `\[[!if]]` in ways that they would want to
+>>> be active during scan, other than an `enabled(foo)` test?
+>>> I'm increasingly tempted to add `\[[!ifenabled foo]]` to solve
+>>> that single case, and call that a solution to this bug...
+>>>
+>>> --[[smcv]]

From e68756dc789b45b8ecf5e9b472467bc57c84676a Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 07:12:58 -0400
Subject: [PATCH 50/75] review

---
 ...plates_for_whole_sections_of_the_site.mdwn | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn
index 0dbda8a3a..1fa710f8f 100644
--- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn
+++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn
@@ -39,3 +39,25 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch
 >>>>> --[[KathrynAndersen]]
 
 Just a quick note that Kathryn's branch is ready.[[!template id=gitbranch branch=rubykat/pagetemplate author="[[KathrynAndersen]]"]][[!tag patch]] --[[Will]]
+
+> Review:
+>
+> The indentation seems odd. IkiWiki is mostly indented with hard tabs;
+> this seems to be a mixture of tabs and spaces, assuming 4 spaces per tab.
+>
+> [[!format perl """
+sub checkconfig () {
+...
+               ! defined IkiWiki::template_file($tmpl))
+"""]]
+>
+> I think `checkconfig` is too soon to rely on `template_file`
+> producing correct results? It looks in `%pagesources` which has not
+> yet been updated.
+>
+> If we had a "just before building" hook, that would be a good time
+> to emit warnings; or doing it once per run, on-demand, triggered
+> by the first call to the `templatefile` hook could work. Or the
+> hook could just silently ignore bad pagespecs?
+>
+> --[[smcv]]

From e187c0bb3cc9ce48a757dffd0e1006b25382997e Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Fri, 4 Jul 2014 23:32:39 +0200
Subject: [PATCH 51/75] unit tests available

---
 doc/bugs/svg_and_pdf_conversion_fails.mdwn | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
index c159da5ad..ac18fe8aa 100644
--- a/doc/bugs/svg_and_pdf_conversion_fails.mdwn
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -43,3 +43,16 @@ should be safe for inclusion.
 >> branch. In practice I think this means JPEG -> JPEG and everything
 >> else -> PNG, since JPEG is commonly used for photos and photo-like
 >> images that don't compress well under lossless compression. --[[smcv]]
+
+>>> i've added a unit test and tested it with the [[!debsid perlmagick]]
+>>> package, the [[!debsid graphicsmagick-libmagick-dev-compat]] package and
+>>> the experimental [[!debpts libimage-magick-perl]] package (where the
+>>> [[!debpts libmagickcore-6.q16-2-extra]] package is required too), in the
+>>> meantime filing [[!debbug 753770]]. (why is it that it sometime seems i
+>>> find more bugs in ikiwiki's dependencies than in itself when working with
+>>> it?)
+>>>
+>>> the unit test also checks for file removal when it is not created any more,
+>>> which works, so my biggest fear about the all-to-png change is unwarranted.
+>>> i'll have a look at that some time, but i think as things are, this is
+>>> ready now, please review again. --[[chrysn]]

From f53cb3bd0fcb952c0cc2999627c14c1f7ad308f4 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 18:39:35 -0400
Subject: [PATCH 52/75] add branch, with a smoke-test for inline

---
 ...form__61__no__93____93___doesn__39__t_disable_it.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn b/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
index 70deda2ab..4469db4b5 100644
--- a/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
+++ b/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
@@ -1,3 +1,8 @@
+[[!tag patch user/smcv/ready]]
+[[!template id=gitbranch branch=smcv/ready/postform-no
+author="[[Simon McVittie|smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/postform-no]]
+
 The [[ikiwiki/directive/inline]] directive generates a form if
 it has either rootpage, or postform with a "yes-like" value. This
 means that
@@ -9,4 +14,8 @@ mentioning rootpage there is useless).
 
 See also [[forum/How_to_disable_"Add_a_new_post_titled:"_submission_form?]].
 
+My `ready/postform-no` branch also contains a trivial regression test for
+`inline`. So far the only thing it really tests is that this bug was fixed,
+not the actual inlining of pages, but it's a start.
+
 --[[smcv]]

From d41e6902472503b0b3e1b180acdde02cb501ab42 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Fri, 4 Jul 2014 18:40:20 -0400
Subject: [PATCH 53/75] I keep getting this tag wrong

---
 ...ne_postform__61__no__93____93___doesn__39__t_disable_it.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn b/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
index 4469db4b5..d0a8a6e01 100644
--- a/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
+++ b/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
@@ -1,4 +1,4 @@
-[[!tag patch user/smcv/ready]]
+[[!tag patch users/smcv/ready]]
 [[!template id=gitbranch branch=smcv/ready/postform-no
 author="[[Simon McVittie|smcv]]"
 browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/postform-no]]

From d1e714e485a8d0e498ccf7b358dbb7445d18373b Mon Sep 17 00:00:00 2001
From: Louis <spalax@gresille.org>
Date: Sat, 5 Jul 2014 14:26:53 +0200
Subject: [PATCH 54/75] Answer to smcv

---
 doc/todo/calendar_autocreate.mdwn | 43 +++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index 26466bca6..26c13aaa3 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -23,6 +23,14 @@ won't be offended if you correct stuff you consider awkward):
 > them by default - I'd prefer to avoid cluttering git history with generated
 > pages. (Indeed, should the option even exist?)
 >
+> > I copied those options from the [[plugins/tag]] plugin: the
+> > `tag_autocreate_commit` option exists and default to 1.
+> >
+> > It should definitely exists: suppose a calendar page is created and not
+> > commited, and later, someone tries to push some changes where a page with
+> > the same name has been created. This would result in a conflict. The
+> > `calendar_autocreate_commit` prevents this.
+>
 > I'd personally do the conditional in gencalendaryear more like:
 >
 > [[!format perl """
@@ -31,6 +39,8 @@ return unless $config{calendar_autocreate};
 >
 > to reduce the indentation depth of the more interesting code.
 >
+> > [[I agree|https://github.com/paternal/ikiwiki/commit/7f18c1ce48630507b744fa56b83999e8ca684606]]
+>
 > The recursion to generate missing years:
 >
 > [[!format perl """
@@ -89,11 +99,25 @@ sub gencalendaryear {
 }
 """]]
 >
+>
+> > [[I agree|https://github.com/paternal/ikiwiki/commit/7f18c1ce48630507b744fa56b83999e8ca684606]]
+>
 > I'm not sure about generating missing years at all, though: if the
 > generation is entirely dynamic, and there were no posts at all during
 > a particular year (or month for that matter), shouldn't we just skip
 > the year/month? That seems to be what e.g. Wordpress does.
 >
+> > [[Done|https://github.com/paternal/ikiwiki/commit/59b46942e01b32138d056381249effbbaf773892]].
+> > I added an option `calendar_fill_gaps` to chose between the two
+> > alternatives (since skipping empty months and years would change the
+> > default behaviour of this plugin).
+> >
+> > I think the code is a bit ugly at some places. Perl is not one the the
+> > programming languages I am fluent into. Sorry.
+> >
+> > PS: Good idea, thought. I now have to implement a similar thing for
+> > [[plugins/contrib/jscalendar]].
+>
 > This piece of ikiwiki-calendar functionality is lost:
 >
 > [[!format diff """
@@ -108,6 +132,20 @@ sub gencalendaryear {
 > highlight for today (although I'm not sure how best to implement that -
 > perhaps a config option representing "I am going to use ikiwiki-calendar").
 >
+> > This is not lost. What ikiwiki-calendar do is simply: build the missing
+> > `archive/year/month` pages, and run `ikiwiki -refresh`. With my patch, the
+> > `ikiwiki -refresh` includes:
+> >
+> > - the build of missing `archive/year/month` pages;
+> > - highlighting the current day (this was already the case).
+> >
+> > So one can simply drop the `ikiwiki-calendar ...` for `ikiwiki --refresh
+> > ...` in cron to get the same result.
+> >
+> > I
+> > [[tried|https://github.com/paternal/ikiwiki/commit/7a92444e56fe023cea3b074dc5e6b5c4acdb6114]]
+> > to make the documentation clearer.
+>
 > [[!format diff """
 -\[[!template id=plugin name=calendar author="\[[ManojSrivastava]]"]]
 -\[[!tag type/widget]]
@@ -116,4 +154,9 @@ sub gencalendaryear {
 > Why did you remove that? It's useful information about the plugin
 > which I think ought to stay.
 >
+> > Oops! It was a mistake.
+> > [[Corrected|https://github.com/paternal/ikiwiki/commit/de9842ecc8914e11e73148dae78cd6909b535262]].
+>
 > --[[smcv]]
+>
+> > Thank you for this review. -- [[Louis|spalax]]

From 6eb89492f7b98003227fddeea6bb03d0f36b5d88 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sat, 5 Jul 2014 16:42:32 +0200
Subject: [PATCH 55/75] comment on autoindex branch

---
 ...tocreated_tagbase_is_not_transient_autoindexed.mdwn | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index b0d88ec6d..225a60141 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -31,3 +31,13 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te
 > git repositories any more? My `autoindex-more` branch changes
 > the logic so it will do what you want in the `autoindex_commit => 0`
 > case, and amends the appropriate regression test. --[[smcv]]
+
+>> the autoindex-more-often branch looks good to me in general.
+>>
+>> i do have doubts about the 3ba2ef1a patch ("remove unnecessary special case
+>> for transient underlay"): now that we consider the complete transient
+>> directory as well, the sequence in which the refresh hooks are called starts
+>> to matter, and pages created by other plugins in a similar fashion as by
+>> autoindex will only be included the next time refresh gets called.
+>>
+>> --[[chrysn]]

From bbe22b70d1d2f63e3f11af8493362b7f8673512f Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sat, 5 Jul 2014 17:52:25 +0200
Subject: [PATCH 56/75] reviewed patch, suggesting minor addition

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

diff --git a/doc/todo/document_dependency_influences_in_code.mdwn b/doc/todo/document_dependency_influences_in_code.mdwn
index dd6cb8112..4dfbb1486 100644
--- a/doc/todo/document_dependency_influences_in_code.mdwn
+++ b/doc/todo/document_dependency_influences_in_code.mdwn
@@ -20,3 +20,9 @@ should count as static or dynamic, perhaps analogous to
 and linked from the `match_foo` section of [[plugins/write]]. I haven't
 written this myself because I'm somewhat stuck on the subtlety of what
 "indirectly influenced" means... --[[smcv]]
+
+>> the documentation looks correct to me, as far as i understand dependencies.
+>> the documentation on `influences_static` could add a "Static influences are
+>> what make `pagespec_match_list` more efficient than repeated
+>> `pagespec_match_list`." to give an idea of why it is there in the first
+>> place. --[[chrysn]]

From 5935c6b17dcf05b8ec7d10623098961ccf059555 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sat, 5 Jul 2014 18:08:08 +0200
Subject: [PATCH 57/75] suggestion on formatted times

---
 ...ttemplate_should_support_uuid__44___date_variables.mdwn | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
index e88f0cc9d..73f04adf0 100644
--- a/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
+++ b/doc/todo/edittemplate_should_support_uuid__44___date_variables.mdwn
@@ -70,3 +70,10 @@ Changes to the structure of `$pagestate{$registering_page}{edittemplate}{$pagesp
 >>> timestamp variables/objects, so I left the naming as it was.
 >>>
 >>> --[[smcv]]
+
+>>>> the ready/edittemplate branch looks good to me too. `formatted_time` and
+>>>> `html_time` probably don't hurt, but personally i'd not add either and
+>>>> instead expose displaytime as a directive, for otherwise migrating to
+>>>> html5 would leave old evaluations of displaytime around in the repository.
+>>>> (example template: `\[[!meta date="<TMPL_VAR time>"]]I wrote this post at
+>>>> \[[!displaytime "<TMPL_VAR time>"]]`). --[[chrysn]]

From 996eedc3ba03ce48e234914803da42c66c5be3d9 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sat, 5 Jul 2014 19:01:42 +0200
Subject: [PATCH 58/75] simple review for straightforward branch

---
 ...ne_postform__61__no__93____93___doesn__39__t_disable_it.mdwn | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn b/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
index d0a8a6e01..7e7548657 100644
--- a/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
+++ b/doc/bugs/__91____91____33__inline_postform__61__no__93____93___doesn__39__t_disable_it.mdwn
@@ -19,3 +19,5 @@ My `ready/postform-no` branch also contains a trivial regression test for
 not the actual inlining of pages, but it's a start.
 
 --[[smcv]]
+
+>> this looks simple, straightforward and good to me --[[chrysn]]

From 875f1e50cbc7c9b5ee7153747b4c92750eef10cf Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sat, 5 Jul 2014 19:11:47 +0200
Subject: [PATCH 59/75] comments on templatebody and phases

---
 doc/bugs/template_creation_error.mdwn | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/doc/bugs/template_creation_error.mdwn b/doc/bugs/template_creation_error.mdwn
index 98d1cf235..d3c0bcca5 100644
--- a/doc/bugs/template_creation_error.mdwn
+++ b/doc/bugs/template_creation_error.mdwn
@@ -255,3 +255,10 @@ same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
 >>> is a start towards that; the docwiki builds successfully, but
 >>> the tests that use IkiWiki internals also need updating to
 >>> set `$phase = PHASE_RENDER` before they start preprocessing. --s
+
+>>>> reviewing those modifications, i think this is a good way to go. along
+>>>> with warning about pagespecs evaluated in scan phase, i think it should be
+>>>> an error to invoke scan in the render phase; that would mean that
+>>>> `readtemplate` needs to check whether it's invoked as a scan or not to
+>>>> decide whether to scan the template page, but would be generally more
+>>>> robust for future plugin writing. --[[chrysn]]

From 85cf3fcfaae584b0699e9b8c7cdcffb9a031c41d Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sun, 6 Jul 2014 14:25:14 +0200
Subject: [PATCH 60/75] give link and example for possible autoindex conflicts

---
 ...nt_autocreated_tagbase_is_not_transient_autoindexed.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index 225a60141..1fc80804e 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -40,4 +40,10 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te
 >> to matter, and pages created by other plugins in a similar fashion as by
 >> autoindex will only be included the next time refresh gets called.
 >>
+>> *addendum:* i just found where i discussed the issue of fighting transient
+>> pages last, it was on [[todo/alias directive]]. the example cited there
+>> (conflicts with autotag) would probably work here as well. (imagine a
+>> `tags/project/completed` and a `tags/project/inprogress` exist, and a page
+>> is tagge `tags/project`. will that be an autoindex or an autotag?)
+>>
 >> --[[chrysn]]

From 2bb5085785d05d5f3fa81b7adcfb8678c7c67ae8 Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@web>
Date: Sun, 6 Jul 2014 12:33:47 -0400
Subject: [PATCH 61/75] Forum: Ask about strange link appearance with trail and
 actiontabs

---
 ...il_plugin_links_with_Actiontabs_theme.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)
 create mode 100644 doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn

diff --git a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
new file mode 100644
index 000000000..8c033eade
--- /dev/null
+++ b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
@@ -0,0 +1,19 @@
+I'm using the trail plugin with the actiontabs theme, and the prev/next buttons
+seem to appear in a strange way on the page.
+
+I use modified CSS, but it changes just the colors and some font sizes, but
+nothing related to positions and trails.
+
+Here's an example - the top prev/next links appear above the action tabs.
+Is this normal? I'm using the ikiwiki version from Debina 7 stable.
+
+- If you use OpenNIC: <http://www.partager.null/tools/systems/admin-guides/ssl/Preparing_the_Tools/>
+- If you don't (will work only until the IP changes): <http://85.65.55.38/tools/systems/admin-guides/ssl/Preparing_the_Tools/>
+
+I can look at the CSS and try to figure this out, but I don't know much CSS or
+how the trail plugin works. If anyone uses trails, especially with actiontabs, and
+can help me - it will be great.
+
+Thanks in advance!
+
+--[[fr33domlover]]

From 48b869cf42d8be66f4a76a3c683416d2c1b5497e Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@web>
Date: Sun, 6 Jul 2014 12:36:23 -0400
Subject: [PATCH 62/75] Fix typos

---
 doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
index 8c033eade..f6d7ee27d 100644
--- a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
+++ b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
@@ -1,11 +1,11 @@
-I'm using the trail plugin with the actiontabs theme, and the prev/next buttons
+I'm using the trail plugin with the actiontabs theme, and the prev/next links
 seem to appear in a strange way on the page.
 
-I use modified CSS, but it changes just the colors and some font sizes, but
-nothing related to positions and trails.
+I use modified CSS, but it changes just the colors and some font sizes.
+Nothing related to positions and trails.
 
 Here's an example - the top prev/next links appear above the action tabs.
-Is this normal? I'm using the ikiwiki version from Debina 7 stable.
+Is this normal? I'm using the ikiwiki version from Debian 7 stable.
 
 - If you use OpenNIC: <http://www.partager.null/tools/systems/admin-guides/ssl/Preparing_the_Tools/>
 - If you don't (will work only until the IP changes): <http://85.65.55.38/tools/systems/admin-guides/ssl/Preparing_the_Tools/>

From 6236b94860b3f67cce14b3a2301b9ffbf14fc798 Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@web>
Date: Sun, 6 Jul 2014 14:45:26 -0400
Subject: [PATCH 63/75] Comment to myself :-)

---
 doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
index f6d7ee27d..0ff284294 100644
--- a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
+++ b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
@@ -17,3 +17,9 @@ can help me - it will be great.
 Thanks in advance!
 
 --[[fr33domlover]]
+
+> I looked at the file *page.tmpl* and it seems I may be able to change
+> the trail link location if I edit that file. Would it be a good/possible solution to
+> edit it and put it in the git repo to be used instead of the default one?
+>
+> --[[fr33domlover]]

From 83afe165366fd6cffd42ea47d6604d90a07143a3 Mon Sep 17 00:00:00 2001
From: Christopher Baines <mail@cbaines.net>
Date: Sun, 6 Jul 2014 22:05:45 +0100
Subject: [PATCH 64/75] Respond to smcv on the album discussion page

---
 doc/plugins/contrib/album/discussion.mdwn | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index 58c0e640f..d8f55eb33 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -614,6 +614,14 @@ concatenates them: for instance, `/usr/share/ikiwiki/themes/actiontabs/style.css
 is the output of `cat doc/style.css themes/actiontabs/style.css`. So adding it
 to `doc/style.css` should be enough?
 
+> I don't think this is the case? Or at least, looking at the generated
+> stylesheet for the examples built using my branch, I would expect there to be
+> two copies of the album rules in the stylesheet [1], but there does not
+> appear to be. This could quite easily be a result of some mistake in my part
+> in not isolating the build though. --[[cbaines]]
+>
+> 1: <http://cbaines.net/projects/ikiwiki/album/dest/basic-actiontabs/style.css>
+
 Regarding commit `Change the default thumbnail size`: as far as I
 understand it, `size => 96x96` is meant to set the image size to
 be as large as possible given these constraints: width ≤ 96px,
@@ -623,3 +631,7 @@ are you seeing, and which versions of Imagemagick and Perlmagick
 are you using?
 
 --[[smcv]]
+
+> I rebuilt the examples using both your album4 and album5 branches, and I only
+> see this in the album4 branch. So this is probably ok to ignore.
+> --[[cbaines]]

From 11c219dcf1f90ae061e83f58471d36eb5495f613 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 17:24:43 -0400
Subject: [PATCH 65/75]

---
 .../Trail_plugin_links_with_Actiontabs_theme.mdwn    | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
index 0ff284294..81352db47 100644
--- a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
+++ b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
@@ -23,3 +23,15 @@ Thanks in advance!
 > edit it and put it in the git repo to be used instead of the default one?
 >
 > --[[fr33domlover]]
+
+>> That's how I intended trails to look with actiontabs:
+>> <http://actiontabs.hosted.pseudorandom.co.uk/posts/second_post/> is
+>> another example.
+>>
+>> With the way the actiontabs theme works, if you want to move the
+>> trail bits down into the content area (white background in the
+>> unedited theme) you might have to alter both `page.tmpl`
+>> and the actiontabs CSS. You'll see that the actiontabs CSS
+>> has a special case for trails, because the tabs and the trail
+>> links would overlap otherwise - you might have to remove
+>> that special case. --[[smcv]]

From 7bf7f2c442a9a5d89bed2d65a7a32b2af1f76157 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 17:35:18 -0400
Subject: [PATCH 66/75]

---
 ..._tagbase_is_not_transient_autoindexed.mdwn | 20 +++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index 1fc80804e..887d3387f 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -47,3 +47,23 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te
 >> is tagge `tags/project`. will that be an autoindex or an autotag?)
 >>
 >> --[[chrysn]]
+
+>>> That's a fair point. I think what happens is down to commit vs. refresh
+>>> timing.
+>>>
+>>> If pages tagged t/p/c, t/p/i and t/p are all created between one
+>>> refresh and the next, with none of those tag pages existing, I think the
+>>> answer is that they would all be autotags, because until t/p/c and
+>>> t/p/i are created, there's no reason to need t/p as an autoindex.
+>>>
+>>> If there were already pages tagged t/p/c and t/p/i at the previous
+>>> refresh, then t/p would already be an autoindex, and that's a
+>>> valid page, so autotagging wouldn't touch it.
+>>>
+>>> I can't see much reason to prefer one over the other; the ideal answer
+>>> is probably to have a tag-cloud *and* a list of child pages, but this
+>>> seems a weird enough thing to do that I'd be OK with a wiki user
+>>> having to disambiguate it themselves. "Whichever automatic process
+>>> happens first, happens" is at least easy to explain, and I consider
+>>> both autoindices and autotags to be time-saving conveniences rather
+>>> than something fundamental. --s

From cfbad20f67ff1b6e5b63f9ffbdd12664368cbe18 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sun, 6 Jul 2014 23:47:06 +0200
Subject: [PATCH 67/75] auto-* ambiguity: it's ok for me

---
 ...ent_autocreated_tagbase_is_not_transient_autoindexed.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
index 887d3387f..0673aa674 100644
--- a/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
+++ b/doc/bugs/transient_autocreated_tagbase_is_not_transient_autoindexed.mdwn
@@ -67,3 +67,8 @@ Shouldn't `ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn` and `ikiwiki-tag-te
 >>> happens first, happens" is at least easy to explain, and I consider
 >>> both autoindices and autotags to be time-saving conveniences rather
 >>> than something fundamental. --s
+
+>>>> i think a behavior that does the right thing when there is a right thing
+>>>> and *something* when there is ambiguity is ok for now; especially, it's
+>>>> not up to the autoindex branch to come up with a solution to the general
+>>>> problem. --[[chrysn]]

From afb0b51f9811ab036978612f9e003bea2ad4a8d6 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 18:03:23 -0400
Subject: [PATCH 68/75] respond; hide fixed bugs by default to reduce clutter

---
 doc/plugins/contrib/album/discussion.mdwn | 149 ++++++++++++++--------
 1 file changed, 93 insertions(+), 56 deletions(-)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index d8f55eb33..dd8c3593e 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -62,6 +62,11 @@ i'm new to ikiwiki, apologies if this is dealt with elsewhere.  -brush
 
 ## design feedback from joeyh on an earlier version
 
+Not entirely relevant any more.
+[[!toggle id="old-design-feedback" text="show"]]
+[[!toggleable id="old-design-feedback" text="""
+[[!toggle id="old-design-feedback" text="hide"]]
+
 You had wanted my feedback on the design of this. I have not looked at the
 code or tried it yet, but here goes. --[[Joey]]	
 
@@ -260,6 +265,7 @@ code or tried it yet, but here goes. --[[Joey]]
 >> changed, and only update those viewers where it has. But the dependency
 >> type stuff is still very new, and not plugin friendly .. so only just
 >> possible, --[[Joey]] 
+"""]]
 
 ----
 
@@ -268,6 +274,10 @@ code or tried it yet, but here goes. --[[Joey]]
 '''I think the "special extension" design is a dead-end, but here's what
 happened when I tried to work out how it would work. --[[smcv]]'''
 
+[[!toggle id="special-extension-sketch" text="show"]]
+[[!toggleable id="special-extension-sketch" text="""
+[[!toggle id="special-extension-sketch" text="hide"]]
+
 Suppose that each viewer is a JPEG-or-GIF-or-something, with extension
 ".albumimage". We have a gallery "memes" with three images, badger,
 mushroom and snake.
@@ -408,10 +418,17 @@ Things that would be nice, and are probably possible:
 * some way to deep-link to memes/badger.jpg with a wikilink, without knowing a
   priori that it's secretly a JPEG (probably harder than it looks - you'd
   have to make a directive for it and it's probably not worth it)
+"""]]
 
 ----
 
-## bug: unable to vary thumbnail size
+## resolved bug reports
+
+[[!toggle id="fixed-bugs" text="show"]]
+[[!toggleable id="fixed-bugs" text="""
+[[!toggle id="fixed-bugs" text="hide"]]
+
+### bug: unable to vary thumbnail size
 
 Hi smcv, great plugin. I am an ikiwiki newbie but so far I've had success using your plugin.
 I've integrated the jquery masonry plugin into the albumitem template and it works great.
@@ -419,11 +436,11 @@ But is there a way to create thumnails of different sizes? I've passed thumnails
 and value to album directive and while it does create the new thumbnail sizes it doesn't use them,
 The 96x96 thumbnails still appear on the page no matter what I do. - jaime
 
-> [[KathrynAndersen]] fixed this, see below. --[[smcv]]
+> Fixed in album5 branch, thanks to [[KathrynAndersen]]. --[[smcv]]
 
 ----
 
-## failed installation
+### failed installation
 
 Hi, the plugin looks great, but I am probably too dumb to use it ;( here is what I did:
 created page gal.mdwn with just \[\[!album\]\] directive (no arguments) and subdirectory gal/ with images in form img_1234.jpg
@@ -471,7 +488,7 @@ Thanks Lukas
 
 ----
 
-## bug + patch: not all images shown on album page
+### bug + patch: not all images shown on album page
 
 Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work.
 
@@ -480,54 +497,25 @@ Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in albu
 > That sounds like a correct solution. I'll fix that in my branch when I work on
 > this again. --[[smcv]]
 
+>> Fixed in `album5` branch --s
+
 ----
 
-## bug: thumbnailsize doesn't work
+### bug: thumbnailsize doesn't work
 
 As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename.
 
 > [[KathrynAndersen]] fixed this, see below. --[[smcv]]
 
+>> Fixed in `album5` branch --s
+
 Issuing `ikiwiki --rebuild` knocks the system into another gear where the thumbnails show up correctly but this is only due to the html being the same as above (linking to hardcoded thumbnailsize) but the generated thumbnail images are now matching the hardcoded size ignoring the thumbnailsize attribute on the album directive.
 
 For me this behaviour is way beyond my skills to sort out (I'm no coder). The albumplugin ikiwiki combo is very attractive to me and the plugin i soo close to working!
 
 --kjs
 
-----
-
-## wishlist + patch: make clicking on the large image go to the next
-
-I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img`
-
---kjs
-
-> That seems reasonable. I'll consider that when I work on this
-> plugin again next. --[[smcv]]
-
-----
-
-## wishlist from kjs
-
-My wishlist for the plugin would include:
-
-- Reading exif info from the imagefile
-- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow.
-- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
-- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave.
-
---kjs
-
-> I want the first two of those too, perhaps one day I'll get round to
-> implementing them.
->
-> For the third, you can get the same practical effect using an inline
-> as documented in the main page. --[[smcv]]
->> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
-
-----
-
-## suggested fix for thumbnail size bug
+### suggested fix for thumbnail size bug
 
 I've tracked down the "always showing the 96x96 thumbnails" bug!
 
@@ -578,9 +566,11 @@ Here's a context-diff of my fix:
 >
 > --[[smcv]]
 
+>> Fixed in `album5` --s
+
 ----
 
-## bug: inability to show more than 10 items
+### bug: inability to show more than 10 items
 
 I've found another bug. The album plugin doesn't allow one to have more than 10 items in an album section. This is because it uses "inline" to display album sections, and the default for inline is to show only 10 items. So it only shows 10 items.
 
@@ -596,7 +586,65 @@ What would be good is if the album directive could have a "show" parameter which
 > although I don't know how useful it would be; if it isn't passed, the
 > default should be 0 (unlimited). --[[smcv]]
 
-## cbaines' branch
+>> Fixed in `album5` --s
+
+----
+
+### cbaines' commit to change default thumbnail size
+
+Regarding commit `Change the default thumbnail size`: as far as I
+understand it, `size => 96x96` is meant to set the image size to
+be as large as possible given these constraints: width ≤ 96px,
+height ≤ 96px, and the original aspect ratio is preserved. So I
+would hope that 96x96 doesn't distort the thumbnails. What distortion
+are you seeing, and which versions of Imagemagick and Perlmagick
+are you using?
+
+--[[smcv]]
+
+> I rebuilt the examples using both your album4 and album5 branches, and I only
+> see this in the album4 branch. So this is probably ok to ignore.
+> --[[cbaines]]
+>
+>> OK, I'll assume that was a duplicate of an earlier patch, probably the
+>> one from KathrynAndersen. --s
+
+"""]]
+
+----
+
+## wishlist + patch: make clicking on the large image go to the next
+
+I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img`
+
+--kjs
+
+> That seems reasonable. I'll consider that when I work on this
+> plugin again next. --[[smcv]]
+
+----
+
+## wishlist from kjs
+
+My wishlist for the plugin would include:
+
+- Reading exif info from the imagefile
+- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow.
+- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
+- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave.
+
+--kjs
+
+> I want the first two of those too, perhaps one day I'll get round to
+> implementing them.
+>
+> For the third, you can get the same practical effect using an inline
+> as documented in the main page. --[[smcv]]
+>> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
+
+----
+
+## cbaines' CSS changes
 
 Regarding the CSS changes: I'll try to have a look soon, work out
 what actually changed (since you re-ordered the CSS, so it isn't
@@ -612,7 +660,7 @@ theme's style.css unless you actually want an actiontabs album and
 a blueview album to be styled differently, because the IkiWiki Makefile
 concatenates them: for instance, `/usr/share/ikiwiki/themes/actiontabs/style.css`
 is the output of `cat doc/style.css themes/actiontabs/style.css`. So adding it
-to `doc/style.css` should be enough?
+to `doc/style.css` should be enough? --[[smcv]]
 
 > I don't think this is the case? Or at least, looking at the generated
 > stylesheet for the examples built using my branch, I would expect there to be
@@ -621,17 +669,6 @@ to `doc/style.css` should be enough?
 > in not isolating the build though. --[[cbaines]]
 >
 > 1: <http://cbaines.net/projects/ikiwiki/album/dest/basic-actiontabs/style.css>
-
-Regarding commit `Change the default thumbnail size`: as far as I
-understand it, `size => 96x96` is meant to set the image size to
-be as large as possible given these constraints: width ≤ 96px,
-height ≤ 96px, and the original aspect ratio is preserved. So I
-would hope that 96x96 doesn't distort the thumbnails. What distortion
-are you seeing, and which versions of Imagemagick and Perlmagick
-are you using?
-
---[[smcv]]
-
-> I rebuilt the examples using both your album4 and album5 branches, and I only
-> see this in the album4 branch. So this is probably ok to ignore.
-> --[[cbaines]]
+>
+>> I searched for `/* relevant to the index page */` and found it twice,
+>> so I stand by what I said :-) --s

From f5a05407129eb549330b8308991a1f3b307fc1f3 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 18:40:17 -0400
Subject: [PATCH 69/75] belatedly respond to kjs

---
 doc/plugins/contrib/album/discussion.mdwn | 55 +++++++++++++++++++++++
 1 file changed, 55 insertions(+)

diff --git a/doc/plugins/contrib/album/discussion.mdwn b/doc/plugins/contrib/album/discussion.mdwn
index dd8c3593e..a8779e279 100644
--- a/doc/plugins/contrib/album/discussion.mdwn
+++ b/doc/plugins/contrib/album/discussion.mdwn
@@ -641,6 +641,61 @@ My wishlist for the plugin would include:
 > For the third, you can get the same practical effect using an inline
 > as documented in the main page. --[[smcv]]
 >> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
+>>
+>>> Hmm, OK. That breaks the "one picture : one page" mental model,
+>>> unfortunately. The pictures themselves can't be first-class wiki pages (see
+>>> lengthy design discussions with Joey above) because they aren't something
+>>> that produces HTML, and don't have human-readable text source code.
+>>> In the current (album5) design, the viewer pages that are automatically
+>>> created to go alongside the pictures are basically stand-ins for the
+>>> pictures, as far as metadata, wikilinks, tags and other "first-class
+>>> wiki page" things are concerned.
+>>>
+>>> If there are to be viewer pages elsewhere in the wiki, I don't think
+>>> inheriting the picture's metadata is desired. Suppose you have a
+>>> picture of Alice and Bob in the album "holiday in Exampleton, 2010",
+>>> and it is tagged people/alice, people/bob and places/exampleton; the
+>>> other contexts it appears in might include "pictures of Alice" and
+>>> "pictures near Exampleton". If you look at the tag page for
+>>> places/exampleton, I doubt you want to see that photo listed three
+>>> times - once is enough, there's only one actual photo after all. So
+>>> I think the "main" viewer page should be the only one that has
+>>> the taglinks for people/alice, people/bob, places/exampleton.
+>>>
+>>> My next question is, should the viewer page representing that
+>>> particular picture in its context of "pictures near Exampleton"
+>>> (i.e. its "next" and "previous" links go to the next and
+>>> previous picture near Exampleton, regardless of whether it was
+>>> on an earlier or later visit) be a first-class wiki page
+>>> at all?
+>>>
+>>> * Does it make any sense to comment on "this picture in this
+>>>   context", if your wiki has comments, or should the only
+>>>   place you can comment on it be its "main" viewer page?
+>>> * Is there any need for it to be possible to make a wikilink
+>>>   to that particular picture in that particular context,
+>>>   or does it only need wikilinks "to the picture" (which,
+>>>   as an implementation detail, really go to its "main" viewer
+>>>   page)?
+>>> * Can the picture in that particular context have tags
+>>>   that are orthogonal to the tags its "main" viewer page has?
+>>> * ... and so on for various wiki features
+>>>
+>>> It sound as though the answer might ideally be that this secondary
+>>> viewer page doesn't need to be a first-class wiki page at all,
+>>> only a HTML output... except that the trail plugin works in terms
+>>> of next and previous first-class wiki pages, not next and
+>>> previous HTML outputs, and the HTML-generation pipeline
+>>> is really aimed towards real pages.
+>>>
+>>> Perhaps the secondary viewer page should end up looking
+>>> something like this:
+>>>
+>>>     \[[!albumviewer original=holiday-in-exampleton-2010/img1234
+>>>       comment="To edit picture metadata, edit the original page instead"]]
+>>>
+>>> and one of the side-effects of the albumviewer directive should be to
+>>> replace [[plugins/comments]] with a link to the original? --s
 
 ----
 

From 13ffa4edb29054fe439f4f14da4311b2037408ec Mon Sep 17 00:00:00 2001
From: fr33domlover <fr33domlover@web>
Date: Sun, 6 Jul 2014 18:47:33 -0400
Subject: [PATCH 70/75] Comment on forum item, trail link appearance

---
 .../Trail_plugin_links_with_Actiontabs_theme.mdwn      | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
index 81352db47..decaaa1bc 100644
--- a/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
+++ b/doc/forum/Trail_plugin_links_with_Actiontabs_theme.mdwn
@@ -35,3 +35,13 @@ Thanks in advance!
 >> has a special case for trails, because the tabs and the trail
 >> links would overlap otherwise - you might have to remove
 >> that special case. --[[smcv]]
+
+>>> Thanks, I'll try that. But I've been using those trails in the last
+>>> several hours and I'm beginning to get used to the current
+>>> layout. Maybe I'll just keep it :-)
+>>>
+>>> (Anyway the way trail links look on my wiki is valid, it's exactly
+>>> like on your link, only with different colors. I suppose it's
+>>> just a cosmetic issue then)
+>>>
+>>> --[[fr33domlover]]

From 8031dbf271105acbe06697a5b1f37a9ecab3de5a Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 18:55:11 -0400
Subject: [PATCH 71/75] idea

---
 doc/todo/per-page_comment_control.mdwn | 31 ++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)
 create mode 100644 doc/todo/per-page_comment_control.mdwn

diff --git a/doc/todo/per-page_comment_control.mdwn b/doc/todo/per-page_comment_control.mdwn
new file mode 100644
index 000000000..69937d7a0
--- /dev/null
+++ b/doc/todo/per-page_comment_control.mdwn
@@ -0,0 +1,31 @@
+It might be nice to be able to control [[plugins/comments]] by inserting
+directives in individual pages:
+
+* disable comments where they would normally be enabled, e.g. for a blog
+  post you know is going to cause flamey responses (`\[[!closecomments]]`
+  to reject new comments but display old ones, `\[[!nocomments]]` to
+  hide comments too?)
+
+* direct comments to a different wiki page or an off-site URL,
+  e.g. if you have mentioned/posted something in two places
+  and you want to collect all the comments together
+  (maybe `\[[!commenton page=other/page]]`,
+  `\[[!commenton url="http://newsblog.example.com/the-next-big-thing"]]`?)
+
+* (maybe) enable comments where they would not normally be enabled?
+  (I'm unsure about this one, it would need to be under some level of
+  admin control - maybe a new pagespec for pages where comments are
+  disabled by default but may be enabled by directives)
+
+The use that got me thinking about this is that if the
+[[plugins/contrib/album]] plugin evolves to be able to have the same
+picture appear in more than one trail as kjs requested, all except the
+"original" (defined as the page to which the picture was attached) should
+probably either disable comments, or direct comments to the "original".
+
+I don't plan to work on this myself unless I find that I need it
+(for album or otherwise).
+
+--[[smcv]]
+
+[[!tag wishlist]]

From 3f07701cd9023d7f0325de0aacf50bb583654b52 Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 19:12:35 -0400
Subject: [PATCH 72/75] the transient underlay is good, use it :-)

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

diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index 26c13aaa3..b350dcdec 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -31,6 +31,17 @@ won't be offended if you correct stuff you consider awkward):
 > > the same name has been created. This would result in a conflict. The
 > > `calendar_autocreate_commit` prevents this.
 >
+> > > `tag_autocreate_commit` exists because when tag autocreation
+> > > was introduced, they were always in the `$srcdir` and committed.
+> > > I changed it so that it was possible to put them in the [[plugins/transient]]
+> > > underlay and not commit them.
+> > >
+> > > When automatic tag pages (or autoindex pages) are not committed, they
+> > > go in the transient underlay, which means they can't cause conflicts:
+> > > independent page creation will simply mask them (a page in the
+> > > `$srcdir` hides a page of the same name in an underlay). I thought
+> > > this implementation did the same when not committing? --[[smcv]]
+>
 > I'd personally do the conditional in gencalendaryear more like:
 >
 > [[!format perl """

From 8c8c1bc668a38a353d3f0599302d236d50fa4c5d Mon Sep 17 00:00:00 2001
From: smcv <smcv@web>
Date: Sun, 6 Jul 2014 19:13:15 -0400
Subject: [PATCH 73/75] explain why that default

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

diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index b350dcdec..b37b3c96b 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -34,7 +34,8 @@ won't be offended if you correct stuff you consider awkward):
 > > > `tag_autocreate_commit` exists because when tag autocreation
 > > > was introduced, they were always in the `$srcdir` and committed.
 > > > I changed it so that it was possible to put them in the [[plugins/transient]]
-> > > underlay and not commit them.
+> > > underlay and not commit them. It defaults to 1 to preserve existing
+> > > functionality.
 > > >
 > > > When automatic tag pages (or autoindex pages) are not committed, they
 > > > go in the transient underlay, which means they can't cause conflicts:

From 15a4bacf51df9f5d8f066aff869f9352e62a2d8a Mon Sep 17 00:00:00 2001
From: Louis <spalax@gresille.org>
Date: Mon, 7 Jul 2014 10:43:11 +0200
Subject: [PATCH 74/75] Answer: using the transient plugin

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

diff --git a/doc/todo/calendar_autocreate.mdwn b/doc/todo/calendar_autocreate.mdwn
index b37b3c96b..fc0b5c0c2 100644
--- a/doc/todo/calendar_autocreate.mdwn
+++ b/doc/todo/calendar_autocreate.mdwn
@@ -43,6 +43,11 @@ won't be offended if you correct stuff you consider awkward):
 > > > `$srcdir` hides a page of the same name in an underlay). I thought
 > > > this implementation did the same when not committing? --[[smcv]]
 >
+> > > > I did not realize how easy it was to use the [[plugins/transient]]
+> > > > plugin! I [[took it into
+> > > > account|https://github.com/paternal/ikiwiki/commit/492a22ac75f8b41a427a98c44525b01a6fd181b5]].
+> > > > -- [[Louis|spalax]]
+>
 > I'd personally do the conditional in gencalendaryear more like:
 >
 > [[!format perl """

From b1ccd9c4640b0ba2dd067acd185592592744aea4 Mon Sep 17 00:00:00 2001
From: "http://invalidmagic.wordpress.com/" <invalidmagic@web>
Date: Mon, 7 Jul 2014 08:13:10 -0400
Subject: [PATCH 75/75]

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

diff --git a/doc/css_market.mdwn b/doc/css_market.mdwn
index 4d1b495c6..376f81b8b 100644
--- a/doc/css_market.mdwn
+++ b/doc/css_market.mdwn
@@ -48,6 +48,8 @@ gnomes will convert them to css files..)
   templates.
   [[!meta stylesheet="bma"]]
 
+* ** http://blog.lastlog.de/, contributed by joachim schiele; please feel free to copy.
+
 * **[blankoblues.css][1]**, contributed by [[Blanko]]. Can be seen on [Blankoblues Demo][2]. Local.css and templates available [here][3].
 
 * **[contraste.css][4]**, contributed by [[Blanko]]. Can be seen on [Contraste Demo][5]. Local.css and templates available [here][6].