+++ /dev/null
-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" />
\ No newline at end of file
+++ /dev/null
-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]]
+++ /dev/null
-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. --[[Joey]]
+ $page.="</a>$text";
}
else {
- $page.=$text;
\ No newline at end of file
+ $page.=$text;
> do that, use the form to generate a new per-bug page..)
> --[[Joey]]
+
+Marking this [[done]] since it's not a ikiwiki bug directly.
Welcome to ikiwiki's todo list. Link items to [[todo/done]] when done.
-Also see the [Debian bugs](http://bugs.debian.org/ikiwiki).
+Also see the [[wishlist]] and [[bugs]] pages.
-[[inline pages="todo/* and !todo/done and !link(todo/done) and !todo/*/*"
+[[inline pages="todo/* and !todo/done and !link(todo/done) and
+!link(wishlist) and !todo/*/*"
feedpages="created_after(todo/supporting_comments_via_disussion_pages)"
actions=yes rootpage="todo" postformtext="Add a new todo item titled:" show=0]]
--- /dev/null
+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]]
--- /dev/null
+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]]
--- /dev/null
+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]]
--- /dev/null
+These [[todo]] items constitute a wishlist of all kinds of features and
+improvements people would like to see in ikiwiki. Good patches for any of
+these will likely be accepted.
+
+[[inline pages="todo/* and !todo/done and !link(todo/done) and
+link(wishlist) and !todo/*/*" archive=yes show=0]]