15 files changed, 290 insertions, 10 deletions
diff --git a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn
index 7586c060b..36161e8b4 100644
--- a/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn
+++ b/doc/todo/Post-compilation_inclusion_of_the_sidebar.mdwn
@@ -28,3 +28,40 @@ NicolasLimare
 > sidebar could be done as you describe using .shtml. --[[Joey]]
 
 [[wishlist]]
+
+> I have a plan for a way to avoid unecessary rebuilds caused by the
+> sidebar. The idea is to use wikistate to store what a sidebar renders to.
+> Then in the needsbuild hook, render sidebar(s) and compare with their
+> previous stored rendering. If a sidebar's rendered content has changed,
+> then all pages that display that sidebar need to be forced to be rebuilt.
+> 
+> Also, if there is no previous stored rendering for a sidebar, or
+> if there is a stored rendering for a sidebar page that no longer exists, then
+> the pages need to be rebuilt. (This should deal with the [[bugs/Building_a_sidebar_does_not_regenerate_the_subpages]] bug.
+> 
+> This would also save significant time, since the stored sidebar rendering
+> could just be dumped into the page by the pagetemplate hook. Current code
+> re-loads and renders the same sidebar file for every page built!
+> 
+> The sticky part is (relative) links on the sidebar. These would need to
+> be modified somehow depending on the page that the sidebar is placed on,
+> to not break the link.
+> 
+> Another wrinkle is changing subpage links on a sidebar. Suppose a sidebar
+> links to page `foo`. If page `bar/foo` exists, the sidebar on page bar will, 
+> currently, link to that page, in preference to a toplevel `foo`.
+> If `bar/foo` is removed, it will update to link to `foo`. With the new
+> scheme, the stored sidebar rendering is not for page `foo`, and so
+> the change of the `bar/foo` link will not be noticed or acted on.
+> Granted, it's unlikely that anyone relies on the current behavior. You
+> generally want links on a sidebar to link to the same place on every page
+> that displays it. So finding some way to force all links on a sidebar to 
+> be handled absolutely and documenting that would avoid this problem.
+>
+> So, one way to handle both the above problems would be to use the
+> pre-rendered sidebar for each page, but use a html parser to look for
+> links in it, and munge them to work as relative links on the page the
+> sidebar is being added to. Or, if the wiki's url is known, just do this
+> once when rendering the sidebar, adding the full url to the links.
+> (Maybe require `url` be set when using sidebar?)
+> --[[Joey]] 
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index ab9263556..f60fc3d6e 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -1,4 +1,4 @@
-It would be great if I could tell ikiwiki to automatically instantiate pages for each tag, according to a template, especially when `$tagbase` is set.
+It would be great if I could tell ikiwiki to automatically instantiate pages for each [[tag|/tags]], according to a template, especially when `$tagbase` is set.
 
 Tags are mainly specific to the object to which they’re stuck. However, I often use them the other way around, too: as concepts. And sometimes I’d like to see all pages related to a given concept (“tagged with a given tag”). The only way to do this with ikiwiki is to instantiate a page for each tag and slap a map on it. This is quite tedious and I’d really love to see Ikiwiki do so by default for all tags.
 
@@ -10,7 +10,7 @@ I would love to see this as well. -- dato
 
 ---
 
-I have create a patch to tag.pm for add the option for auto create tag pages.
+I have create a patch to [[tag.pm|plugins/tag]] for add the option for auto create tag pages.
 A new setting is used to enable or disable auto-create tag pages, `tag_autocreate`.
 The new tag file is created during the preprocess phase. 
 The new tag file is then complied during the change phase.
@@ -96,7 +96,7 @@ _tag.pm from version 3.01_
 	+
 
 
-This uses a template called `autotagpage.tmpl`, here is my template file:
+This uses a [[template|wikitemplates]] called `autotagpage.tmpl`, here is my template file:
 
     \[[!inline pages="link(<TMPL_VAR TAG>)" archive="yes"]]
 
@@ -106,3 +106,20 @@ I am not sure if that is the best way to handle it.
 
 [[!tag patch]]
 -- Jeremy Schultz <jeremy.schultz@uleth.ca>
+
+No, this doesn't help:
+
+	+       # This refresh/saveindex is to fix the Tags link
+	+       # With out this additional refresh/saveindex the tag link displays ?tag
+	+       IkiWiki::refresh();
+	+       IkiWiki::saveindex();
+
+On the second extra pass, it doesn't notice that it has to update the "?"-link. If I run ikiwiki once more, it is updated. I don't know yet how this should be fixed, because I don't know the internals of ikiwiki well enough. Something inhibits detecting the need to update in refresh() in Render.pm; perhaps, this condition: 
+
+		if (! $pagemtime{$page}) {
+                   ...
+				push @add, $file;
+                   ...
+                }
+
+is not satisfied for the newly created tag page. I shall put debug msgs into Render.pm to find out better how it works. --Ivan Z.
diff --git a/doc/todo/blogspam_training.mdwn b/doc/todo/blogspam_training.mdwn
new file mode 100644
index 000000000..f15eba59d
--- /dev/null
+++ b/doc/todo/blogspam_training.mdwn
@@ -0,0 +1,31 @@
+The [[blogspam plugin|plugins/blogspam]] is just great.
+
+However, it lacks support in the web interface to [train comments as
+SPAM](http://blogspam.net/api/classifyComment.html), when they were
+erroneously identified as ham.  It would be great to have such
+support, also in the spirit of helping
+[blogspam.net](http://blogspam.net) to get better and better.
+
+What would consist the most appropriate user interface is not entirely
+clear to me in the general case (wiki page editing).  The case of blog
+comments look easier to: when the admin user is logged in (and if the
+blogspam plugin is enabled), each comment can have an extra link "mark
+as SPAM" which would both delete/revert the comment and submit it to
+the configured blogspam server for training.
+
+> Comments can't have an extra link when the admin user is logged
+> in, because the admin user sees the same static pages as everyone
+> else (non-admins still see the "remove" link provided by the remove
+> plugin, too). Perhaps a better UI would be that the action of that
+> link was overridden by the blogspam plugin to go to a form with
+> a checkbox for "also submit as spam"? --[[smcv]]
+
+Similarly, ham training can be plugged directly into the current
+comment moderation interface. Each comment that gets approved by the
+admin, can be sent to blogspam.net as ham. If this is considered too
+"aggressive", this behaviour can need to be explicitly enabled by
+turning on a configuration option.
+
+-- [[Zack]]
+
+[[!tag wishlist]]
diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn
new file mode 100644
index 000000000..4c9c2352a
--- /dev/null
+++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn
@@ -0,0 +1,34 @@
+At the moment the text area in the edit form has a fixed size of 20 rows.
+
+On longer pages its not very comfortable to edit pages with such a small box. The whole screen size should be used instead([example](http://img3.imagebanana.com/img/bl10u9mb/editingtodo_1241804460828.png)).
+
+> The whole screen width is used, via the following
+> from style.css:
+>
+>	{
+>	 width: 100%;
+>	}
+>
+> Perhaps you have replaced it with a modified style sheet that does not
+> include that? --[[Joey]] [[!tag done]]
+
+>> The screen shot was made with http://ikiwiki.info/ where i didn't change anything. The width is optimally used. The problem is the height.
+
+>>> You confused me by talking about rows...  
+>>> I don't know how to allow CSS to resize a textarea
+>>> to the full browser height. The obvious `height: 75%;`
+>>> does not work, at least in firefox and epiphany.
+>>> 
+>>> Ah, of course, if it did work, it'd make it be 75% of
+>>> the full *page* height, and not the browser window height.
+>>>
+>>> According to
+>>> [this page](http://stackoverflow.com/questions/632983/css-height-if-textarea-as-a-percentage-of-the-viewport-height):
+>>>>>50% of what? Parent says ‘auto’, which means base it on the height of the child content. Which depends on the height on the parent. Argh! etc.
+>>>>>
+>>>>>So you have to give its parent a percentage height. And the parent's parent, all the way up to the root.
+>>> So, other than a javascript-based resizer, some very tricky and invasive CSS
+>>> seems to be needed. Please someone let me know if you succeed in doing that.
+>>> --[[Joey]] 
+
+>>>>>> the javascript approach would need to work something like this: you need to know about the "bottom-most" item on the edit page, and get a handle for that object in the DOM. You can then obtain the absolute position height-wise of this element and the absolute position of the bottom of the window to determine the pixel-difference. Then, you set the height of the textarea to (current height in px) + determined-value. This needs to be re-triggered on various resize events, at least for the window and probably for other elements too. I may have a stab at this at some point. -- [[Jon]]
diff --git a/doc/todo/friendly_markup_names.mdwn b/doc/todo/friendly_markup_names.mdwn
new file mode 100644
index 000000000..f88e3c1c7
--- /dev/null
+++ b/doc/todo/friendly_markup_names.mdwn
@@ -0,0 +1,13 @@
+On the edit form when you are creating a new page, you are given an option of
+page types that can be used. The string presented to the user here is not
+particularly friendly: e.g., mdwn, txtl... it would be nice if the drop-down
+contents were "Markdown", "Textile", etc. (the values in the option tags can
+remain the same).
+
+I've written a first-take set of patches for this. They are in
+git://github.com/jmtd/ikiwiki.git in the branch "friendly_markup_names".  [[!tag patch]]
+
+-- [[Jon]]
+
+[[merged|done]], TFTP! (I have not checked if any other format plugins
+would benefit from a longer name) --[[Joey]]
diff --git a/doc/todo/hidden_links__47__tags.mdwn b/doc/todo/hidden_links__47__tags.mdwn
index 43d7a8797..2a4749394 100644
--- a/doc/todo/hidden_links__47__tags.mdwn
+++ b/doc/todo/hidden_links__47__tags.mdwn
@@ -5,9 +5,9 @@ Using the tag functionality I could group some news items for including them int
 The tagged items should not differ from the items, that are not tagged.  
 I didn't find any way to hide the tag list or links and I don't want to have to create a "hidden" page containing links to the pages and then using the backlink functionality, because this is more prone to errors. It's easier to forget adding a link on a second page than forgetting to add a needed tag to a new newsitem.  
 
-> I found out, that using the meta plugin it is possible to create the hidden link, that I wanted.  
+> I found out, that using the [[meta plugin|plugins/meta]] it is possible to create the hidden link, that I wanted.  
 -- [[users/Enno]]
 
->> Yes, meta link will not show up as a visible link on the page, while
+>> Yes, [[meta link|ikiwiki/directive/meta]] will not show up as a visible link on the page, while
 >> also not showing up in the list of tags of a page, so it seems what you
 >> want. [[done]] --[[Joey]] 
diff --git a/doc/todo/inlines_inheriting_links.mdwn b/doc/todo/inlines_inheriting_links.mdwn
new file mode 100644
index 000000000..12531990c
--- /dev/null
+++ b/doc/todo/inlines_inheriting_links.mdwn
@@ -0,0 +1,20 @@
+[[!tag wishlist]]
+
+Continuing the ideas in [[bugs/Inline doesn't wikilink to pages]].
+
+I thought of a use case for another feature: making [[ikiwiki/directive/inline]] inherit the link relations of the included pages (optionally, say, with `inheritlinks=yes`). For example, if I want to list `elements/*` that have been linked to in any of `new_stuff/*`, I could try to write a [[ikiwiki/pagespec]] like
+`elements/* and backlink(new_stuff/*)`.
+
+This is not yet possible, as discussed in [[todo/tracking_bugs_with_dependencies]].
+
+It would be possible to work around this limitation of pagespecs if it was possible to create a page `all_new_stuff` with `\[[!inline pages="new_stuff/*" inheritlinks=yes]]`: then the desired pagespec would be expressed as `elements/* and backlink(all_new_stuff)`.
+
+> Or, instead of specifying whether to inherit at the place of the inline, add more relations (`inline`, `backinline`) and relation composition (say, `*`, or haskell-ish `$` in order not confuse with the glob `*`) and explicitly write in the pagespecs that you want to follow the inline relation backwards: `elements/* and backlink$backinline(all_new_stuff)` or, equivalently, if [["classes"|todo/tracking_bugs_with_dependencies]] are implemented in pagespecs: `elements/* and backlink(backinline(all_new_stuff))`. Of course, this suggestion requires the powerful extension to pagespecs, but it gives more flexibility, and the possibility to avoid redundant information: the same pagespec at two places -- the inline and the other matching construction.
+>
+> BTW, adding more relations -- the `inline` relation among them -- would satisfy [[the other feature request|bugs/Inline doesn't wikilink to pages]]. --Ivan Z.
+
+This is not just an ugly workaround. The availability of this feature has some reason: the classes of pages you want to refer to "recursively" (in that kind of complex pagespecs) tend to have some meaning themselves. So, I might indeed want to have a page like `all_new_stuff`, it would be useful for me. And at the same time I would like to write pagespecs like `elements/* and backlink(all_new_stuff)` -- and using the proposed feature in [[todo/tracking_bugs_with_dependencies/]] would be less clean because then I would have to enter the same information at two places: the possibly complex pagespec in the inline. And having redundant information leads to inconsistency.
+
+So in a sense, in some or most cases, it would indeed be cleaner to "store" the definition of a class of pages referred to in complex pagespecs as a separate object. And the most natural representation for this definition of a class of pages (adhering to the principle of wiki that what you mean is entered/stored in its most natural representation, not through some hidden disconnected code) is making a page with an inline/map/or the like, so that at the same time you store the definition and you see what it is (the set of pages is displayed to you).
+
+I would actually use it in my current "project" in ikiwiki: I actually edit a set of materials as a set of subpages `new_stuff/*`, and I also want to have a combined view of all of them (made through inline), and at another page, I want to list what has been linked to in  `new_stuff/*` and what hasn't been linked to.--Ivan Z.
diff --git a/doc/todo/interactive_todo_lists.mdwn b/doc/todo/interactive_todo_lists.mdwn
new file mode 100644
index 000000000..22b92953a
--- /dev/null
+++ b/doc/todo/interactive_todo_lists.mdwn
@@ -0,0 +1,49 @@
+This is a fleshed out todo based on discussions at
+[[forum/managing_todo_lists]].
+
+I would like to have TODO lists inside ikiwiki wikis. This would mean:
+
+* a new markup plugin to support a language suitable for TODO lists (OPML,
+  XOXO are two possible candidates)
+* some javascript to provide interactive editing.
+
+As [[chrysn]] pointed out on the forum page, this has some crossover with
+[[structured page data]]. In particular, if the markup language chosen had a
+concept of invalid markup (existing plugins just tend to ignore stuff that
+isn't explicitly part of their markup) we would need to sensibly handle that.
+Perhaps rejecting web edits and providing context help on why the edit was
+rejected, although that sounds like a significant headache.
+
+I have started working on this, albeit slowly. A proof of concept is at
+<http://dev.jmtd.net/outliner/>.
+
+There are two git repositories associated with my WIP: one contains the
+javascript, the plugin, the changes made to page templates; the other contains
+the contents of that wiki-site (so the test todos and the contents of bugs/
+which forms a sort-of todo list for the todo list :) ) I will endeavour to get
+mirrors of those repos up on github or similar asap.
+
+-- [[Jon]]
+
+----
+
+Just to report the WIP plugin for this is now in a reasonably good state. I ended
+up just inventing a new markup language -- for now, items are divided by newlines
+and lists are one-dimensional, for simplicity. I got fed up thinking about how to
+handle the structured data issues / needing a lot of boilerplate around items and
+the implications for the "new item" dialogue.
+
+Still quite a lot to do though!
+
+-- [[Jon]]
+
+I've pushed a copy of the work in progress which consists of
+
+ * A change to page.tmpl
+ * A javascript underlay directory + javascript file
+ * a few CSS bits in a local.css
+ * a plugin
+
+to <http://github.com/jmtd/ikiwiki_todolist/>
+
+-- [[Jon]]
diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
new file mode 100644
index 000000000..d3c3a1375
--- /dev/null
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -0,0 +1,9 @@
+[[!tag wishlist]]
+
+As noted in [[todo/tag_pagespec_function]], there is a "misbehavior" of a `tagged()` pagespec: it matches even pages which have plain links to the tag page.
+
+And in general, it would be quite useful to be able to distinguish different kinds of links: one more kind, in addition to "tag", is "bug dependency" noted in [[todo/structured_page_data#another_kind_of_links]] and [[todo/tracking_bugs_with_dependencies#another_kind_of_links]].
+
+It could distinguish the links by the `rel=` attribute. ([[Tags already receive a special rel-class|todo/rel_attribute_for_links]].) This means there is a general need for a syntax to specify user-defined rel-classes on wikilink (then bug deps would simply use their special rel-class, either directly, or through a special directive like `\[[!depends ]]`), and to refer to them in pagespecs (in forward and backward direction).
+
+Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z.
diff --git a/doc/todo/more_flexible_inline_postform.mdwn b/doc/todo/more_flexible_inline_postform.mdwn
new file mode 100644
index 000000000..112220394
--- /dev/null
+++ b/doc/todo/more_flexible_inline_postform.mdwn
@@ -0,0 +1,14 @@
+Using the [[plugins/inline]] plugin, you can get an inline-postform for
+creating new pages.
+
+It would be quite nice to have the flexibility to do this outside of the
+inline directive.
+
+I've got a proof-of-concept hacked inline comment submission example at
+<http://dev.jmtd.net/comments/> for example. I've just copied the HTML from
+the post form and stuck it inside a [[plugins/toggle]].
+
+(Before Simon completed the comments plugin, I thought this would the a
+logical first step towards doing comment-like things with inlined pages).
+
+-- [[Jon]]
diff --git a/doc/todo/pagespec_relative_to_a_target.mdwn b/doc/todo/pagespec_relative_to_a_target.mdwn
index 4757988e0..00030cce6 100644
--- a/doc/todo/pagespec_relative_to_a_target.mdwn
+++ b/doc/todo/pagespec_relative_to_a_target.mdwn
@@ -90,8 +90,12 @@ diff -urNX ignorepats ikiwiki/IkiWiki/Plugin/relative.pm ikidev/IkiWiki/Plugin/r
 
 [[!tag patch]]
 
-> This looks really interesting.  It reminds me of XPath and its conditionals.
+> This looks really interesting.  It reminds me of [[!wikipedia XPath]] and its conditionals.
 > Those might actually work well adapted to pagespecs.  For instance, to write
 > "match any page with a child blah", you could just write *[blah] , or if you
 > don't want to use relative-by-default in the conditionals, *[./blah].
 > -- [[JoshTriplett]]
+
+> And it [[!taglink also_reminds_me|pagespec_in_DL_style]] of [[!wikipedia description logics]]: of course, given the relation `subpage` one could write a description-logic-style formula which would define the class of pages that are ("existentially") in a given relation (`subpage` or `inverse(subpage)*subpage`) to a certain other class of pages (e.g., named "blah") ("existentially" means there must exist a page, e.g., named "blah", which is in the given relation to the candidate).
+
+> Probably the model behind XPath is similar (although I don't know enough to say this definitely).--Ivan Z.
diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn
index 22f67cc0a..72bfd8dea 100644
--- a/doc/todo/structured_page_data.mdwn
+++ b/doc/todo/structured_page_data.mdwn
@@ -82,6 +82,10 @@ See also:
 >    rather than all pages linked from a given page.
 >
 >The first use case is handled by having a template in the page creation.  You could
+
+
+
+
 >have some type of form to edit the data, but that's just sugar on top of the template.
 >If you were going to have a web form to edit the data, I can imagine a few ways to do it:
 >
@@ -243,8 +247,9 @@ in a large number of other cases.
 
 > would match `data_eq(Depends on,6)`, `data_link(Depends on,bugs/bugA)`, `data_link(Depends on,bugs/bugB)`
 > or, if you applied the patch in [[todo/tracking_bugs_with_dependencies]] then you can use 'defined pagespecs'
-> such as `data_link(Depends on,~openBugs)`.  The ability to label links like this allows separation of
+> such as `data_link(Depends on,~openBugs)`. <a id="another_kind_of_links" />The ability to label links like this allows separation of
 > dependencies between bugs from arbitrary links.
+>> This issue (the need for distinguished kinds of links) has also been brought up in other discussions: [[tracking_bugs_with_dependencies#another_kind_of_links]] (deps vs. links) and [[tag_pagespec_function]] (tags vs. links). --Ivan Z.
 
 ----
 
diff --git a/doc/todo/tag_pagespec_function.mdwn b/doc/todo/tag_pagespec_function.mdwn
index 681a1f661..3604a83d9 100644
--- a/doc/todo/tag_pagespec_function.mdwn
+++ b/doc/todo/tag_pagespec_function.mdwn
@@ -12,7 +12,14 @@ match tagged pages independent of whatever the tagbase is set to.
 > 
 > The only problem I see is it could be confusing if `tag(foo)` matched
 > a page that just linked to the tag via a wikilink, w/o actually tagging it.
->
+
+>> (My [[!taglink wishlist]].) Yes, this is confusing and not nice. I observed this misbehavior, because I wanted to match two different lists of pages (only tagged or linked in any way), but it didn't work. Would this feature require a complex patch? --Ivan Z.
+
+>>> If you link to a page 'foo' which happens to be a tag then the page you link from will turn up in the set of pages returned by tagged(foo). The only way to avoid this would be for the tag plugin to not use wikilinks as an implementation method. That itself would not be too hard to do, but there might be people relying on the older behaviour. A better alternative might be to have a "tag2" plugin (or a better name) which implements tagging entirely separately. -- [[Jon]]
+>>>> I see; at least, your response is encouraging (that it's not hard). I could even find some work that can give similar features: [[structured page data#another_kind_of_links]] -- they envisage a pagespec like `data_link(Depends on,bugs/bugA)`, thus a "separation of dependencies between bugs from arbitrary links".
+
+>>>> Indeed, having many relations that can be used in the formulas defining classes of objects (like pagespecs here) is a commonly imagined thing, so this would be a nice feature. (I'll be trying out the patches there first, probably.) In general, extending the language of pagespecs to something more powerful (like [[!wikipedia description logics]]) seems to be a nice possible feature. I saw more discussions of ideas [[!taglink about_the_extension_of_the_pagespec_language_in_the_direction_similar_to_description_logics|pagespec_in_DL_style]] somewhere else here. --Ivan Z.
+
 > One other thing, perhaps it should be called `tagged()`? --[[Joey]] 
 
 [[!tag patch done]]
diff --git a/doc/todo/tags.mdwn b/doc/todo/tags.mdwn
index 682acfa1f..ee9151116 100644
--- a/doc/todo/tags.mdwn
+++ b/doc/todo/tags.mdwn
@@ -1,4 +1,4 @@
-Stuff still needing to be done with tags:
+Stuff still needing to be done with [[/tags]]:
 
 * It's unfortunate that the rss category (tag) support doesn't include
   a domain="" attribute in the category elements. That would let readers
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index 2832e37aa..8b36f1e59 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -11,6 +11,8 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so
 >
 >> I thought about this briefly, and got about that far.. glad you got
 >> further. :-) --[[Joey]]
+
+>> Or, one [[!taglink could_also_refer|pagespec_in_DL_style]] to the language of [[!wikipedia description logics]]: their formulas actually define classes of objects through quantified relations to other classes. --Ivan Z.
 > 
 > Another option would be go with a more functional syntax.  The concept here would
 > be to allow a pagespec to appear in a 'pagespec function' anywhere a page can.  e.g.
@@ -58,6 +60,7 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so
 
 >> So, equivilant example: `define(bugs, bugs/* and !*/Discussion) and define(openbugs, bugs and !link(done)) and openbugs and !link(openbugs)`
 >> 
+
 >> Re recursion, it is avoided.. but building a pagespec that is O(N^X) where N is the
 >> number of pages in the wiki is not avoided. Probably need to add DOS prevention.
 >>  --[[Joey]]
@@ -67,13 +70,15 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so
 
 >>>> Yeah, guess that'd work. :-)
 
-> One quick further thought.  All the above discussion assumes that 'dependency' is the
+> <a id="another_kind_of_links" />One quick further thought.  All the above discussion assumes that 'dependency' is the
 > same as 'links to', which is not really true.  For example, you'd like to be able to say
 > "This bug does not depend upon [ [ link to other bug ] ]" and not have a dependency.
 > Without having different types of links, I don't see how this would be possible.
 >
 > -- [[Will]]
 
+>> I saw that this issue is targeted at by the work on [[structured page data#another_kind_of_links]]. --Ivan Z.
+
 Okie - I've had a quick attempt at this.  Initial patch attached.  This one doesn't quite work.
 And there is still a lot of debugging stuff in there.
 
@@ -188,6 +193,41 @@ The following three inlines work for me with this patch:
 I've lost track of the indent level, so I'm going back to not indented - I think this is a working [[patch]] taking into
 account all comments above (which doesn't mean it is above reproach :) ).  --[[Will]]
 
+> Very belated code review of last version of the patch:
+> 
+> * `is_globlist` is no longer needed
+> * I don't understand why the pagespec match regexp is changed
+>   from having flags `igx` to `ixgs`. Don't see why you
+>   want `.` to match '\n` in it, and don't see any `.` in the regexp 
+>   anyway?
+> * Some changes of `@_` to `%params` in `pagespec_makeperl` do not
+>   make sense to me. I don't see where \%params is defined and populated,
+>   except with `\$params{specFunc}`.
+> * Seems that the only reason `match_glob` has to check for `~` is
+>   because when a named spec appears in a pagespec, it is translated
+>   to `match_glob("~foo")`. If, instead, `pagespec_makeperl` checked
+>   for named specs, it could convert them into `check_named_spec("foo")`
+>   and avoid that ugliness.
+> * The changes to `match_link` seem either unecessary, or incomplete.
+>   Shouldn't it check for named specs and call
+>   `check_named_spec_existential`?
+> * Generally, the need to modify `match_*` functions so that they
+>   check for and handle named pagespecs seems suboptimal, if
+>   only because there might be others people may want to use named
+>   pagespecs with. It would be possible to move this check
+>   to `pagespec_makeperl`, by having it check if the parameter
+>   passed to a pagespec function looked like a named pagespec.
+>   The only issue is that some pagespec functions take a parameter
+>   that is not a page name at all, and it could be weird
+>   if such a parameter were accidentially interpreted as a named
+>   pagespec. (But, that seems unlikely to happen.)
+> * I need to check if your trick to avoid infinite recursion
+>   works if there are two named specs that recursively
+>   call one-another. I suspect it does, but will test this
+>   myself..
+>  
+> --[[Joey]] 
+
 ----
 
     diff --git a/IkiWiki.pm b/IkiWiki.pm