3 files changed, 133 insertions, 0 deletions
diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn
new file mode 100644
index 000000000..68e24b4d4
--- /dev/null
+++ b/doc/todo/Add_label_to_search_form_input_field.mdwn
@@ -0,0 +1,21 @@
+The default searchform.tmpl looks rather bare and unintuitive with just an input field.
+
+The patch below adds a label for the field to improve usability:
+
+    --- templates/searchform.tmpl.orig	Fri Jun 15 15:02:34 2007
+    +++ templates/searchform.tmpl	Fri Jun 15 15:02:41 2007
+    @@ -1,5 +1,6 @@
+     <form method="get" action="<TMPL_VAR SEARCHACTION>" id="searchform">
+     <div>
+    +<label for="phrase">Search:</label>
+     <input type="text" name="phrase" value="" size="16" />
+     <input type="hidden" name="enc" value="UTF-8" />
+     <input type="hidden" name="do" value="hyperestraier" />
+
+> I don't do this by default because putting in the label feels to me make
+> the action bar too wide. YMMV. What I'd really like to do is make the
+> _content_ of the search field say "search". You see that on some other
+> sites, but so far the only way I've seen to do it is by inserting a
+> nasty lump of javascript. --[[Joey]]
+
+[[wishlist]]
diff --git a/doc/todo/Buggy_dependency_graph.mdwn b/doc/todo/Buggy_dependency_graph.mdwn
new file mode 100644
index 000000000..980435111
--- /dev/null
+++ b/doc/todo/Buggy_dependency_graph.mdwn
@@ -0,0 +1,82 @@
+I think there is a problem in my "dependency graph". As an example, 
+[here](http://poivron.org/~nil/misc/ikiwiki_buggy_index) is the index 
+ikiwiki generated for [my site](http://poivron.org/~nil/misc/ikiwiki_buggy_index)
+(note that the site changed since this index was generated).
+
+Some **HUGE** dependencies appear, clearly non optimal, like
+
+    depends = A｜ B | A | C | A | D | A | E | A | F | A | G | ....
+
+or 
+
+    depends= A | B | C | D | A | B | C | D | A | B | C | D | ....
+
+Couldn't isolate the cause, but some sources for this problem may be:
+
+* related to the img module
+* easily observable in my sire because one of my pages includes 80 resized images
+
+Other special things in my templates and site:
+
+* a sidebar with \[[include pages="notes/\*" template=foo]] while notes.mdwn has 
+  a \[[include pages="notes/*"]] and uses the sidebar; removed it, doesn't change
+* a template (biblio.tmpl) calling the "img" plugin with a template parameter as the
+  image filename; removed it, doesn't change
+* some strange games with tags whose page calls a "map" directive to show other tags
+  shile tags are also used in tagclouds (in the sidebar and in the main pages)
+* ...
+
+I observed these problems (same *kind*, I didn't check in details) on
+ 
+* ikiwiki 2.00gpa1 + v5.8.4 + Debian 3.1
+* ikiwiki 2.3 + v5.8.8 + Ubuntu 7.04
+
+I can think about reducung the size of my wiki source and making it available online for analysis.
+
+-- NicolasLimare
+
+> As long as these dependencies don't grow over time (ie, when a page is
+> edited and nothing changed that should add a dependency), I wouldn't
+> worry about them. There are many things that can cause non-optimal
+> dependencies to be recorded. For one thing, if you inline something, ikiwiki
+> creates a dependency like:
+> 
+> (PageSpec) or (file1 or file2 or file3 ...)
+> 
+> Where fileN are all the files that the PageSpec currently matches. (This
+> is ncessary to detect when a currently inlined file is deleted, and know
+> the inlining page needs an update.) Now consider what it does if you have
+> a single page with two inline statements, that inline the same set of
+> stuff twice:
+> 
+> ((PageSpec) or (file1 or file2 or file3 ...) or (PageSpec) or (file1 or file2 or file3 ...)
+>
+> Clearly non-optimal, indeed.
+> 
+> Ikiwiki doesn't bother to simplify complex PageSpecs
+> because it's difficult to do, and because all they use is some disk
+> space. Consider what ikiwiki uses these dependencies for.
+> All it wants to know is: does the PageSpec for this page it's considering
+> rebuilding match any of the pages that have changed? Determining this is
+> a simple operation -- the PageSpec is converted to perl code. The perl
+> code is run.
+> 
+> So the total impact of an ugly dependency like this is:
+> 
+> 1. Some extra data read/written to disk.
+> 2. Some extra space in memory.
+> 3. A bit more data for the PageSpec translation code to handle. But that
+>    code is quite fast.
+> 4. Typically one extra function call when the generated perl code is run.
+>    Ie, when the expression on the left-hand side fails, which typically
+>    happens after one (inexpensive) function call, it has to check
+>    the identical expression on the right hand side.
+> 
+> So this is at best a wishlist todo item, not a bug. A PageSpec simplifier
+> (or improved `pagespec_merge()` function) could be written and improve
+> ikiwiki's memory and disk usage, but would it actually speed it up any?
+> We'd have to see the code to the simplifier to know.
+> 
+> --[[Joey]]
+
+[[tag wishlist]]
diff --git a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn
new file mode 100644
index 000000000..7586c060b
--- /dev/null
+++ b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn
@@ -0,0 +1,30 @@
+In some sites (mine, for example), the pages are quasi-static, while the sidebar must be updated at each commit
+(because it contains some lists, like "last posts" or "last updates", or a tagcloud). As this sidebar is included
+in every page of the site, many commits can potentialy leat to a full re-compilation....
+
+I think a sidebar included after the compilation (via a SSI mechanism for example) would make sense and 
+reduce the dependencies.
+
+Different things could be possible:
+
+* output as .shtml instead of .html
+* ignore the sidebar->page dependency links
+* consider the *real* dependencies; pageA may include the title (only) of pageB, but don't need to be recompiled 
+after each typo correction on pageB.
+
+shtml output with open cgi web access is a potential security hole and can DoS the site, but it's not a problem for a 
+single-editor site.
+
+NicolasLimare
+
+> This is a good idea, though sadly not portable enough to be the default.
+> Especially if the only way to do it is with .shtml.
+> But I really like the idea of not rebuilding the sidebar all the time. 
+> Definitly a TODO, for me, if I can figure out how to do it. Patches
+> eagerly accepted. 
+> 
+> I have implemented a htmlext configuration item, that lets you control
+> what extension ikiwiki uses for output html pages. So in theory, a
+> sidebar could be done as you describe using .shtml. --[[Joey]]
+
+[[wishlist]]