17 files changed, 208 insertions, 73 deletions
diff --git a/doc/bugs/HTML_inlined_into_Atom_not_necessarily_well-formed.mdwn b/doc/bugs/HTML_inlined_into_Atom_not_necessarily_well-formed.mdwn
new file mode 100644
index 000000000..d2f8ca3dc
--- /dev/null
+++ b/doc/bugs/HTML_inlined_into_Atom_not_necessarily_well-formed.mdwn
@@ -0,0 +1,35 @@
+If a blog entry contains a HTML named entity, such as the `&mdash;` produced by [[plugins/rst]] for blockquote citations, it's pasted into the Atom feed as-is. However, Atom feeds don't have a DTD, so named entities beyond `&lt;`, `&gt;`, `&quot;`, `&amp;` and `&apos;` aren't well-formed XML.
+
+Possible solutions:
+
+* Put HTML in Atom feeds as type="html" (and use ESCAPE=HTML) instead
+
+> Are there any particular downsides to doing that ..? --[[Joey]]
+
+>> It's the usual XHTML/HTML distinction. type="html" will always be interpreted as "tag soup", I believe - this may lead to it being rendered differently in some browsers. In general ikiwiki seems to claim to produce XHTML (at least, the default page.tmpl makes it claim to be XHTML Strict). On the other hand, this is a much simpler solution... see escape-feed-html branch in my repository, which I'm now using instead --[[smcv]]
+
+>>> Of course, browsers [probably don't treat xhtml pages as xhtml anyway](http://hixie.ch/advocacy/xhtml).
+>>> And the same content will be treated as html (probably as tag soup) if it's
+>>> in a rss feed.
+
+>>> [[merged|done]]
+
+* Keep HTML in Atom feeds as type="xhtml", but replace named entities with numeric ones,
+  like in the re-escape-entities branch in my repository ([diff here](http://git.debian.org/?p=users/smcv/ikiwiki.git;a=commitdiff;h=c0eb041c65d0653bacf0d4acb7a602e9bda8888e))
+
+>> I can see why you think this is excessively complex! --[[smcv]]
+
+(Also, the HTML in RSS feeds would probably get better interoperability if it was escaped with ESCAPE=HTML rather than being in a CDATA section?)
+
+> Can't see why? --[[Joey]]
+
+>> For a start, `]]>` in content wouldn't break the feed :-) but I was really thinking of non-XML, non-SGML parsers (more tag soup) that don't understand CDATA (I've suffered from CDATA damage when feeding generated code through gtkdoc, for instance). --[[smcv]]
+
+>>> FWIW, the htmlscrubber escapes the `]]>`. (Wouldn't hurt to make that
+>>> more robust tho.)
+>>> 
+>>> ikiwiki has used CDATA from the beginning -- this is the first time
+>>> I've heard about rss 2.0 parsers that didn't know about CDATA.
+>>>
+>>> (IIRC, I used CDATA because the result is more space-efficient and less
+>>> craptacular to read manually.)
diff --git a/doc/bugs/Obsolete_templates__47__estseek.conf.mdwn b/doc/bugs/Obsolete_templates__47__estseek.conf.mdwn
new file mode 100644
index 000000000..99330a115
--- /dev/null
+++ b/doc/bugs/Obsolete_templates__47__estseek.conf.mdwn
@@ -0,0 +1,3 @@
+The templates/estseek.conf file can safely be removed now that ikiwiki has switched to using xapian-omega.
+
+> Thanks for the reminder, [[done]] --[[Joey]]
diff --git a/doc/bugs/HTML-escaped_titles_in_Atom__44___RSS_feeds_don__39__t_validate.mdwn b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn
index 48c168997..48c168997 100644
--- a/doc/bugs/HTML-escaped_titles_in_Atom__44___RSS_feeds_don__39__t_validate.mdwn
+++ b/doc/bugs/rss_feeds_do_not_use_recommended_encoding_of_entities_for_some_fields.mdwn
diff --git a/doc/news/version_2.51.mdwn b/doc/news/version_2.51.mdwn
deleted file mode 100644
index 87d742ba4..000000000
--- a/doc/news/version_2.51.mdwn
+++ /dev/null
@@ -1,33 +0,0 @@
-ikiwiki 2.51 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * Improve toplevel parentlink to link directly to index.html when usedirs is
-     disabled.
-   * map: Add a "show" parameter. "show=title" can be used to display page
-     titles, rather than the default page name. Based on a patch from
-     Jaldhar H. Vyas, Closes: #[484510](http://bugs.debian.org/484510)
-   * hnb: New plugin, contributed by Axel Beckert.
-   * meta: Store "description" in pagestate for use by other plugins.
-   * map: Support show=description.
-   * textile: The Text::Textile perl module has some regexps that fail if
-     input is flagged as utf-8, but contains invalid characters such as 0x92.
-     To prevent it from crashing, re-encode the content before calling it,
-     which will ensure that it's really utf-8.
-   * Version the suggests of xapian-omega to a version known to be new enough
-     to work with ikiwiki. Reportedly, version 0.9.9 is too old to work.
-     Closes: #[486592](http://bugs.debian.org/486592)
-   * creole: New plugin from Bernd Zeimetz. Closes: #[486930](http://bugs.debian.org/486930)
-   * aggregate: Add template parameter.
-   * Add support for the universal edit button &lt;http://universaleditbutton.org/&gt;
-     (To get this on all pages of an exiting wiki, rebuild the wiki.)
-   * txt: New plugin, contributed by Gabriel McManus.
-   * smiley: Generate links relative to the destpage. (Fixes a reversion from
-     2.41.)
-   * toc: Revert change in 2.45 that made it run at sanitize time. That broke
-     use of toc in a sidebar.
-   * Call format hooks when generating page previews, thus fixing toc display
-     there, as well as fixing inlins to again display in page previews, since
-     it's started using format hooks. This also allows several other things,
-     like embed, that use format hooks, to work during page preview time.
-   * Format hooks should not rely on getting an entire html document, as they
-     will only get the body during page preview.
-   * toggle: Deal with preview mode when adding javascript."""]]
-\ No newline at end of file
diff --git a/doc/news/version_2.56.mdwn b/doc/news/version_2.56.mdwn
new file mode 100644
index 000000000..b8c069488
--- /dev/null
+++ b/doc/news/version_2.56.mdwn
@@ -0,0 +1,10 @@
+ikiwiki 2.56 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * autoindex: New plugin that generates missing index pages.
+     (Sponsored by The TOVA Company.)
+   * Escape HTML is rss and atom feeds instead of respectively using CDATA and
+     treating it as XHTML. This avoids problems with escaping the end of the
+     CDATA when the htmlscrubber is not used, and it avoids problems with atom
+     XHTML using named entity references that are not in the atom DTD. (Simon McVittie)
+   * Add test for old versions of git that don't support --cleanup=verbatim,
+     and munge empty commit messages."""]]
+\ No newline at end of file
diff --git a/doc/plugins/autoindex.mdwn b/doc/plugins/autoindex.mdwn
index 66e0163c2..03e2d12f3 100644
--- a/doc/plugins/autoindex.mdwn
+++ b/doc/plugins/autoindex.mdwn
@@ -2,6 +2,6 @@
 [[!tag type/useful]]
 
 This plugin searches for [[SubPages|ikiwiki/subpage]] with a missing parent
-page, and generates a parent page for them. The generated page content is
-controlled by the autoindex [[template|wikitemplates]], which by default,
-uses a [[map]] to list the SubPages.
+page, and generates the parent pages. The generated page content is
+controlled by the `autoindex.tmpl` [[template|wikitemplates]], which by
+default, uses a [[map]] to list the SubPages.
diff --git a/doc/plugins/contrib/unixauth.mdwn b/doc/plugins/contrib/unixauth.mdwn
index 12f885c33..2de6fc51f 100644
--- a/doc/plugins/contrib/unixauth.mdwn
+++ b/doc/plugins/contrib/unixauth.mdwn
@@ -3,9 +3,36 @@
 
 This plugin authenticates users against the Unix user database. It presents a similar UI to [[plugins/passwordauth]], but simpler, as there's no need to be able to register or change one's password.
 
-[pwauth](http://www.unixpapa.com/pwauth/) must be installed and working. In particular, it must be configured to recognize the UID of the calling web server, or authentication will always fail. Set `pwauth_path` to the full path of your pwauth binary.
+To authenticate, either [checkpassword](http://cr.yp.to/checkpwd.html) or [pwauth](http://www.unixpapa.com/pwauth/) must be installed and configured. `checkpassword` is strongly preferred. If your web server runs as an unprivileged user -- as it darn well should! -- then `checkpassword` needs to be setuid root. (Or your ikiwiki CGI wrapper, I guess, but don't do that.) Other checkpassword implementations are available, notably [checkpassword-pam](http://checkpasswd-pam.sourceforge.net/).
 
-As [with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike with passwordauth, sniffing these credentials can get an attacker much further than mere wiki access. SSL with this plugin is a __must__.
+Config variables that affect the behavior of `unixauth`:
+
+* `unixauth_type`: defaults to unset, can be "checkpassword" or "pwauth"
+* `unixauth_command`: defaults to unset, should contain the full path and any arguments
+* `unixauth_requiressl`: defaults to 1, can be 0
+* `sslcookie`: needs to be 1 if `unixauth_requiressl` is 1 (perhaps this should be done automatically?)
+
+__Security__: [As with passwordauth](/security/#index14h2), be wary of sending usernames and passwords in cleartext. Unlike passwordauth, sniffing `unixauth` credentials can get an attacker much further than mere wiki access. Therefore, this plugin defaults to not even _displaying_ the login form fields unless we're running under SSL. Nobody should be able to do anything remotely dumb until the admin has done at least a little thinking. After that, dumb things are always possible. ;-)
+
+`unixauth` tests for the presence of the `HTTPS` environment variable. `Wrapper.pm` needs to be tweaked to pass it through; without that, the plugin fails closed.
+
+[[!toggle id="diff" text="Wrapper.pm.diff"]]
+
+[[!toggleable id="diff" text="""
+
+    --- Wrapper.pm.orig 2008-07-29 00:09:10.000000000 -0400
+    +++ Wrapper.pm
+    @@ -28,7 +28,7 @@ sub gen_wrapper () { #{{{
+        my @envsave;
+        push @envsave, qw{REMOTE_ADDR QUERY_STRING REQUEST_METHOD REQUEST_URI
+                       CONTENT_TYPE CONTENT_LENGTH GATEWAY_INTERFACE
+    -                  HTTP_COOKIE REMOTE_USER} if $config{cgi};
+    +                  HTTP_COOKIE REMOTE_USER HTTPS} if $config{cgi};
+        my $envsave="";
+        foreach my $var (@envsave) {
+                $envsave.=<<"EOF"
+
+"""]]
 
 [[!toggle id="code" text="unixauth.pm"]]
 
@@ -40,13 +67,26 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p
         }
     
         my $ret=0;
-        if (! exists $config{pwauth_path}) {
-                $config{pwauth_path}="/usr/libexec/pwauth";
+        if (! exists $config{unixauth_type}) {
+                # admin needs to carefully think over his configuration
+                return 0;
+        }
+        elsif ($config{unixauth_type} eq "checkpassword") {
+                open UNIXAUTH, "|$config{unixauth_command} true 3<&0" or die("Could not run $config{unixauth_type}");
+                print UNIXAUTH "$user\0$password\0Y123456\0";
+                close UNIXAUTH;
+                $ret=!($?>>8);
+        }
+        elsif ($config{unixauth_type} eq "pwauth") {
+                open UNIXAUTH, "|$config{unixauth_command}" or die("Could not run $config{unixauth_type}");
+                print UNIXAUTH "$user\n$password\n";
+                close UNIXAUTH;
+                $ret=!($?>>8);
+        }
+        else {
+                # no such authentication type
+                return 0;
         }
-        open PWAUTH, "|$config{pwauth_path}" or die("Could not run pwauth");
-        print PWAUTH "$user\n$password\n";
-        close PWAUTH;
-        $ret=!($?>>8);
     
         if ($ret) {
             my $userinfo=IkiWiki::userinfo_retrieve();
@@ -69,6 +109,17 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p
         my $session=$params{session};
         my $cgi=$params{cgi};
     
+        # if not under SSL, die before even showing a login form,
+        # unless the admin explicitly says it's fine
+        if (! exists $config{unixauth_requiressl}) {
+                $config{unixauth_requiressl} = 1;
+        }
+        if ($config{unixauth_requiressl}) {
+            if ((! $config{sslcookie}) || (! exists $ENV{'HTTPS'})) {
+                die("SSL required to login. Contact your administrator.<br>");
+            }
+        }
+    
         if ($form->title eq "signin") {
                 $form->field(name => "name", required => 0);
                 $form->field(name => "password", type => "password", required => 0);
@@ -93,6 +144,7 @@ As [with passwordauth](/security/#index14h2), be wary of sending usernames and p
                                 );
                         }
                         
+                        # XXX is this reachable? looks like no
                         elsif ($submittype eq "Login") {
                                 $form->field( 
                                         name => "name",
diff --git a/doc/plugins/contrib/unixauth/discussion.mdwn b/doc/plugins/contrib/unixauth/discussion.mdwn
new file mode 100644
index 000000000..c4f5ff269
--- /dev/null
+++ b/doc/plugins/contrib/unixauth/discussion.mdwn
@@ -0,0 +1,32 @@
+The security of this plugin scares me. As noted in the plugin
+documentation, you basically have to use it with SSL, since snooping on the
+login password doesn't give you an essentially useless account -- it gives
+you an actual account on the machine!
+
+Also, apparently pwauth defers *all* auth attempts if one fails, and it
+does this by using a lock file, and sleeping after a failed auth attempt.
+Which is needed to avoid brute-forcing, since this is a significant
+password.. but how will that interact with ikiwiki? Well, ikiwiki _also_
+uses a lock file. So, at a minimum, someone can not only try to brute-force
+the pwauth password, but the ikiwiki processes that stack up due to that
+will also keep ikiwiki's lock held. Which basically DOSes the wiki for
+everyone else; noone else can try to log in, or log out, or edit a page,
+all of which require taking the lock.
+
+So I don't think I'll be accepting this plugin into ikiwiki itself..
+--[[Joey]]
+
+Thanks for the comments. That's definitely an undesirable interaction between pwauth and ikiwiki; in my current application it wouldn't be a serious problem, but I'd like this plugin to be general-purpose and safe enough for inclusion in ikiwiki. It's the system-users-are-wiki-users idea I'm married to here, not pwauth itself; can you suggest another approach I might take?
+-- [[schmonz]]
+
+> Have you considered using [[plugins/httpauth]] and then the appropriate apache module?  There are apache modules like [mod_authnz_external](http://unixpapa.com/mod_auth_external.html) that might help.  The advantage of these solutions is that they usually make the security implications explicit.  -- Will
+
+Actually, yes. That's how I made sure I had pwauth working to begin with. I'm partial to the form-based approach because I'm not aware of any way to reliably "log out" browsers from HTTP authentication. If that *is* reliably possible, then I worked way too hard for no reason. ;-)
+-- [[schmonz]]
+
+I've added support for [checkpassword](http://cr.yp.to/checkpwd/interface.html), since those generally don't have any rate-limiting cleverness to interfere with ikiwiki's, and made a few other changes. Please check out the plugin docs again and let me know if this is closer to being acceptable.
+-- [[schmonz]]
+
+> I actually think that the rate limiting is a good thing. After all,
+> ikiwiki doesn't do its own login rate limiting. Just need to find a way
+> to disentangle the two locks. --[[Joey]]
diff --git a/doc/plugins/creole.mdwn b/doc/plugins/creole.mdwn
index b6861ab26..ed347e2c5 100644
--- a/doc/plugins/creole.mdwn
+++ b/doc/plugins/creole.mdwn
@@ -12,5 +12,5 @@ wiki markup formats, so should be fairly easy to guess at. There is also a
 [CheatSheet](http://www.wikicreole.org/wiki/CheatSheet).
 
 Links are standard [[WikiLinks|ikiwiki/WikiLink]]. Links and
-[[PreProcessorDirectives]] inside `{{{ }}}` blocks are still expanded,
+[[ikiwiki/PreProcessorDirectives]] inside `{{{ }}}` blocks are still expanded,
 since this happens before the creole format is processed.
diff --git a/doc/plugins/creole/discussion.mdwn b/doc/plugins/creole/discussion.mdwn
new file mode 100644
index 000000000..a31f9cf83
--- /dev/null
+++ b/doc/plugins/creole/discussion.mdwn
@@ -0,0 +1,7 @@
+I've installed Text::WikiCreole 0.05 and enabled the plugin, but I get an error when rebuilding the wiki: `Undefined subroutine &IkiWiki::Plugin::creole::creole_custombarelinks called at /usr/pkg-20080723/lib/perl5/vendor_perl/5.8.0/IkiWiki/Plugin/creole.pm line 23`. Is there a newer Text::WikiCreole I'm not finding online?
+-- [[schmonz]]
+
+> There's a patch in the debian package of libtext-wikicreole-perl that
+> adds that option. I'm not sure what the status of it being released
+> upstream is, though IIRC I was assured it would not be a problem.
+> --[[Joey]]
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 04b6ea8e9..77210d35c 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -128,26 +128,34 @@ of a plugin.
 
         hook(type => "preprocess", id => "foo", call => \&preprocess);
 
-Replace "foo" with the command name that will be used inside brackets for
-the preprocessor directive.
-
-Each time the directive is processed, the referenced function (`preprocess`
-in the example above) is called, and is passed named parameters. A "page"
-parameter gives the name of the page that embedded the preprocessor
-directive, while a "destpage" parameter gives the name of the page the
-content is going to (different for inlined pages), and a "preview"
-parameter is set to a true value if the page is being previewed. All
-parameters included in the directive are included as named parameters as
-well. Whatever the function returns goes onto the page in place of the
+Replace "foo" with the command name that will be used for the preprocessor
 directive.
 
-An optional "scan" parameter, if set to a true value, makes the hook be
-called during the preliminary scan that ikiwiki makes of updated pages,
-before begining to render pages. This parameter should be set to true if
-the hook modifies data in `%links`. Note that doing so will make the hook
-be run twice per page build, so avoid doing it for expensive hooks. (As an
-optimisation, if your preprocessor hook is called in a void contets, you
-can assume it's being run in scan mode.)
+Each time the directive is processed, the referenced function (`preprocess`
+in the example above) is called. Whatever the function returns goes onto
+the page in place of the directive. Or, if the function aborts using
+`error()`, the directive will be replaced with the error message.
+
+The function is passed named parameters. First come the parameters set
+in the preprocessor directive. These are passed in the same order as
+they're in the directive, and if the preprocessor directive contains a bare
+parameter (example: `\[[!foo param]]`), that parameter will be passed with
+an empty value.
+
+After the parameters from the preprocessor directive some additional ones
+are passed: A "page" parameter gives the name of the page that embedded the
+preprocessor directive, while a "destpage" parameter gives the name of the
+page the content is going to (different for inlined pages), and a "preview"
+parameter is set to a true value if the page is being previewed.
+
+If `hook` is passed an optional "scan" parameter, set to a true value, this
+makes the hook be called during the preliminary scan that ikiwiki makes of
+updated pages, before begining to render pages. This should be done if the
+hook modifies data in `%links`. Note that doing so will make the hook be
+run twice per page build, so avoid doing it for expensive hooks. (As an
+optimisation, if your preprocessor hook is called in a void context, you
+can assume it's being run in scan mode, and avoid doing expensive things at
+that point.)
 
 Note that if the [[htmlscrubber]] is enabled, html in
 [[ikiwiki/PreProcessorDirective]] output is sanitised, which may limit what
diff --git a/doc/sandbox/Teximg.mdwn b/doc/sandbox/Teximg.mdwn
new file mode 100644
index 000000000..8483c1489
--- /dev/null
+++ b/doc/sandbox/Teximg.mdwn
@@ -0,0 +1,2 @@
+[[!teximg code="E = - \frac{Z^2 \cdot  \mu \cdot e^4}{32\pi^2 \epsilon_0^2 \hbar^2 n^2}" ]]
+
diff --git a/doc/sandbox/Try_some_math_formulas.mdwn b/doc/sandbox/Try_some_math_formulas.mdwn
new file mode 100644
index 000000000..31eb10813
--- /dev/null
+++ b/doc/sandbox/Try_some_math_formulas.mdwn
@@ -0,0 +1,7 @@
+# Title with $\TeX$
+
+* How about some math?
+* $\frac{1}{2} = \frac{3}{6}$
+
+
+
diff --git a/doc/todo/Allow_change_of_wiki_file_types.mdwn b/doc/todo/Allow_change_of_wiki_file_types.mdwn
new file mode 100644
index 000000000..420651c0a
--- /dev/null
+++ b/doc/todo/Allow_change_of_wiki_file_types.mdwn
@@ -0,0 +1,7 @@
+The new [[plugins/rename]] plugin allows files to be renamed, but doesn't seem to allow changing the page type.  It would be nice if there was a way to change page type through the web interface.
+
+#### Background
+
+I'm currently moving a couple of projects from [Trac](http://trac.edgewall.org/) to Ikiwiki.  I don't want to have to re-do all the wiki formatting at once.  Initially I simply imported all the old wiki pages without suffixes.  This made them appear on the web as raw un-editable text.  I wanted other project members to be able to do the updating to the new markup language, so I then renamed the files to use '.txt' suffixes, and that allows them to be edited.  Unfortunately, there is still no way to convert them to '.mdwn' files on the web.
+
+I was hoping that the [[plugins/rename]] plugin would allow web uses to change the filename suffix, but it doesn't.  This means that the page type can be set on page creation using the web interface, but cannot be changed thereafter using the web interface.  I was thinking the UI would be something like adding the 'Page type' drop-down menu that appears on the creation page to either the edit or rename pages.
diff --git a/doc/todo/color_plugin.mdwn b/doc/todo/color_plugin.mdwn
index 511851ba3..ebf5b084c 100644
--- a/doc/todo/color_plugin.mdwn
+++ b/doc/todo/color_plugin.mdwn
@@ -58,6 +58,11 @@ comments are very welcome. --[[Paweł|ptecza]]
 >> Similar hardcoded method I've found in `img` plugin :) But only one
 >> argument is not named there (image path).
 
+>>> I think I hadn't realized what you were doing there. The order
+>>> for unnamed parameters can in fact be relied on. 
+>>> 
+>>> --[[Joey]]
+
 >> Maybe I shouldn't use so simple plugin syntax? For following syntax
 >> I wouldn't have that problem:
 
@@ -96,6 +101,8 @@ seems to be too enigmatic and it was hard to me to handle unnamed parameters
 in not hardcoded way. I hope that my changes are acceptable for you.
 Of course, I'm open for discussion or exchange of ideas :) --[[Paweł|ptecza]]
 
+> One question, why the 2px padding for span.color? --[[Joey]]
+
 	--- /dev/null	2008-06-21 02:02:15.000000000 +0200
 	+++ color.pm	2008-07-27 14:58:12.000000000 +0200
 	@@ -0,0 +1,69 @@
@@ -146,7 +153,7 @@ Of course, I'm open for discussion or exchange of ideas :) --[[Paweł|ptecza]]
 	+	$content =~ s!<span class="color">((color: ([a-z]+|\#[0-9a-f]{3,6})?)?((; )?(background-color: ([a-z]+|\#[0-9a-f]{3,6})?)?)?)</span>!<span class="color" style="$1">!g;
 	+	$content =~ s!<span class="colorend">!!g;
 	+
-	+	return $content; 
+	+	return $content;
 	+} #}}}
 	+
 	+sub preprocess(@) { #{{{
diff --git a/doc/todo/mbox.mdwn b/doc/todo/mbox.mdwn
index 2df7ed877..dd0e5756b 100644
--- a/doc/todo/mbox.mdwn
+++ b/doc/todo/mbox.mdwn
@@ -2,11 +2,9 @@ I'd like to be able to drop an unmodified RFC2822 email message into ikiwiki, an
 
 > We're discussing doing just that (well, whole mailboxes, really) over in
 > [[comment_by_mail]] --[[Joey]]
-
->> I am going to start putting something simple together, but 
->> probably not too quickly.
->> So far I don't see a way to have ikiwiki process directories 
->> (i.e. maildirs or mh folders) as a single page.  This not that 
->> big of a deal, but it means that every mailbox will need 
->> something like \[[!mailbox type=maildir path=thedir]] in some  
->> "normal" (e.g. markdown) page -- [[DavidBremner]]
+>> If you like to read code, you can have a gander at the 
+>> [mailbox](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=summary) 
+>> plugin.  At the moment, it reads all of the messages in a maildir and passes them through 
+>> a template of your choice.  Kinda acts like `cat` at the moment because none of the 
+>> css is defined yet.  Next missions are threading (Email::Thread?), and maybe some simple css. 
+>> To see the (unsurprising) syntax, look at [a trivial example markdown file](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=blob;f=test/in/index.mdwn;hb=HEAD)
diff --git a/doc/todo/search_terms.mdwn b/doc/todo/search_terms.mdwn
index 0e5edb520..cf1708c34 100644
--- a/doc/todo/search_terms.mdwn
+++ b/doc/todo/search_terms.mdwn
@@ -1,4 +1,4 @@
-The [[plugin/search]] plugin could use xapian terms to allow some special
+The [[plugins/search]] plugin could use xapian terms to allow some special
 searches. For example, "title:foo", or "link:somepage", or "author:foo", or
 "copyright:GPL".