10 files changed, 224 insertions, 12 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/autoindex_should_use_add__95__autofile.mdwn b/doc/todo/autoindex_should_use_add__95__autofile.mdwn
index 9f3fd71f1..908c85cb4 100644
--- a/doc/todo/autoindex_should_use_add__95__autofile.mdwn
+++ b/doc/todo/autoindex_should_use_add__95__autofile.mdwn
@@ -3,7 +3,7 @@ so the latter should probably use the former. --[[smcv]]
 
 ----
 
-[[!template id=gitbranch branch=smcv/autoindex-autofile author="[[smcv]]"]]
+[[!template id=gitbranch branch=smcv/ready/autoindex-autofile author="[[smcv]]"]]
 
 I'm having trouble fixing this:
 
@@ -69,6 +69,8 @@ manually-created version, but that doesn't necessarily mean we don't want
 > 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
@@ -110,3 +112,7 @@ and
 
 > 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
index 5a7b1f839..fde5ac01f 100644
--- a/doc/todo/feed_enhancements_for_inline_pages.mdwn
+++ b/doc/todo/feed_enhancements_for_inline_pages.mdwn
@@ -1,8 +1,51 @@
 [[!template id=gitbranch branch=GiuseppeBilotta/inlinestuff author="Giuseppe Bilotta"]]
 
-A few patches to clean up and improve feed management for inline pages.
+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.
 
-* the first patch simply replaces the id attribute in the default template for feedlinks with a class attribute by the same name. This is necessary in pages with multiple inlines to guarantee correctness
-* the second patch tries to define the default description for a feed based not only on the wiki name, but also on the current page name. The actual way this is built might not be the optimal one, so I'm open to suggestions
-* the third patch passes the feed titles to the templates, changing the default templates to use these as title attributes for the links. a rel="alternate" attribute is also included
-* the fourth patch introduces a feedlinks parameter to the inline directive, to allow for the specifications of the locations where the feed links should appear. Currently, two options are allowed (head and body), plus both and none with obvious significance
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/transient_pages.mdwn b/doc/todo/transient_pages.mdwn
index 1a35dddb1..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]].
 
@@ -22,10 +22,20 @@ It could also be used for an [[todo/alias_directive]].
 --------------------------
 
 [[!template id=gitbranch branch=smcv/ready/transient author="[[smcv]]"]]
-[[!template id=gitbranch branch=smcv/ready/transient-recentchanges author="[[smcv]]"]]
-[[!template id=gitbranch branch=smcv/ready/transient-tag 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
@@ -148,6 +158,9 @@ 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
 
@@ -197,6 +210,22 @@ Not done yet (in that branch, at least):
 >>   >> 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
@@ -217,6 +246,9 @@ Not done yet (in that branch, at least):
 >>   >> transient page has the same extension as its replacement?
 >>   >> --[[Joey]]
 
+>>   >>> Good idea, that'll be true for web edits at least.
+>>   >>> Commit added. --s
+
 --------------------------
 
 ## An earlier version