18 files changed, 216 insertions, 35 deletions
diff --git a/doc/todo/Commit_emails:_ones_own_changes.mdwn b/doc/todo/Commit_emails:_ones_own_changes.mdwn
index d577c454f..862a85071 100644
--- a/doc/todo/Commit_emails:_ones_own_changes.mdwn
+++ b/doc/todo/Commit_emails:_ones_own_changes.mdwn
@@ -4,3 +4,6 @@ What's the rationale behind excluding ones own changes from the commit emails se
 > Well, commit mails are intended to keep you informed of changes in the
 > wiki, and I assumed you'd know about changes you made yourself.
 > --[[Joey]]
+
+> [[done]] -- commit mails removed; recentchanges feeds can be configured
+> for whatever you like.
diff --git a/doc/todo/Inline_plugin_option_to_show_full_page_path.mdwn b/doc/todo/Inline_plugin_option_to_show_full_page_path.mdwn
index ab9cd61e4..30490e9d3 100644
--- a/doc/todo/Inline_plugin_option_to_show_full_page_path.mdwn
+++ b/doc/todo/Inline_plugin_option_to_show_full_page_path.mdwn
@@ -15,14 +15,14 @@ Cheers,
 > that contains the full page name. Then you just use a modified
 > `inlinepage.tmpl`, that uses that instead of the title. --[[Joey]]
 
-diff --git a/IkiWiki/Plugin/inline.pm b/IkiWiki/Plugin/inline.pm
-index 59eabb6..82913ba 100644
---- a/IkiWiki/Plugin/inline.pm
-+++ b/IkiWiki/Plugin/inline.pm
-@@ -229,6 +229,7 @@ sub preprocess_inline (@) { #{{{
- 					$template->param(content => $content);
- 				}
- 				$template->param(pageurl => urlto(bestlink($params{page}, $page), $params{destpage}));
-+				$template->param(page => $page);
- 				$template->param(title => pagetitle(basename($page)));
- 				$template->param(ctime => displaytime($pagectime{$page}, $params{timeformat}));
+	diff --git a/IkiWiki/Plugin/inline.pm b/IkiWiki/Plugin/inline.pm
+	index 59eabb6..82913ba 100644
+	--- a/IkiWiki/Plugin/inline.pm
+	+++ b/IkiWiki/Plugin/inline.pm
+	@@ -229,6 +229,7 @@ sub preprocess_inline (@) { #{{{
+	 					$template->param(content => $content);
+	 				}
+	 				$template->param(pageurl => urlto(bestlink($params{page}, $page), $params{destpage}));
+	+				$template->param(page => $page);
+	 				$template->param(title => pagetitle(basename($page)));
+	 				$template->param(ctime => displaytime($pagectime{$page}, $params{timeformat}));
diff --git a/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn b/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn
index 70970c6cc..dc456bbbf 100644
--- a/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn
+++ b/doc/todo/__34__subscribe_to_this_page__34___checkbox_on_edit_form.mdwn
@@ -3,4 +3,8 @@ user to add a page to their subscribed list while editing.  This would prove
 particularly useful for [[todo]] and [bug](bugs) items, to allow users to receive
 notifications for activity on their reports.
 
---[[JoshTriplett]]
-\ No newline at end of file
+--[[JoshTriplett]]
+
+I went and removed commit notification mails entirely, the idea is that you
+subscribe using the [[RecentChanges]] rss feed, and filter it on your end.
+Good enough? --[[Joey]]
diff --git a/doc/todo/aggregate_locking.mdwn b/doc/todo/aggregate_locking.mdwn
new file mode 100644
index 000000000..b6c82e923
--- /dev/null
+++ b/doc/todo/aggregate_locking.mdwn
@@ -0,0 +1,64 @@
+The [[plugin/aggregate]] plugin's locking is a suboptimal.
+
+There should be no need to lock the wiki while aggregating -- it's annoying
+that long aggregate runs can block edits from happening. However, not
+locking would present problems. One is, if an aggregate run is happening,
+and the feed is removed, it could continue adding pages for that feed.
+Those pages would then become orphaned, and stick around, since the feed
+that had created them is gone, and thus there's no indication that they
+should be removed.
+
+To fix that, garbage collect any pages that were created by
+aggregation once their feed is gone.
+
+Are there other things that could happen while it's aggregating that it
+should check for?
+
+Well, things like the feed url etc could change, and it
+would have to merge in such changes before saving the aggregation state.
+New feeds could also be added, feeds could be moved from one source page to
+another.
+
+Merging that feed info seems doable, just re-load the aggregation state
+from disk, and set the `message`, `lastupdate`, `numposts`, and `error`
+fields to their new values if the feed still exists.
+
+----
+
+Another part of the mess is that it needs to avoid stacking multiple
+aggregate processes up if aggregation is very slow. Currently this is done
+by taking the lock in nonblocking mode, and not aggregating if it's locked.
+This has various problems, for example a page edit at the right time can
+prevent aggregation from happening.
+
+Adding another lock just for aggregation could solve this. Check that lock
+(in checkconfig) and exit if another aggregator holds it.
+
+----
+
+The other part of the mess is that it currently does aggregation in
+checkconfig, locking the wiki for that, and loading state, and then
+dropping the lock, unloading state, and letting the render happen. Which
+reloads state. That state reloading is tricky to do just right.
+
+A simple fix: Move the aggregation to the new 'render' hook. Then state
+would be loaded, and there would be no reason to worry about aggregating.
+
+Or aggregation could be kept in checkconfig, like so:
+
+* load aggregation state
+* get list of feeds needing aggregation
+* exit if none
+* attempt to take aggregation lock, exit if another aggregation is happening
+* fork a child process to do the aggregation
+  * load wiki state (needed for aggregation to run)
+  * aggregate
+  * lock wiki
+  * reload aggregation state
+  * merge in aggregation state changes
+  * unlock wiki
+* drop aggregation lock
+* force rebuild of sourcepages of feeds that were aggregated
+* exit checkconfig and continue with usual refresh process
+
+[[done]]
diff --git a/doc/todo/aggregate_to_internal_pages.mdwn b/doc/todo/aggregate_to_internal_pages.mdwn
new file mode 100644
index 000000000..a4164fa25
--- /dev/null
+++ b/doc/todo/aggregate_to_internal_pages.mdwn
@@ -0,0 +1,5 @@
+The new internal page feature is designed for something like
+[[plugins/aggregate]].
+
+How to transition to it though? inlines of aggregated content would need to
+change their pagespecs to use `internal()`.
diff --git a/doc/todo/allow_wiki_syntax_in_commit_messages.mdwn b/doc/todo/allow_wiki_syntax_in_commit_messages.mdwn
index 01c5d397b..97691bdc3 100644
--- a/doc/todo/allow_wiki_syntax_in_commit_messages.mdwn
+++ b/doc/todo/allow_wiki_syntax_in_commit_messages.mdwn
@@ -9,4 +9,13 @@ a whole page into RecentChanges. Of course, it could only use _one_ of the
 available markups, ie the default markdown. --[[Joey]]
 
 To go along with this, the preview should show the formatted commit message.
---[[JoshTriplett]]
-\ No newline at end of file
+--[[JoshTriplett]]
+
+This is really easy to do now, but it would have to be limited to applying
+markdown formatting (or whatever formatter is default I suppose) to the
+content, and *not* to expanding any WikiLinks or preprocessor directives.
+Especially with the new static RecentChanges, expanding even wikilinks
+would be pretty tricky to do. Applying markdown formatting seems like a
+reasonable thing; it would make commit messages that have the form of a
+bulletted list be marked up nicely, and would also handle _emphasised_
+words etc, and even http links. --[[Joey]]
diff --git a/doc/todo/bzr.mdwn b/doc/todo/bzr.mdwn
index dbe35245c..179ea2f24 100644
--- a/doc/todo/bzr.mdwn
+++ b/doc/todo/bzr.mdwn
@@ -4,6 +4,8 @@ rcs_commit was only changed to work around bzr's lack of a switch to set the
 username). bzr_log could probably be written better by someone better at perl,
 and rcs_getctime and rcs_notify aren't written at all. --[[bma]]
 
+(rcs_notify is not needed in this branch --[[Joey]])
+
     #!/usr/bin/perl
     
     use warnings;
@@ -183,4 +185,10 @@ and rcs_getctime and rcs_notify aren't written at all. --[[bma]]
 
 >>> It's new (in fact I'm not even sure that it made it in to 0.90, it might be in 0.91 due
 >>> in a couple of weeks.
->>> I was just noting it for a future enhancement. --[[JamesWestby]]
-\ No newline at end of file
+>>> I was just noting it for a future enhancement. --[[JamesWestby]]
+
+> I've just posted another patch with support for bzr, including support for 
+> --author and a testsuite to git://git.samba.org/jelmer/ikiwiki.git. I hadn't 
+> seen this page earlier.  --[[jelmer]]
+
+> I used jelmer's patch --[[done]]! --[[Joey]]
diff --git a/doc/todo/ctime_on_blog_post_pages_.mdwn b/doc/todo/ctime_on_blog_post_pages_.mdwn
new file mode 100644
index 000000000..4fd099d9d
--- /dev/null
+++ b/doc/todo/ctime_on_blog_post_pages_.mdwn
@@ -0,0 +1,5 @@
+[[Blog|ikiwiki/blog]] feeds and index pages show the posted time (ctime), the actual blog entry pages only show the modified time.
+
+The user has to look at the history link to find when a blog item was posted.
+
+It would be nice if blog entry post pages could include the ctime. -- [[Edward_Betts]]
diff --git a/doc/todo/doxygen_support.mdwn b/doc/todo/doxygen_support.mdwn
new file mode 100644
index 000000000..ae31c1603
--- /dev/null
+++ b/doc/todo/doxygen_support.mdwn
@@ -0,0 +1,7 @@
+[[tag wishlist]]
+
+Given that ikiwiki has a suggested use as a tool for developers, I was thinking it might be cool if ikiwiki had [Doxygen](http://www.doxygen.org/) support.  I'm not exactly sure how the integration would work.  Something along the lines of a plugin to support .dox files would be my first thought.  I'd leave generating the documentation from any source files for a separate run of Doxygen - it'd be easier and you probably don't want the source being edited over the web.
+
+#### Background ####
+
+I have been involved with one project that uses Doxygen to generate their web pages and user docs, as well as their 'in code' documentation: <http://orca-robotics.sourceforge.net/orca/index.html>.  This makes the whole system somewhat like ikiwiki, but without the cgi for public editing.  I was thinking of trying to convince that project to move to ikiwiki, but they're not going to want to re-write all their documentation.
diff --git a/doc/todo/httpauth_example.mdwn b/doc/todo/httpauth_example.mdwn
index f67f67371..0c6268aa1 100644
--- a/doc/todo/httpauth_example.mdwn
+++ b/doc/todo/httpauth_example.mdwn
@@ -3,3 +3,6 @@ authentication (perhaps as a [[tip|tips]]), showing how to authenticate the
 user for edits without requiring authentication for the entire wiki. (Ideally,
 recentchanges should work without authentication as well, even though it goes
 through the CGI.) --[[JoshTriplett]]
+
+> (Now that recentchanges is a static page, it auths the same as other wiki
+> pages.) --[[Joey]]
diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn
index e5de93521..608c7d681 100644
--- a/doc/todo/mercurial.mdwn
+++ b/doc/todo/mercurial.mdwn
@@ -1,6 +1,6 @@
 * Need to get post commit hook working (or an example of how to use it.)
   * See below. --[[bma]]
-* rcs_notify is not implemented
+* rcs_notify is not implemented (not needed in this branch --[[Joey]])
 * Is the code sufficiently robust? It just warns when mercurial fails.
 * When rcs_commit is called with a $user that is an openid, it will be
   passed through to mercurial -u. Will mercurial choke on this?
diff --git a/doc/todo/mtime.mdwn b/doc/todo/mtime.mdwn
new file mode 100644
index 000000000..92cbe84ff
--- /dev/null
+++ b/doc/todo/mtime.mdwn
@@ -0,0 +1,14 @@
+It'd be nice if the mtime of the files ikiwiki renders matched the mtime of
+the source files.
+
+However, this turns out to be more complex than just calling utime() a few
+times. If a page inlines other, younger pages, then having an older mtime
+means that an old version of it will be kept in web caches, forcing
+annoying shift-reloads to see the changed content (for example).
+
+And it's not just inline. The template plugin means that a change to a
+template can result in changes to how a page gets rendered. The version
+plugin changes page content without any younger page being involved. And
+editing one of the html templates and rebuilding the wiki can change every
+page. All of these need to be reflected in the file mtime to avoid caching
+problems.
diff --git a/doc/todo/multiple_output_formats.mdwn b/doc/todo/multiple_output_formats.mdwn
index 76fd39303..00623be39 100644
--- a/doc/todo/multiple_output_formats.mdwn
+++ b/doc/todo/multiple_output_formats.mdwn
@@ -5,4 +5,13 @@ This would provide true "printable versions" of the wiki pages supporting it.
 
 --[[JeremieKoenig]]
 
+Could this be done by making the output format a plugin, similar to the way
+pyblosxom works? Atom and RSS could then possibly be moved into plugins.
+
+Presumably they'd have to work by converting HTML into some other format, as
+trying to force all input languages to generate more than one output language
+would be impractical to say the least.
+
+--[[bma]]
+
 [[tag wishlist]]
diff --git a/doc/todo/multiple_templates.mdwn b/doc/todo/multiple_templates.mdwn
index 361270bb9..d165eebaf 100644
--- a/doc/todo/multiple_templates.mdwn
+++ b/doc/todo/multiple_templates.mdwn
@@ -1,11 +1,11 @@
-> Another useful feature might be to be able to choose a different template
-> file for some pages; blog pages would use a template different from the
+> Another useful feature might be to be able to choose a different [[template|wikitemplates]]
+> file for some pages; [[blog|ikiwiki/blog]] pages would use a template different from the
 > home page, even if both are managed in the same repository, etc.
 
-Well, that would probably be fairly easy to add if it used pagespecs to
+Well, that would probably be fairly easy to add if it used [[pagespecs|ikiwiki/pagespec]] to
 specify which pages use the non-default template.
 
-Hmm, I think the pagetemplate hook should allow one to get close enough to
+Hmm, I think the [[pagetemplate|plugins/pagetemplate]] hook should allow one to get close enough to
 this in a plugin now.
 
 See also: [[Allow_per-page_template_selection]] -- same thing, really.
diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn
index 4714a7a09..4bbda6565 100644
--- a/doc/todo/passwordauth:_sendmail_interface.mdwn
+++ b/doc/todo/passwordauth:_sendmail_interface.mdwn
@@ -44,7 +44,6 @@ Remaining TODOs:
     just for this bit of functionality?
   * Debian news file.
   * ikiwiki news file.
-  * Are commit emails still working?
 
 --[[tschwinge]]
 
diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn
index 0d702975f..89dbb04a2 100644
--- a/doc/todo/plugin.mdwn
+++ b/doc/todo/plugin.mdwn
@@ -6,20 +6,6 @@ Suggestions of ideas for plugins:
 > web-server-specific code to list all users, and openid can't feasibly do so
 > at all. --[[JoshTriplett]]
 
-* Support [[RecentChanges]] as a regular page containing a plugin that
-  updates each time there is a change, and statically builds the recent
-  changes list. (Would this be too expensive/inflexible? There might be
-  other ways to do it as a plugin, like making all links to RecentChanges
-  link to the cgi and have the cgi render it on demand.) 
-
-  Or using an iframe
-  to inline the cgi, although firefox seems to render that nastily with
-  nested scroll bars. :-(
-> Or just link to the equivalent in the version control system, if available;
-> gitweb's shortlog or summary view would work nicely as a
-> RecentChanges. --[[JoshTriplett]]
->>Why not fork the process?  We wouldn't have to wait around for a response since we would assume the recent changes page was being generated correctly.
-
 * It would be nice to be able to have a button to show "Differences" (or 
   "Show Diff") when editing a page. Is that an option that can be enabled?
   Using a plugin?
@@ -58,4 +44,4 @@ Suggestions of ideas for plugins:
 
 * As I couldn't find another place to ask, I'll try here. I would like to install some contributed plugins, but can not find anywhere to downlod them.
 
-  > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]]
-\ No newline at end of file
+  > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]]
diff --git a/doc/todo/recentchanges.mdwn b/doc/todo/recentchanges.mdwn
index d46c0d9a8..91128a860 100644
--- a/doc/todo/recentchanges.mdwn
+++ b/doc/todo/recentchanges.mdwn
@@ -86,3 +86,59 @@ your pages. --Ethan
 > backend.
 >
 > -- CharlesMauch
+
+---- 
+
+Here's a full design for redoing recentchanges, based on Ethan's ideas:
+
+* Add a recentchanges plugin that has a preprocessor directive:
+	\[[recentchanges num=100 pages=* template=recentchanges.tmpl]]
+  If put on the [[recentchanges]] page, this would result in up to 100
+  recentchanges/change_$id.mdwn files being created.
+* Which means the plugin has to store state and use a checkconfig hook
+  or the like to create the requested pages (and delete old ones) when
+  the wiki is rebuilt and when the post_commit hook is run.
+* Then it's a simple matter of using inline on the recentchanges page
+  to display the changes. (With a special template to display nicely.)
+* Rss/atom comes for free..
+* So drop mail notifications.
+* If someone wants to subscribe to notifications for only a subset
+  of pages, they can either filter the recentchanges in their rss
+  aggregator, or they can set up their own page that uses the recentchanges
+  directive for only the pages they want.
+* The `rcs_notify` functions will be removed.
+* To add diffs, another plugin can add a pagetemplate hook that calls
+  a `rcs_diff`. (optional)
+* So to update the changes files, just call `rcs_recentchanges`, create
+  files for each new id, and delete files for each id that is no longer
+  included.
+* The cgi support for recentchanges can be dropped, or moved to a different
+  plugin.
+
+I'm unsure how fast this will all be, but by using regular pages, there's
+cacheing, at least. The main slowdown might turn out to be the inlining and
+not the generation of the changes pages. The current cgi recentchanges
+code saves a tenth of a second or so by memoizing htmllink, an optimisation
+that won't be available when using the more general inlining code.
+
+An obvious optimisation, and one implied by this design, is that each change
+file is only written once. This assumes that the data in them doesn't ever
+change, which actually isn't true (svn commit messages can be changed), but
+is probably close enough to true for our purposes.
+
+Another optimisation would be to htmlize the change files when they're
+written out -- avoids re-rendering a given file each time a new change is
+made (thus doing 1/100th the work). 
+
+Links in the change files to the changed pages will need special handling.
+These links should not generate backlinks. They probably shouldn't be
+implemented as wikiliks at all. Instead, they should be raw, absolute 
+html links to the pages that were changed.
+
+Only problem with this approach is that the links break if the changed
+page later gets deleted. I think that's acceptable. It could link to
+`ikiwiki.cgi?do=redir&page=foo`, but that's probably overkill.
+
+--[[Joey]]
+
+[[done]] !! (in this branch at least :-)
diff --git a/doc/todo/unaccent_url_instead_of_encoding.mdwn b/doc/todo/unaccent_url_instead_of_encoding.mdwn
new file mode 100644
index 000000000..fbba893c5
--- /dev/null
+++ b/doc/todo/unaccent_url_instead_of_encoding.mdwn
@@ -0,0 +1,9 @@
+If one puts localized chars in wikilinks ikiwiki will escape it.
+This works right from a technical point of view, but the URLs will become ugly.
+
+So I made a patch which unaccent chars: <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/unaccentpagetitlenames/>
+This is a one liner change, but requires a bit of reordering in the code.
+
+[[cstamas]]
+
+[[tag wishlist patch]]