MAJOR basewiki reorg

Including redir pages for the moved basewiki pages. These will be removed in
a future release.

16 files changed, 59 insertions, 71 deletions

diff --git a/doc/todo/absolute_urls_in_wikilinks.mdwn b/doc/todo/absolute_urls_in_wikilinks.mdwn
index ad6e5ff5c..50c2fe16f 100644
--- a/doc/todo/absolute_urls_in_wikilinks.mdwn
+++ b/doc/todo/absolute_urls_in_wikilinks.mdwn
@@ -5,7 +5,7 @@ for pages included into other pages out of the wiki rendering process (shtml for
 since these pages can be included from a subdir. Ditto, links from \[[ inline ..]] or \[[map ..]].
 
 > You can make a wikilink absolute by prefixing it with a /, see 
-> [[subpage/linkingrules/]]. Pagespecs match absolute by default. But what do
+> [[ikiwiki/subpage/linkingrules/]]. Pagespecs match absolute by default. But what do
 > you mean "included from a subdir"? If you inline a page, its links shouldn't 
 > change. --Ethan
 
diff --git a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn
index 869d479c1..c39261e82 100644
--- a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn
+++ b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn
@@ -1,3 +1,10 @@
-[[Wishlist]]: optionally use the [[plugins/contrib/syntax]] plugin automatically on source code files in the repository with recognized extensions or shebangs, and render them as though they consisted of an [[.mdwn|markdown]] page containing nothing but a single call to the syntax plugin with the file contents as the text argument and the recognized type as the type argument.
+[[Wishlist]]: optionally use the [[plugins/contrib/syntax]] plugin
+automatically on source code files in the repository with recognized
+extensions or shebangs, and render them as though they consisted of an
+[[.mdwn|ikiwiki/markdown]] page containing nothing but a single call to the syntax
+plugin with the file contents as the text argument and the recognized type
+as the type argument.
 
-Together with the ability to have [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]], this would allow the use of ikiwiki for [[wikipedia literate programming]].
+Together with the ability to have
+[[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]],
+this would allow the use of ikiwiki for [[wikipedia literate programming]].
diff --git a/doc/todo/basewiki_should_be_self_documenting.mdwn b/doc/todo/basewiki_should_be_self_documenting.mdwn
index d467f2f0b..7dc767e76 100644
--- a/doc/todo/basewiki_should_be_self_documenting.mdwn
+++ b/doc/todo/basewiki_should_be_self_documenting.mdwn
@@ -1,5 +1,5 @@
 The pages in the basewiki should be fully self-documenting as far as what
-users need to know to edit pages in the wiki. [[HelpOnFormatting]]
+users need to know to edit pages in the wiki. [[ikiwiki/Formatting]]
 documents the basics, but doesn't include every preprocessor directive.
 
 Note that there's a disctinction between being self-documenting for users,
@@ -28,33 +28,4 @@ basewiki:
 
 Meta is another one.
 
-The holdup on documenting these in full in the basewiki is that I'm not sure
-where to put the docs. [[HelpOnFormatting]] should stay as simple as possible
-and just give examples, not full lists of availavle parameters, etc. And
-it's bad enough that [[blog]] uses that toplevel namespace, without adding
-lots more toplevel pages to the basewiki. ([[blog]] really needs to be moved..
-I have several wikis that override it with their actual blog content).
-
-Maybe the thing to do would be to make a meta/ or usage/ or wiki/ or something
-directory in the basewiki, and put new pages documenting how to use preprocesor
-directives in there.
-
-Actually, if we look at the basewiki contents:
-
-	blog.mdwn@              pagespec.mdwn@               subpage@
-	favicon.ico@            preprocessordirective.mdwn@  subpage.mdwn@
-	helponformatting.mdwn@  sandbox.mdwn@                templates/
-	index.mdwn@             shortcuts.mdwn@              templates.mdwn@
-	local.css@              smileys@                     wikiicons@
-	markdown.mdwn@          smileys.mdwn@                wikilink.mdwn@
-	openid.mdwn@            style.css@
-
-Most of this is meta stuff. Only index.mdwn, local.css, favicon.ico,
-smileys, wikiicons, shortcuts, and templates are really content/configs that
-are used as the base of a wiki. The rest is documentation.
-
-Moving a lot of these pages could be hard though.. Lots of wikis probably
-link to them. Maybe the directory they're moved to could be in the search
-path, like the userdir is, so that simple links keep working.
-
 See also: [[Conditional_Underlay_Files]]
diff --git a/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn b/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn
index 2ace6a7ef..e5e23531e 100644
--- a/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn
+++ b/doc/todo/conditional_text_based_on_ikiwiki_features.mdwn
@@ -1,6 +1,6 @@
 I'd like to see some way to conditionally include wiki text based on
 whether the wiki enables or disables certain features.  For example,
-[[helponformatting]], could use `\[[if (enabled smiley) """Also, because
+[[ikiwiki/formatting]], could use `\[[if (enabled smiley) """Also, because
 this wiki has the smiley plugin enabled, you can insert \[[smileys]] and
 some other useful symbols."""]]`, and a standard template for [[plugins]]
 pages could check for the given plugin name to print "enabled" or
@@ -10,9 +10,9 @@ Some potentially useful conditionals:
 
 * `enabled pluginname`
 * `disabled pluginname`
-* `any pagespec`: true if any of the pages in the [[PageSpec]] exist
-* `all pagespec`: true if all of the pages in the [[PageSpec]] exist
-* `no pagespec` or `none pagespec`: true if none of the pages in the [[PageSpec]] exist
+* `any pagespec`: true if any of the pages in the [[ikiwiki/PageSpec]] exist
+* `all pagespec`: true if all of the pages in the [[ikiwiki/PageSpec]] exist
+* `no pagespec` or `none pagespec`: true if none of the pages in the [[ikiwiki/PageSpec]] exist
 * `thispage pagespec`: true if pagespec includes the page getting rendered (possibly one including the page with this content on it).
 * `sourcepage pagespec`: true if pagespec includes the page corresponding to the file actually containing this content, rather than a page including it.
 * `included`: true if included on another page, via [[plugins/inline]], [[plugins/sidebar]], [[plugins/contrib/navbar]], etc.
@@ -24,8 +24,8 @@ keep the aliases for simplicity anyway).  You also may or may not want to
 include an `else` clause; if so, you could label the text used if true as
 `then`.
 
-Syntax could vary greatly here, both for the [[PreprocessorDirective]] and
-for the condition itself.
+Syntax could vary greatly here, both for the
+[[ikiwiki/PreprocessorDirective]] and for the condition itself.
 
 > I think this is a good thing to consider, although conditionals tend to
 > make everything a lot more complicated, so I also want to KISS, and not
@@ -56,10 +56,10 @@ for the condition itself.
 > 
 > --[[Joey]]
 
->> [[PageSpec]] syntax seems perfect, and your proposed syntax for the `if`
->> [[PreprocessorDirective]] looks fine to me.
+>> [[ikiwiki/PageSpec]] syntax seems perfect, and your proposed syntax for the `if`
+>> [[ikiwiki/PreprocessorDirective]] looks fine to me.
 >>
->> [[PageSpec]]s don't give you `none` for free, since `!foo/*` as a boolean
+>> [[ikiwiki/PageSpec]]s don't give you `none` for free, since `!foo/*` as a boolean
 >> would mean "does any page not matching `foo/*` exist", not "does `foo/*`
 >> match nothing"; however, I don't really care much about `none`, since I
 >> just threw it in while brainstorming, and I don't know any compelling use
@@ -75,7 +75,7 @@ for the condition itself.
 >>   pages."""]].  The help text would then only appear on the sidebar page
 >>   itself, not the sidebar included on all pages.
 >>
->> * On [[blog]] entries, you could use `included` to implement a cut.
+>> * On [[ikiwiki/blog]] entries, you could use `included` to implement a cut.
 >>   (Please don't take that as an argument against. :) ) For instance, you
 >>   could use included rather than [[plugins/toggle]] for the detailed
 >>   changelogs of ikiwiki, or to embed an image as a link in the feed rather
@@ -105,4 +105,4 @@ This is now completely [[todo/done]]! See [[plugins/conditional]].
 
 --[[Joey]]
 
-> You rock mightily. --[[JoshTriplett]]
\ No newline at end of file
+> You rock mightily. --[[JoshTriplett]]
diff --git a/doc/todo/datearchives-plugin.mdwn b/doc/todo/datearchives-plugin.mdwn
index 8c3faf9ca..4264b5895 100644
--- a/doc/todo/datearchives-plugin.mdwn
+++ b/doc/todo/datearchives-plugin.mdwn
@@ -42,7 +42,9 @@ Index: IkiWiki/Plugin/datearchives.pm
 +1
 </pre>
 
-This works (although accessing `%IkiWiki::pagectime` is not too clever), but it would be far more useful if the date pages were automatically created and populated with the relevant posts. A [[Pagespec]] works perfectly for displaying the relevant content, but we're still left with the issue of actually creating the page. What's the Right Way to do this? We could create them in the RCS working copy and check them in, or create them directly in the output directory... (I'd also like to create an option for the tags plugin to auto-create its targets in the same way). Any opinions? :-)
+This works (although accessing `%IkiWiki::pagectime` is not too clever),
+but it would be far more useful if the date pages were automatically
+created and populated with the relevant posts. A [[ikiwiki/Pagespec]] works perfectly for displaying the relevant content, but we're still left with the issue of actually creating the page. What's the Right Way to do this? We could create them in the RCS working copy and check them in, or create them directly in the output directory... (I'd also like to create an option for the tags plugin to auto-create its targets in the same way). Any opinions? :-)
 
 > Ok, first, I don't understand what your plugin does. Maybe I need to get
 > some sleep, but a better explanation might help. :-) It seems to make
diff --git a/doc/todo/discuss_without_login.mdwn b/doc/todo/discuss_without_login.mdwn
index 74f3cde70..82311459d 100644
--- a/doc/todo/discuss_without_login.mdwn
+++ b/doc/todo/discuss_without_login.mdwn
@@ -5,7 +5,7 @@ Any plugin or option for allowing website visitors to edit the discuss page with
 Or any plugin to add a feedback form (and maybe threads) to extend a Wiki webpage?
 
 Or is there per-page access control that can be fine-tuned to lock some users or groups for specific pages?
-(The [[pagespec]] does show a way to lock all pages except for Discussion pages, but I want some users to also be able to edit other pages.)
+(The [[ikiwiki/pagespec]] does show a way to lock all pages except for Discussion pages, but I want some users to also be able to edit other pages.)
 
 I want a way for website visitors to be able to give feedback on the wiki pages without having to sign up or log in.
 I don't want them to be able to edit the exiting wiki pages except maybe Discussion page.
diff --git a/doc/todo/format_escape.mdwn b/doc/todo/format_escape.mdwn
index 7c9a7f1ec..0f5859b3e 100644
--- a/doc/todo/format_escape.mdwn
+++ b/doc/todo/format_escape.mdwn
@@ -219,7 +219,7 @@ Index: doc/plugins/rst.mdwn
 -* reStructuredText does not allow raw html to be inserted into
 -  documents, but ikiwiki does so in many cases, including
 -  [[WikiLinks|WikiLink]] and many
--  [[PreprocessorDirectives|PreprocessorDirective]].
+-  [[PreprocessorDirectives|ikiwiki/PreprocessorDirective]].
 +* Some bits of ikiwiki may still assume that markdown is used or embed html
 +  in ways that break reStructuredText. (Report bugs if you find any.)
  * It's slow; it forks a copy of python for each page. While there is a
diff --git a/doc/todo/graphviz.mdwn b/doc/todo/graphviz.mdwn
index 31d5787ae..c55a4aa23 100644
--- a/doc/todo/graphviz.mdwn
+++ b/doc/todo/graphviz.mdwn
@@ -1,4 +1,12 @@
-How about a plugin providing a [[preprocessor_directive|preprocessordirective]] to render a [[debpkg graphviz]] file as an image via one of the graphviz programs ("dot" by default) and include the resulting image on the page, using the "cmapx" image map format?  graphviz files themselves could also render the same way into an HTML file with the same basename as the graphviz file; format and program could come either from an ikiwiki configuration option or comments/directives in the file.  (For example, "digraph" could imply "dot", and "graph" could imply "neato".)
+How about a plugin providing a
+[[preprocessor_directive|ikiwiki/preprocessordirective]] to render a
+[[debpkg graphviz]] file as an image via one of the graphviz programs
+("dot" by default) and include the resulting image on the page, using the
+"cmapx" image map format?  graphviz files themselves could also render the
+same way into an HTML file with the same basename as the graphviz file;
+format and program could come either from an ikiwiki configuration option
+or comments/directives in the file.  (For example, "digraph" could imply
+"dot", and "graph" could imply "neato".)
 
 To complement this, ikiwiki could support creating and editing graphviz files through the CGI interface, as a new page type; preview could render the file.  It would also help to have some sort of graphviz extension attribute for linking to a wiki page, which would become a standard href or URL attribute in the input passed to the particular graphviz program.
 
diff --git a/doc/todo/htmlvalidation.mdwn b/doc/todo/htmlvalidation.mdwn
index 6fe2d56f2..96bcd926b 100644
--- a/doc/todo/htmlvalidation.mdwn
+++ b/doc/todo/htmlvalidation.mdwn
@@ -32,7 +32,7 @@
 
     Ah didn't realize you meant it fixed it at the markdown level. I'll
     think about making postprocessordirectives into
-    [[preprocessordirective]]s instead, then I could use that fix (but I'm not
+    [[ikiwiki/preprocessordirective]]s instead, then I could use that fix (but I'm not
     sure how feasible it is to do that). --[[Joey]]
 
     Done.. inlining is now a preprocessor directive, happens before
diff --git a/doc/todo/latex.mdwn b/doc/todo/latex.mdwn
index 8822bd30b..01d927552 100644
--- a/doc/todo/latex.mdwn
+++ b/doc/todo/latex.mdwn
@@ -1,5 +1,5 @@
 How about a plugin adding a
-[[preprocessor_directive|preprocessordirective]] to render some given LaTeX
+[[preprocessor_directive|ikiwiki/preprocessordirective]] to render some given LaTeX
 and include it in the page?  This could either render the LaTeX as a PNG via
 [[debpkg dvipng]] and include the resulting image in the page, or perhaps
 render via [HeVeA](http://pauillac.inria.fr/~maranget/hevea/index.html),
diff --git a/doc/todo/linktitle.mdwn b/doc/todo/linktitle.mdwn
index 8f424fd30..8d6ce3c1f 100644
--- a/doc/todo/linktitle.mdwn
+++ b/doc/todo/linktitle.mdwn
@@ -1,19 +1,19 @@
 Pages could have a `linktitle` (perhaps via [[plugins/meta]]), and
 [[wikilinks|wikilink]] could use that title by default when linking to the
-page.  That would allow pages to have a simple, easily linkable name (without
-spaces, for instance), but use the proper title for links.  For example,
-[[PreprocessorDirective]] could use the `linktitle` "preprocessor directive",
-and pages for [[users]] could have `linktitle`s that put spaces in their
-names.
+page.  That would allow pages to have a simple, easily linkable name
+(without spaces, for instance), but use the proper title for links.  For
+example, [[ikiwiki/PreprocessorDirective]] could use the `linktitle`
+"preprocessor directive", and pages for [[users]] could have `linktitle`s
+that put spaces in their names.
 
-Ideally, perhaps two versions of the title could exist, one for general use,
-and an optional one for if the case in the actual link starts with an
-uppercase letter.  That would allow [[preprocessordirective]] to use the link
-text "preprocessor directive", but [[PreprocessorDirective]] to use the link
-text "Preprocessor Directive", for use at the beginnings of sentences.  If the
-second version did not exist, the first version would apply to both cases.
-However, that also seems like potential overkill, and less important than the
-basic functionality of `linktitle`.
---[[JoshTriplett]]
+Ideally, perhaps two versions of the title could exist, one for general
+use, and an optional one for if the case in the actual link starts with an
+uppercase letter.  That would allow [[ikiwiki/preprocessordirective]] to
+use the link text "preprocessor directive", but
+[[ikiwiki/PreprocessorDirective]] to use the link text "Preprocessor
+Directive", for use at the beginnings of sentences.  If the second version
+did not exist, the first version would apply to both cases. However, that
+also seems like potential overkill, and less important than the basic
+functionality of `linktitle`. --[[JoshTriplett]]
 
 [[wishlist]]
diff --git a/doc/todo/preprocessor_directive_for_proposed_changes.mdwn b/doc/todo/preprocessor_directive_for_proposed_changes.mdwn
index b8577c233..e73e6c09e 100644
--- a/doc/todo/preprocessor_directive_for_proposed_changes.mdwn
+++ b/doc/todo/preprocessor_directive_for_proposed_changes.mdwn
@@ -7,7 +7,7 @@ which can't be made through the web interface:
 
 Of course in these cases, you can add your request to a discussion page
 and wait for someone with the access/confidence to apply them.
-Maybe this can be enhanced with a [[PreprocessorDirective]]:
+Maybe this can be enhanced with a [[ikiwiki/PreprocessorDirective]]:
 
 <pre>
 \[[suggest op=merge dstfile=trunk srcfile=branches/jk oldrev=1234 newrev=1342]]
diff --git a/doc/todo/review_mechanism.mdwn b/doc/todo/review_mechanism.mdwn
index 03c0fa749..5e4ba212e 100644
--- a/doc/todo/review_mechanism.mdwn
+++ b/doc/todo/review_mechanism.mdwn
@@ -15,7 +15,7 @@ This would be done in a way that would trigger the appropriate VCS merge operati
 A generic "change queue" mechanism could be used for translations or other stuff as well.
 Each change would have its own wiki page under changes/revNNNN.
 Change queues would be wiki pages as well (probably using [[inlines|plugins/inline]]);
-[[Pagespecs|Pagespec]] and [[tags]] would be used to control the queues to which a given change would belong.
+[[Pagespecs|ikiwiki/Pagespec]] and [[tags]] would be used to control the queues to which a given change would belong.
 
 --[[JeremieKoenig]]
 
diff --git a/doc/todo/rss_title_description.mdwn b/doc/todo/rss_title_description.mdwn
index cb71a0f1b..3f56a10e0 100644
--- a/doc/todo/rss_title_description.mdwn
+++ b/doc/todo/rss_title_description.mdwn
@@ -18,7 +18,7 @@ A few pointers and I might be able to implement this myself. -- JamesWestby
 > Now, the description field currently defaults to the wiki name,
 > and that could indeed stand to be made configurable. Since the
 > current (svn) version of ikiwiki supports long, word-wrapped
-> blocks of text as parameters to [[PreProcessorDirective]]s, seems
+> blocks of text as parameters to [[ikiwiki/PreProcessorDirective]]s, seems
 > to me the best way would be to simple modify inline.pm to make the
 > descripion configurable by such parameter, with a fallback to the
 > wiki name. You'll need to modify rsspage.tmpl to use whatever new
diff --git a/doc/todo/shortcut_link_text.mdwn b/doc/todo/shortcut_link_text.mdwn
index 6842a911f..d03d37411 100644
--- a/doc/todo/shortcut_link_text.mdwn
+++ b/doc/todo/shortcut_link_text.mdwn
@@ -1,4 +1,4 @@
-[[plugins/shortcut]] creates link shortcut [[PreprocessorDirective]]s,
+[[plugins/shortcut]] creates link shortcut [[ikiwiki/PreprocessorDirective]]s,
 which substitute their argument into the specified shortcut URL to generate
 the link target, and use the argument as the link text.  For example, given
 the example [[shortcuts]], `\[[wikipedia ikiwiki]]` generates a link to
diff --git a/doc/todo/smileys_do_not_work_in_PreprocessorDirective_arguments.mdwn b/doc/todo/smileys_do_not_work_in_PreprocessorDirective_arguments.mdwn
index dabc58dee..a55a66141 100644
--- a/doc/todo/smileys_do_not_work_in_PreprocessorDirective_arguments.mdwn
+++ b/doc/todo/smileys_do_not_work_in_PreprocessorDirective_arguments.mdwn
@@ -1,11 +1,11 @@
-Several [[PreprocessorDirective]]s take ikiwiki-formatted text as arguments,
+Several [[ikiwiki/PreprocessorDirective]]s take ikiwiki-formatted text as arguments,
 such as the `then` and `else` arguments of the new `if` directive, or the
 `desc` argument of the `shortcut` directive.  However, smileys do not work in
 these arguments.
 
-Since the arguments to [[PreprocessorDirective]]s might use the same syntax as
+Since the arguments to [[ikiwiki/PreprocessorDirective]]s might use the same syntax as
 smileys for a different meaning, smiley substitution should not happen until
-after [[PreprocessorDirective]]s.
+after [[ikiwiki/PreprocessorDirective]]s.
 
 --[[JoshTriplett]]