14 files changed, 474 insertions, 41 deletions
diff --git a/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn b/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn
index e2221bb84..603e82b20 100644
--- a/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn
+++ b/doc/todo/Tags_list_in_page_footer_uses_basename.mdwn
@@ -6,3 +6,6 @@ I think the tag list should always contain the full path to the tag, with the ta
 
 > What if tagbase is not used? I know this would clutter up the display of
 > my tags on several wikis, including this one. --[[Joey]]
+
+>> Since Giuseppe's patches to fix [[bugs/tag_behavior_changes_introduced_by_typed_link_feature]],
+>> the tag list has what Josh requested, but only if a tagbase is used. [[done]] --[[smcv]]
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 16dc78fb2..da0389261 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -260,7 +260,10 @@ required to implement [[todo/alias directive]], which couldn't be easily done
 by writing to the RCS as the page's contents can change depending on which
 other pages claim it as an alias. --[[chrysn]]
 
-I agree with [[chrysn]]. In fact, is there any good reason that the core tag plugin doesn't do this? The current usability is horrible, to the point that I have gone 2.5 years with Ikiwiki and haven't yet started using tags. -- 
+I agree with [[chrysn]]. In fact, is there any good reason that the core tag
+plugin doesn't do this? The current usability is horrible, to the point that
+I have gone 2.5 years with Ikiwiki and haven't yet started using tags.
+--[Eric](http://wiki.pdxhub.org/people/eric)
 
 > See [[todo/transient_pages]] for progress on this. --[[smcv]]
 
diff --git a/doc/todo/autoindex_should_use_add__95__autofile.mdwn b/doc/todo/autoindex_should_use_add__95__autofile.mdwn
index 19c5004f8..908c85cb4 100644
--- a/doc/todo/autoindex_should_use_add__95__autofile.mdwn
+++ b/doc/todo/autoindex_should_use_add__95__autofile.mdwn
@@ -1,4 +1,118 @@
 `add_autofile` is a generic version of [[plugins/autoindex]]'s code,
 so the latter should probably use the former. --[[smcv]]
 
-> See [[todo/transient_pages]] for progress on this. --[[smcv]]
+----
+
+[[!template id=gitbranch branch=smcv/ready/autoindex-autofile author="[[smcv]]"]]
+
+I'm having trouble fixing this:
+
+	# FIXME: some of this is probably redundant with add_autofile now, and
+	# the rest should perhaps be added to the autofile machinery
+
+By "a generic version of" above, it seems I mean "almost, but not
+quite, entirely unlike".
+
+> As long as it's not Tea. ;) --[[Joey]] 
+
+I tried digging through the git history for the
+reasoning behind the autofile and autoindex implementations, but now I'm
+mostly confused.
+
+## autofile
+
+The autofile machinery records a list of every file that has ever been proposed
+as an autofile: for instance, the tag plugin has a list of every tag that
+has ever been named in a \[[!tag]] or \[[!taglink]], even if no file was
+actually needed (e.g. because it already existed). Checks for files that
+already exist (or whatever) are deferred until after this list has been
+updated, and files in this list are never auto-created again unless the wiki
+is rebuilt.
+
+This avoids re-creating the tag `create-del` in this situation, which is
+the third one that I noted on
+[[todo/auto-create tag pages according to a template]]:
+
+* create tags/create-del manually
+* tag a page as create-del
+* delete tags/create-del
+
+and also avoids re-creating `auto-del` in this similar situation (which I
+think is probably the most important one to get right):
+
+* tag a page as auto-del, which is created automatically
+* delete tags/auto-del
+
+I think both of these are desirable.
+
+However, this infrastructure also results in the tag page not being
+re-created in either of these situations (the first and second that I noted
+on the other page):
+
+* tag a page as auto-del-create-del, which is created automatically
+* delete tags/auto-del-create-del
+* create tags/auto-del-create-del manually
+* delete tags/auto-del-create-del again
+
+or
+
+* create tags/create-del-auto
+* delete tags/create-del-auto
+* tag a page as create-del-auto
+
+I'm less sure that these shouldn't create the tag page: we deleted the
+manually-created version, but that doesn't necessarily mean we don't want
+*something* to exist.
+
+> That could be argued, but it's a very DWIM thing. Probably best to keep
+> the behavior simple and predictable, so one only needs to remember that
+> when a page is deleted, nothing will ever re-create it behind ones back.
+> --[[Joey]]
+
+>> Fair enough, I'll make autoindex do that. --s
+
+## autoindex
+
+The autoindex machinery records a more complex set. Items are added to the
+set when they are deleted, but would otherwise have been added as an autoindex
+(don't exist, do have children (by which I mean subpages or attachments),
+and are a directory in the srcdir). They're removed if this particular run
+wouldn't have added them as an autoindex (they exist, or don't have children).
+
+Here's what happens in situations mirroring those above.
+
+The "create-del" case still doesn't create the page:
+
+* create create-del manually
+* create create-del/child
+* delete create-del
+* it's added to `%deleted` and not re-created
+
+Neither does the "auto-del" case:
+
+* create auto-del/child, resulting in auto-del being created automatically
+* delete auto-del
+* it's added to `%deleted` and not re-created
+
+However, unlike the generic autofile infrastructure, `autoindex` forgets
+that it shouldn't re-create the deleted page in the latter two situations:
+
+* create auto-del-create-del/child, resulting in auto-del-create-del being
+    created automatically
+* delete auto-del-create-del; it's added to `%deleted` and not re-created
+* create auto-del-create-del manually; it's removed from `%deleted`
+* delete auto-del-create-del again (it's re-created)
+
+and
+
+* create create-del-auto
+* delete create-del-auto; it's not added to `%deleted` because there's no
+    child that would cause it to exist
+* create create-del-auto/child
+
+> I doubt there is any good reason for this behavior. These are probably
+> bugs. --[[Joey]] 
+
+>> OK, I believe my updated branch gives `autoindex` the same behaviour
+>> as auto-creation of tags. The `auto-del-create-del` and
+>> `create-del-auto` use cases work the same as for tags on my demo wiki. --s
diff --git a/doc/todo/configurable_markdown_path.mdwn b/doc/todo/configurable_markdown_path.mdwn
new file mode 100644
index 000000000..2d67aabac
--- /dev/null
+++ b/doc/todo/configurable_markdown_path.mdwn
@@ -0,0 +1,20 @@
+[[!template id=gitbranch branch=wtk/mdwn author="[[wtk]]"]]
+
+summary
+=======
+
+Make it easy to configure the Markdown implementation used by the
+[[plugins/mdwn]] plugin.  With this patch, you can set the path to an
+external Markdown executable in your ikiwiki config file.  If you do
+not set a path, the plugin will use the usual config options to
+determine which Perl module to use.
+
+> This adds a configuration in which a new process has to be worked
+> for every single page rendered. Actually, it doesn't only add
+> such a configuration, it makes it be done by *default*.
+> 
+> Markdown is ikiwiki's default, standard renderer. A configuration
+> that makes it slow will make ikiwiki look bad.
+> 
+> I would not recommend using Gruber's perl markdown. It is old, terminally
+> buggy, and unmaintained. --[[Joey]] [[!tag reviewed]]
diff --git a/doc/todo/credentials_page.mdwn b/doc/todo/credentials_page.mdwn
new file mode 100644
index 000000000..6b90af144
--- /dev/null
+++ b/doc/todo/credentials_page.mdwn
@@ -0,0 +1,33 @@
+pushing [[this|todo/httpauth feature parity with passwordauth]] and [[this|todo/htpasswd mirror of the userdb]] further (although rather in the [[wishlist]] priority): would it make sense for users to have a `$USER/credentials` page that is by default locked to the user and admins, where the user can state one or more of the below?
+
+* OpenID
+* ssh public key (would require an additional mechanism for writing this to a `authorized_keys` file with appropriate environment variables or prefix that makes sure the commit is checked against the right user and that the user names agree)
+* gpg public key (once there is a mechanism that relies on gpg for authentication))
+* https certificate hash (don't know details; afair the creation of such certificates is typically initiated server-side)
+* password hash (this is generally considered a valuable secret; is this still true with good hashes and proper salting?)
+
+such a page could have a form as described in [[todo/structured page data]] and could even serve as a way of managing users. --[[chrysn]]
+
+> I was just thinking about something along these lines myself. The
+> idea, if I understand correctly, is to allow users to have multiple
+> login options all leading to the same identity. This would allow a
+> user to login for example via either their Google account or their
+> WordPress account, while still being identified as the same user.
+
+> However, I'm not sure this should be a static page (I guess you
+> mean `$USER/credentials`, I don't think ‘creditentials’ actually
+> exists). Something entirely managed at the CGI level is probably
+> better, as it also helps keeping the data in its place (such as ssh
+> public keys in `authorized_keys` etc).
+
+> -- GB
+
+>> having multiple login options leading to the same identity, and (more important to me) giving the user an easy way to review and edit them. i'm thinking a bit of foaf+ssl style "i am $USER and you can recognize me by my client certificate $CERTIFICATE" statements.
+>>
+>> the reason why i want this in a static place instead of cgi level is that it can be used, for example, for automatically creating htpasswd files for read-only (cgi-less) replicas of private wikis. furthermore, it all gets versioned and it can easily be seen where the data really is. the credentials have to be filed appropriately by plugins anyway, but that can happen as a part of the regular rebuild process.
+>>
+>> and yes, you're right about the word misusage; thanks for pointing it out and fixing it.
+>>
+>> --[[chrysn]]
+
+an issue to be considered: for ways of authentication that don't explicitly mention the user name (and that would be everything but password; especially OpenID), there has to be a way to prevent users from hijacking an admin's account. the user wouldn't get more privileges, but the admin could find himself logged in as a user instead of an admin when he logs in using his OpenID, for example. he could fix it by removing the openid from the user's ("his") page, but it has to be taken care of nevertheless. --[[chrysn]]
diff --git a/doc/todo/feed_enhancements_for_inline_pages.mdwn b/doc/todo/feed_enhancements_for_inline_pages.mdwn
new file mode 100644
index 000000000..fde5ac01f
--- /dev/null
+++ b/doc/todo/feed_enhancements_for_inline_pages.mdwn
@@ -0,0 +1,51 @@
+[[!template id=gitbranch branch=GiuseppeBilotta/inlinestuff author="Giuseppe Bilotta"]]
+
+I rearranged my patchset once again, to clearly identify the origin and
+motivation of each patch, which is explained in the following.
+
+In my ikiwiki-based website I have the following situation:
+
+* `$config{usedirs}` is 1
+* there are a number of subdirectories (A/, B/, C/, etc)
+  with pages under each of them (A/page1, A/page2, B/page3, etc)
+* 'index pages' for each subdirectory: A.mdwn, B.mdwn, C.mdwn;
+  these are rather barebone, only contain an inline directive for their
+  respective subpages and become A/index.html, etc
+* there is also the main index.mdwn, which inlines A.mdwn, B.mdwn, C.mdwn,
+  etc (i.e. the top-level index files are also inlined on the homepage)
+
+With the upstream `inline` plugin, the feeds for A, B, C etc are located
+in `A/index.atom`, `B/index.atom`, etc; their title is the wiki name and
+their main link goes to the wiki homepage rather than to their
+respective subdir (e.g. I would expect `A/index.atom` to have a link to
+`http://website/A` but it actually points to `http://website/`).
+
+This is due to them being generated from the main index page, and is
+fixed by the first patch: ‘inline: base feed urls on included page
+name’. As explained in the commit message for the patch itself, this is
+a ‘forgotten part’ from a previous page vs destpage fix which has
+already been included upstream.
+
+The second patch, ‘inline: improve feed title and description
+management’, aligns feed title and description management by introducing
+a `title` option to complement `description`, and by basing the
+description on the page description if the entry is missing. If no
+description is provided by either the directive parameter or the page
+metadata, we use a user-configurable default based on both the page
+title and wiki name rather than hard-coding the wiki name as description.
+
+The third patch, ‘inline: allow assigning an id to postform/feedlink’,
+does just that. I don't currently use it, but it can be particularly
+useful in the postform case for example for scriptable management of
+multiple postforms in the same page.
+
+In one of my wiki setups I had a terminating '/' in `$config{url}`. You
+mention that it should not be present, but I have not seen this
+requirement described anywhere. Rather than restricting the user input,
+I propose a patch that prevents double slashes from appearing in links
+created by `urlto()` by fixing the routine itself.
+
+The inline plugin is also updated (in a separate patch) to use `urlto()`
+rather than hand-coding the feed urls. You might want to keep this
+change even if you discard the urlto patch.
+
diff --git a/doc/todo/generic_insert_links b/doc/todo/generic_insert_links.mdwn
index 050f32ee7..050f32ee7 100644
--- a/doc/todo/generic_insert_links
+++ b/doc/todo/generic_insert_links.mdwn
diff --git a/doc/todo/inline_raw_files.mdwn b/doc/todo/inline_raw_files.mdwn
index 100c07288..ef7fcb12c 100644
--- a/doc/todo/inline_raw_files.mdwn
+++ b/doc/todo/inline_raw_files.mdwn
@@ -1,4 +1,4 @@
-[[!template id=gitbranch branch=wtk/master author="[[wtk]]"]]
+[[!template id=gitbranch branch=wtk/raw_inline author="[[wtk]]"]]
 
 summary
 =======
@@ -59,3 +59,32 @@ usage
 >>
 >> --[[wtk]]
 
+>>> I haven't heard anything in a while, so I've reorganized my version
+>>> history and rebased it on the current ikiwiki head.  Perhaps now it
+>>> will be easier to merge or reject.  Note the new branch name:
+>>> `raw_inline`. I'll open separate todo items for items mentioned in my
+>>> previous comment. --[[wtk]]
+
+---- 
+
+Reviewing your patch the first thing I see is this:
+
+<pre>
++        if (! $file) {
++               error("Missing file.");
++        }
+</pre>
+
+This fails if the filename is "0". Also, `pagetype()`
+currently cannot fail; allowing it to crash the entire
+wiki build if the filename is somehow undefined seems
+unwise.
+
+I didn't look much further, because it seems to me what you're trying to do
+can be better accomplished by using the highlight plugin. Assuming the raw
+file you want to inline and comment on is some source-code-like thing,
+which seems likely.
+
+Or, another way to do it would be to use the templates plugin, and make
+a template there that puts an inline directive inside pre tags.
+ --[[Joey]] [[!tag reviewed]]
diff --git a/doc/todo/latex.mdwn b/doc/todo/latex.mdwn
index 76bb69c9e..5a8bdcad2 100644
--- a/doc/todo/latex.mdwn
+++ b/doc/todo/latex.mdwn
@@ -9,7 +9,7 @@ of the ikiwiki [[/logo]].
 
 > [[users/JasonBlevins]] has also a plugin for including [[LaTeX]] expressions (by means of `itex2MML`) -- [[plugins/mdwn_itex]] (look at his page for the link). --Ivan Z.
 
->> I've [updated](http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/mdwn_itex/) Jason's plugin for ikiwiki 3.x.  --W. Trevor King
+>> I've [[updated|mdwn_itex]] Jason's plugin for ikiwiki 3.x.  --[[wtk]]
 
 ----
 
diff --git a/doc/todo/mdwn_itex.mdwn b/doc/todo/mdwn_itex.mdwn
new file mode 100644
index 000000000..3e304fa76
--- /dev/null
+++ b/doc/todo/mdwn_itex.mdwn
@@ -0,0 +1,22 @@
+[[!template id=gitbranch branch=wtk/mdwn_itex author="[[wtk]]"]]
+
+summary
+=======
+
+Extend the [[plugins/mdwn]] plugin to support [itex][] using Jacques
+Distler's [itex2MML][].
+
+notes
+=====
+
+This is an updated form of [[users/JasonBlevins]]' plugin.  You can
+see the plugin [in action][example] on my blog.  The blog post lists a
+few additional changes you may need to make to use the plugin,
+including changing your page template to a MathML-friendly doctype and
+disabling plugins like [[plugins/htmlscrubber]] and
+[[plugins/htmltidy]] which would otherwise strip out the generated
+MathML.
+
+[itex]: http://golem.ph.utexas.edu/~distler/blog/itex2MMLcommands.html
+[itex2MML]: http://golem.ph.utexas.edu/~distler/blog/itex2MML.html
+[example]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/mdwn_itex/
diff --git a/doc/todo/org_mode.mdwn b/doc/todo/org_mode.mdwn
new file mode 100644
index 000000000..3e9d95376
--- /dev/null
+++ b/doc/todo/org_mode.mdwn
@@ -0,0 +1,24 @@
+[[!template id=gitbranch branch=wtk/org author="[[wtk]]"]]
+
+summary
+=======
+
+Add a plugin for handling files written in [org-mode][].
+
+notes
+=====
+
+This is an updated form of [Manoj Srivastava's plugin][MS].  You can
+see the plugin [in action][example] on my blog.
+
+For reasons discussed in the [[reStructuredText plugin|plugins/rst]],
+wikilinks and other ikiwiki markup that inserts raw HTML can cause
+problems.  Org-mode provides a [means for processing raw HTML][raw],
+but Ikiwiki currently (as far as I know) lacks a method to escape
+inserted HTML depending on which plugins will be used during the
+[[htmlize phase|plugins/write#index11h3]].
+
+[org-mode]: http://orgmode.org/
+[MS]: http://www.golden-gryphon.com/blog/manoj/blog/2008/06/08/Using_org-mode_with_Ikiwiki/
+[example]: http://www.physics.drexel.edu/~wking/unfolding-disasters/posts/Git/notes/
+[raw]: http://orgmode.org/manual/Quoting-HTML-tags.html
diff --git a/doc/todo/support_includes_in_setup_files.mdwn b/doc/todo/support_includes_in_setup_files.mdwn
new file mode 100644
index 000000000..50afb2b6b
--- /dev/null
+++ b/doc/todo/support_includes_in_setup_files.mdwn
@@ -0,0 +1,10 @@
+I have a client server setup so I can I edit/preview on my laptop/desktop and push to a server. I therefore have two almost identical setup files that reasonably often I let get out of sync.  I'd like to be able into include the common parts into the two setup files. Currently the following works, but it relies on knowing the implementation of IkiWiki::Setup::Standard
+
+use IkiWiki::Setup::Standard { specific stuff };
+require "/path/to/common_setup";
+
+where common_setup contains a call to IkiWiki::Setup::merge
+
+To see that this is fragile, note that the require must come second, or ikiwiki will try to load a module called IkiWiki::Setup::merge
+
+DavidBremner
diff --git a/doc/todo/transient_pages.mdwn b/doc/todo/transient_pages.mdwn
index 911f208fd..c08d54228 100644
--- a/doc/todo/transient_pages.mdwn
+++ b/doc/todo/transient_pages.mdwn
@@ -12,8 +12,8 @@ suggests:
 added.
 
 This would also be useful for autoindex, as suggested on
-[[plugins/autoindex/discussion]]. I'd also like to use it for
-[[plugins/contrib/album]].
+[[plugins/autoindex/discussion]] and [[!debbug 544322]]. I'd also like
+to use it for [[plugins/contrib/album]].
 
 It could also be used for an [[todo/alias_directive]].
 
@@ -24,6 +24,18 @@ It could also be used for an [[todo/alias_directive]].
 [[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]]
 [[!tag patch]]
 
+Related branches:
+
+* `ready/tag-test`: an extra regression test for tags
+* either `transient-relative` or `transient-relative-api`: avoid using `Cwd`
+  on initialization
+* `ready/transient-aggregate`: use for aggregate
+* `ready/transient-autoindex`: optionally use for autoindex,
+  which is [[!debbug 544322]] (includes autoindex-autofile from
+  [[todo/autoindex should use add__95__autofile]])
+* `ready/transient-recentchanges`: use for recentchanges
+* `ready/transient-tag`: optionally use for tag (includes tag-test)
+
 I think this branch is now enough to be useful. It adds the following:
 
 If the `transient` plugin is loaded, `$srcdir/.ikiwiki/transient` is added
@@ -31,17 +43,21 @@ as an underlay. I'm not sure whether this should be a plugin or core, so
 I erred on the side of more plugins; I think it's "on the edge of the core",
 like goto.
 
-Pages with the default extension in the transient underlay are automatically
+Pages in the transient underlay are automatically
 deleted if a page of the same name is created in the srcdir (or an underlay
 closer to the srcdir in stacking order).
 
+With the additional `ready/transient-tag` branch,
 `tag` enables `transient`, and if `tag_autocreate_commit` is set to 0
 (default 1), autocreated tags are written to the transient underlay.
 There is a regression test.
 
+With the additional `transient-autoindex` branch,
 `autoindex` uses autofiles. It also enables `transient`, and if
 `autoindex_commit` is set to 0 (default 1), autoindexes are written to
-the transient underlay. There is a regression test.
+the transient underlay. There is a regression test. However, this branch
+is blocked by working out what the desired behaviour is, on
+[[todo/autoindex_should_use_add__95__autofile]].
 
 > I wonder why this needs to be configurable? I suppose that gets back to
 > whether it makes sense to check these files in or not. The benefits of 
@@ -64,15 +80,25 @@ the transient underlay. There is a regression test.
 > commit clutter is really worth it.
 
 >> According to the last section of
->> [[todo/auto-create_tag_pages_according_to_a_template]], chrysn and
+>> [[todo/auto-create_tag_pages_according_to_a_template]], [[chrysn]] and
 >> Eric both feel rather strongly that it should be possible to
->> not commit any tags. I made it configurable because, as you point out,
+>> not commit any tags; in [[plugins/autoindex/discussion]],
+>> lollipopman and [[JoeRayhawk]] both requested the same for autoindex.
+>> I made it configurable because, as you point out,
 >> there are also reasons why it makes sense to check these
 >> automatically-created files in. I'm neutral on this, personally.
 >>
 >> If this is a point of contention, would you accept a branch that
 >> just adds `transient` and uses it for [[plugins/recentchanges]],
->> which aren't checked in and never have been?
+>> which aren't checked in and never have been? I've split the
+>> branch up in the hope that *some* of it can get merged.
+>>
+>>> I will be happy to merge transient-recentchanges when it's ready.
+>>> I see no obstacle to merging transient-tag either, and am not
+>>> really against using it for autoindex or aggregate either
+>>> once they get completed.
+>>> I just wanted to think through why configurability is needed.
+>>> --[[Joey]]
 >>
 >> One potentially relevant point is that configuration clutter only
 >> affects the site admin whereas commit clutter is part of the whole
@@ -80,18 +106,31 @@ the transient underlay. There is a regression test.
 
 > Anyway, the configurability
 > appears subtly broken; the default is only 1 if a new setup file is
-> generated. With an existing setup file, the 'default' values in
+> generated. (Correction: It was not even the default then --[[Joey]])
+> With an existing setup file, the 'default' values in
 > `getsetup` don't take effect, so it will default to undef, which
 > is treated the same as 0. --[[Joey]]
 
->> Fixed in the branch, hopefully. (How disruptive would it be to have
+>> Fixed in the branches, hopefully. (How disruptive would it be to have
 >> defaults take effect whenever the setup file doesn't set a value, btw?
 >> It seems pretty astonishing to have them work as they do at the moment.) --s
 
+>>> Well, note that default is not actually a documented field in
+>>> getsetup hooks at all! (It is used in IkiWiki.pm's own `getsetup()`, and
+>>> the concept may have leaked out into one or two plugins (comments,
+>>> transient)).
+>>> 
+>>> Running getsetup at plugin load time is something I have considered
+>>> doing. It would simplify some checkconfig hooks that just set hardcoded 
+>>> defaults. Although since dying is part of the getsetup hook's API, it
+>>> could be problimaric.
+>>> --[[Joey]]
+
 autoindex ignores pages in the transient underlay when deciding whether
 to generate an index.
 
-New recent changes go in the transient underlay; I tested this manually.
+With the additional `ready/transient-recentchanges` branch, new recent
+changes go in the transient underlay; I tested this manually.
 
 Not done yet (in that branch, at least):
 
@@ -119,54 +158,96 @@ Not done yet (in that branch, at least):
   transient underlay too (they'll naturally migrate over time). I haven't
   tested this yet, it's just a proof-of-concept.
 
+  > Now renamed to `ready/transient-aggregate`; it does seem to work fine.
+  > --s
+
 > I can confirm that the behavior of autoindex, at least, is excellent.
 > Haven't tried tag. Joey, can you merge transient and autoindex? --JoeRayhawk
 
 >> Here are some other things I'd like to think about first: --[[Joey]] 
 >>
 >> * There's a FIXME in autoindex.
-
->>> Right, the extra logic for preventing autoindex pages from being
->>> re-created. I've started on regression tests for this, but I'll
->>> need to rummage through the commit log for the exact requirements
->>> and the reasoning behind them, so it could take a while. --s
+>>
+>>     > Right, the extra logic for preventing autoindex pages from being
+>>     > re-created. This is taking a while, so I'm going to leave out the
+>>     > autoindex part for the moment. The FIXME is only relevant
+>>     > because I tried to solve
+>>     > [[todo/autoindex should use add__95__autofile]] first, but
+>>     > strictly speaking, that's an orthogonal change. --s
 
 >> * Suggest making recentchanges unlink the transient page
 >>   first, and only unlink from the old location if it wasn't
 >>   in the transient location. Ok, it only saves 1 syscall :)
+>>
+>>   > Is an unlink() really that expensive? But, OK, fixed in the
+>>   > `ready/transient-recentchanges` branch. --s
 
->>> Is an unlink() really that expensive? But, OK, fixed in the
->>> updated branch. --s
+>>   >> It's not, but it's easy. :) --[[Joey]]
 
 >> * Similarly it's a bit worrying for performance that it
 >>   needs to pull in and use `Cwd` on every ikiwiki startup now.
 >>   I really don't see the need; `wikistatedir` should
 >>   mostly be absolute, and ikiwiki should not chdir in ways
 >>   that break it anyway.
-
->>> The reason to make it absolute is that relative underlays
->>> are interpreted as relative to the base underlay directory,
->>> not the cwd.
->>>
->>> The updated branch only loads `Cwd` if the path is relative;
->>> an extra commit on branch `smcv/transient-relative` goes
->>> behind `add_underlay`'s back to allow use of a cwd-relative
->>> underlay. Which direction would you prefer? --s
+>>
+>>   > The reason to make it absolute is that relative underlays
+>>   > are interpreted as relative to the base underlay directory,
+>>   > not the cwd, by `add_underlay`.
+>>   >
+>>   > The updated `ready/transient-only` branch only loads `Cwd` if
+>>   > the path is relative; an extra commit on branch
+>>   > `smcv/transient-relative` goes behind `add_underlay`'s
+>>   > back to allow use of a cwd-relative underlay. Which direction
+>>   > would you prefer?
+>>   >
+>>   > I note in passing that [[plugins/autoindex]] and `IkiWiki::Render`
+>>   > both need to use `Cwd` and `File::Find` on every refresh, so
+>>   > there's only any point in avoiding `Cwd` for runs that don't
+>>   > actually refresh, like simple uses of the CGI. --s
+
+>>   >> Oh, right, I'd forgotten about the horrificness of File::Find
+>>   >> that required a chdir for security. Ugh. Can we just avoid
+>>   >> it for those simple cases then? (demand-calculate wikistatedir)
+>>   >> --[[Joey]] 
+
+>>   >>> The reason that transientdir needs to be absolute is that it's
+>>   >>> added as an underlay.
+>>   >>>
+>>   >>> We could avoid using `Cwd` by taking the extra commit from either
+>>   >>> `smcv/transient-relative` or `smcv/transient-relative-api`;
+>>   >>> your choice. I'd personally go for the latter.
+>>   >>>
+>>   >>> According to git grep, [[plugins/po]] already wants to look at
+>>   >>> the underlaydirs in its checkconfig hook, so I don't think
+>>   >>> delaying calculation of the underlaydir is viable. (I also noticed
+>>   >>> a bug,
+>>   >>> [[bugs/po:_might_not_add_translated_versions_of_all_underlays]].)
+>>   >>>
+>>   >>> `underlaydirs` certainly needs to have been calculated by the
+>>   >>> time `refresh` hooks finish, so `find_src_files` can use it. --s
 
 >> * Unsure about the use of `default_pageext` in the `change`
 >>   hook. Is everything in the transientdir really going
 >>   to use that pageext? Would it be better to look up the
 >>   complete source filename?
-
->>> At the moment everything in the transientdir will either
->>> have the `default_pageext` or be internal, although I
->>> did wonder whether to make [[plugins/contrib/album]]
->>> viewer pages optionally be `html`, for better performance
->>> when there's a very large number of photos.
->>>
->>> A more thorough garbage-collection mechanism would be to
->>> use File::Find on the transient directory; I'll get there
->>> eventually. --s
+>>
+>>   > I've updated `ready/transient` to do a more thorough GC by
+>>   > using File::Find on the transient directory. This does
+>>   > require `File::Find` and `Cwd`, but only when pages change,
+>>   > and `refresh` loads both of those in that situation anyway.
+>>   >
+>>   > At the moment everything in the transientdir will either
+>>   > have the `default_pageext` or be internal, although I
+>>   > did wonder whether to make [[plugins/contrib/album]]
+>>   > viewer pages optionally be `html`, for better performance
+>>   > when there's a very large number of photos. --s
+
+>>   >> Oh, ugh, more File::Find... Couldn't it just assume that the
+>>   >> transient page has the same extension as its replacement?
+>>   >> --[[Joey]]
+
+>>   >>> Good idea, that'll be true for web edits at least.
+>>   >>> Commit added. --s
 
 --------------------------
 
diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
index b069ee2bd..6ede7f91e 100644
--- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
+++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn
@@ -1,3 +1,46 @@
+## current status
+
+[[done]] again! :)
+
+Actually, there are two places where the configured url is still hardcoded:
+
+1. When searching, all the links will use it. This is annoying to fix,
+   and we deem it not a problem.
+2. When ikiwiki dies with an error, the links on the error page will
+   use it. Too bad :)
+
+------
+
+## semi-old
+
+
+* CGI pages, with the exception of edit pages, set `<base>` to
+  `$config{url}`
+
+  I had to revert using `baseurl(undef)` for that, because it needs
+  to be a full url.
+
+  Ideally, baseurl would return an absolute url derived from the url
+  being used to access the cgi, but that needs access to the CGI object,
+  which it does not currently have. Similarly, `misctemplate`
+  does not have access to the CGI object, so it cannot use it to
+  generate a better baseurl. Not sure yet what to do; may have to thread
+  a cgi parameter through all the calls to misctemplate. --[[Joey]]
+
+  > Fixed, cgitemplate is used now. --[[Joey]] 
+
+* Using `do=goto` to go to a comment or recentchanges item
+  will redirect to the `$config{url}`-based url, since the
+  permalinks are made to be absolute urls now.
+
+  Fixing this would seem to involve making meta force permalinks
+  to absolute urls when fulling out templates, while allowing them
+  to be left as partial urls internally, for use by goto. --[[Joey]]
+
+  > This reversion has now been fixed. --[[Joey]]
+
+## old attempt
+
 It looks like all links in websites are absolute paths, this has some limitations:
 
 * If connecting to website via https://... all links will take you back to http://
@@ -320,7 +363,7 @@ Potential future things:
   >> and 5 in plugins, since I used it for things like redirection back
   >> to the top of the wiki --[[smcv]]
 
-[[merged|done]] --[[Joey]] 
+merged|done --[[Joey]] (But reopened, see above.)
 
 ----