1 files changed, 3 insertions, 1 deletions

diff --git a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
index aa7a590df..ad52d780a 100644
--- a/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
+++ b/doc/bugs/listdirectives_doesn__39__t_register_a_link.mdwn
@@ -96,8 +96,8 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>> --[[smcv]]
 >>>> 
 >>>> (I'll interpet Joeys silence as a good sign ;-). Is there a difference between "link to it" and "path to it"? If we assume autoindex produces bonafide "first class" links there shouldn't be one!?
+>>>>
 >>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that? -- [[holger]]
-
 >>>>> Yes, there *has* to be a difference between a first class wikilink
 >>>>> and the thing to which `map` and `inline` can contribute.
 >>>>> `map` and `inline` use a pagespec to decide what they include,
@@ -110,3 +110,5 @@ The [[ikiwiki/directive/listdirectives]]` directive doesn't register a link betw
 >>>>>
 >>>>> If `inline` generated links, it would inline exactly those pages that
 >>>>> it doesn't inline. That's never going to end well :-) --[[smcv]]
+>>>>>> We have to differentiate between what users of ikiwiki consider first class links and what internally is happening. For the user any link contributing to the structured access tree is first class. The code on the other hand has to differentiate between the static links, then generated links, then orphan links. Three "passes", even your proposed solution could be seen as adding another pass since the orphan plugin has to run after all the plugins generating (first class user) links.   -- [[holger]]
+