more triage

doc/bugs.mdwn

@@ -1,6 +1,7 @@
 This is ikiwiki's bug list. Link bugs to [[bugs/done]] when done.
 
-Also see the [Debian bugs](http://bugs.debian.org/ikiwiki).
+Also see the [Debian bugs](http://bugs.debian.org/ikiwiki), and the
+[[TODO]] page.
 
 [[inline pages="bugs/* and !bugs/done and !bugs/discussion and 
 !link(bugs/done) and !bugs/*/*"

doc/bugs/Command-line_arguments_should_override_settings_in_the_setup_file.mdwn

@@ -17,7 +17,9 @@ So two suggestions to fix this:
 1. Make command-line arguments override settings in the setup file
 
 > This is difficult to do, since reading a setup file replaces values for
-> config items with the values in the setup file.
+> config items with the values in the setup file. Also, when you say
+> --setup foo, you're asking ikiwiki to set up the wiki using the
+> comnfiguration in file foo. Which is what it does.
 
 2. Comment out all settings in the example setup file that are simply
    setting options to their default values. That way, the file will
@@ -25,4 +27,6 @@ So two suggestions to fix this:
    work for these settings while they remain commented out.
 
 > I've done that, I also fixed some issues with --verbose handling earlier.
+> I'm pretty sure that those fixes fix the real issue, so calling this
+> [[done]].
 > --[[Joey]]

doc/patchqueue/calendar_--_archive_browsing_via_a_calendar_frontend.mdwn

@@ -1,3 +1,13 @@
+I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list  of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file).  The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have 
+
+     \[[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
+
+or some thing to generate a archive of postings. 
+
+Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
+
+ManojSrivastava
+
 This plugin is inspired by the calendar plugin for Blosxom, but derivesno code from it. This plugin is essentially a fancy front end to archives of previous pages, usually used for blogs. It can produce a calendar for a given month, or a list of months for a given year. To invoke the calendar, just use the preprocessor directive:
 
      \[[calendar ]]

doc/todo/Account_moderation.mdwn

@@ -8,3 +8,5 @@ the account gets approved.)
 --[[JoshTriplett]]
 
 [[tag soc]]
+
+[[wishlist]]

doc/todo/Add_showdown_GUI_input__47__edit.mdwn

@@ -10,3 +10,6 @@ A demo is at <http://www.attacklab.net/showdown-gui.html>
 > is that it provides a GUI for editing with widets for italics, etc,
 > compared to showdown which still leaves input in markdown and seems more
 > geared to a fast preview of the html. --[[Joey]]
+
+> Since we have semi-working wikiwgy and it's better, I'm considering this
+> todo item as [[done]] or rather, will-not-be-done..

doc/todo/BTS_integration.mdwn

@@ -7,3 +7,5 @@ This seems somewhat difficult, as ikiwiki would need to maintain a cache of the
 [scmbug](http://www.mkgnu.net/?q=scmbug) might help here. --[[JoshTriplett]]
 
 [[tag soc]]
+
+[[tag wishlist]]

doc/todo/Better_bug_tracking_support.mdwn

@@ -45,4 +45,6 @@ be embedded to the source code repository commit messages.
 >> By Google BTS, do you mean the issue tracker in the Google code 
 >> project hosting?
 >>
->> --Teemu
+>> --Teemu
+
+[[wishlist]]

doc/todo/BibTeX.mdwn

@@ -2,4 +2,4 @@ I would *love* to see a plugin that lets you create one or more BibTeX-formatted
 
 --[[JoshTriplett]]
 
-[[tag soc]]
+[[tag soc]] [[tag wishlist]]

doc/todo/Calendar_plugin.mdwn

@@ -1,9 +0,0 @@
-I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list  of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file).  The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have 
-
-     \[[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]
-
-or some thing to generate a archive of postings. 
-
-Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.
-
-ManojSrivastava

doc/todo/Editing_po_files.mdwn

@@ -1,3 +1,5 @@
 ikiwiki could support rendering and editing po files via the web.  Run against
 a software repository, ikiwiki would make for an interesting
-translation-management tool. --[[JoshTriplett]]
+translation-management tool. --[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/IRC_topic.mdwn

@@ -6,3 +6,5 @@ in version control. --[[JoshTriplett]]
 A simple script should be able to poll for the irc topic and update a page,
 then run ikiwiki -refresh to update the wiki. No need to put that in
 ikiwiki or a plugin, though. --[[Joey]]
+
+[[wishlist]]

doc/todo/Improve_signin_form_layout.mdwn

@@ -38,4 +38,7 @@ just have to get stylin'. :-)
 That looks pretty good.. putting the passwordauth part in a box of its own with
 the submit buttons I don't know how to do.
 
+I'm happy enough with what we have now though, with the above improvements.
+Hope you are too, as I'm calling this [[done]]..
+
 --[[Joey]]

doc/todo/OpenSearch.mdwn

@@ -14,3 +14,5 @@ information in `ikiwiki.setup`, and the `title` attribute of the `link` should
 contain the wiki title from `ikiwiki.setup`.
 
 --[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/Plugins_to_provide___34__add_to__34___links_for_popular_feed_readers.mdwn

@@ -1,4 +1,6 @@
 ikiwiki could provide one or more plugins that provide "add to" links for popular feed readers, such as Google Reader, Bloglines, My Yahoo!, or Netvibes.
 
 Potentially less useful given an implementation of [[todo/integration_with_Firefox_and_Iceweasel_feed_subscription_mechanism]].
---[[JoshTriplett]]
+--[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/Support_XML-RPC-based_blogging.mdwn

@@ -10,3 +10,5 @@ blog names would work. --[[JoshTriplett]]
 >> I'd love to see support for this and would be happy to contribute towards a bounty (say US$100) :-).  [PmWiki](http://www.pmwiki.org/) has a plugin which [implements this](http://www.pmwiki.org/wiki/Cookbook/XMLRPC) in a way which seems fairly sensible as an end user.  --[[AdamShand]]
 
 [[tag soc]]
+
+[[tag wishlist]]

doc/todo/abbreviation.mdwn

@@ -1,3 +1,5 @@
 We might want some kind of abbreviation and acronym plugin. --[[JoshTriplett]]
 
- * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page).  -- [[AdamShand]]
+ * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page).  -- [[AdamShand]]
+
+[[wishlist]]

doc/todo/allow_full_post_from_the___34__add_a_new_post__34___form.mdwn

@@ -8,3 +8,5 @@ comment form.
 
 > I agree that having this as an option is reasonable. Although it would
 > take a fair amount of work. --[[Joey]]
+
+[[tag wishlist]]

doc/todo/automatic_use_of_syntax_plugin_on_source_code_files.mdwn

@@ -1,3 +1,3 @@
-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|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]].

doc/todo/block_external_links.mdwn

@@ -12,3 +12,5 @@ This may actually form a subset of the general concept of content policies,
 described at [[todo/fileupload]].
 
 --[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/canonical_feed_location.mdwn

@@ -12,3 +12,5 @@ with all news or the one with the latest news only, I don't know yet.)
 >> That wouldn't use the same style for the RSS and Atom links, and it
 >> wouldn't embed the feed link into `<head>` so that browsers can automatically
 >> find it.
+
+[[tag wishlist]]

doc/todo/html.mdwn

@@ -2,3 +2,5 @@ Create some nice(r) stylesheets.
 
 Should be doable w/o touching a single line of code, just
 editing the [[wikitemplates]] and/or editing [[style.css]].
+
+[[done]] ([[css_market]] ..)

doc/todo/ikibot.mdwn

@@ -4,4 +4,6 @@ Random idea: create an ikiwiki IRC bot, which notices the use of ikiwiki syntax
     <ikihacker> \[[setup]]
     <ikibot> http://ikiwiki.info/setup.html: "This tutorial will walk you through setting up a wiki with ikiwiki. ..."
 
---[[JoshTriplett]]
+--[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/integration_with_Firefox_and_Iceweasel_feed_subscription_mechanism.mdwn

@@ -9,3 +9,5 @@ configure their browser to subscribe to feeds via [[plugins/aggregate]] running
 on their site.  We could then provide the manual configuration settings as a
 [[tip|tips]], and perhaps provide an extension or other mechanism to set them
 automatically. --[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/latex.mdwn

@@ -156,3 +156,5 @@ Thanks for the comment.. is fixed.
 -----
 
 [[tag soc]]
+
+[[tag wishlist]]

doc/todo/linktitle.mdwn

@@ -15,3 +15,5 @@ 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]]

doc/todo/manpages.mdwn

@@ -1,2 +1,4 @@
 ikiwiki could support manpages (or general groff input files) and convert them
 to HTML. --[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/multiple_templates.mdwn

@@ -7,3 +7,5 @@ specify which pages use the non-default template.
 
 Hmm, I think the 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.

doc/todo/pastebin.mdwn

@@ -7,3 +7,5 @@ Desired features:
 * Password protection?
 
 -- [[JoshTriplett]]
+
+[[wishlist]]

doc/todo/rel__61__nofollow_on_external_links.mdwn

@@ -1 +1,4 @@
-Ikiwiki could optionally use rel=nofollow on all external links, or on all those from a configurable subset of pages (such as */discussion if using [[plugins/opendiscussion]]). --[[JoshTriplett]]
+Ikiwiki could optionally use rel=nofollow on all external links, or on all those from a configurable subset of pages (such as */discussion if using [[plugins/opendiscussion]]). --[[JoshTriplett]]
+
+> This is tricky, and would need a html parser, since external links can be
+> added in lots of ways including raw in markdown. --[[Joey]]

doc/todo/source_link.mdwn

@@ -1 +1 @@
-How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
+How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?

doc/todo/spell_check_plug-in.mdwn

@@ -6,4 +6,7 @@ Knot adz fair ass eye no --[[Joey]]
 
 ----
 
-Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
+Firefox 2 (or whatever it will be in Debian) does this for you, and then there's the mozex extension
+
+> Yeah, IMHO gecko's spellchecker nailed this. Spellcheckers server-side
+> are now passe. Calling this [[done]] --[[Joey]]

doc/todo/svg.mdwn

@@ -4,4 +4,6 @@ We should support SVG.  In particular:
 
 * We could support editing SVGs via the web interface.  SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup.
 
---[[JoshTriplett]]
+--[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/tags.mdwn

@@ -8,3 +8,5 @@ Stuff still needing to be done with tags:
 
   This is one good argument for changing ikiwiki so that pages are all
   dir/index.html, then a link to just "dir" works.
+
+  So this could be implemented now for userdirs wikis..

doc/todo/web-based_image_editing.mdwn

@@ -1 +1,3 @@
-We could support web-based image editing, using something like [Snipshot](http://snipshot.com/).  Several comparisons of web-based image editors exist; we would need to choose which one(s) to support. --[[JoshTriplett]]
+We could support web-based image editing, using something like [Snipshot](http://snipshot.com/).  Several comparisons of web-based image editors exist; we would need to choose which one(s) to support. --[[JoshTriplett]]
+
+[[wishlist]]

doc/todo/web_gui_for_managing_tags.mdwn

@@ -7,4 +7,6 @@ As with [[default_content_for_new_post]] I understand that this falls into a bit
 
 MoinMoin has a simple implementation of this, [click here to see an example](http://www.spack.org/wiki/SandBox?action=edit&editor=text).
 
---[[AdamShand]]
+--[[AdamShand]]
+
+[[tag wishlist]]

doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn

@@ -1 +1 @@
-Wishlist item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin.  This would allow the use of links and formatting in comments.
+[[Wishlist]] item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin.  This would allow the use of links and formatting in comments.

doc/todo/wikiwyg.mdwn

@@ -23,3 +23,5 @@ problem. According to the developers, it is possible to do that, and start
 off in WikiText mode.
 
 [[tag soc]]
+
+[[tag wishlist]]