doesn't look like an ikiwiki bug

[git.ikiwiki.info.git] / doc / bugs / entirely_negated_pagespec_matches_internal_pages.mdwn

diff --git a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn
index 012fcec2c29e832d941e8f4c54513d23fa1241a2..a9b223a465cabbc5cc9b3820f6ea4d43ec9345fd 100644 (file)
--- a/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn
+++ b/doc/bugs/entirely_negated_pagespec_matches_internal_pages.mdwn
@@ -3,8 +3,8 @@ matches all other pages, including all internal pages. This can lead to
 unexpected results, since it will match a bunch of recentchanges pages,
 etc.
 
-Recall that internal-use pages are not matched by a glob. So "*" doesn't
-match them. So if the pagespec is "* and !foo and !bar", it won't match
+Recall that internal-use pages are not matched by a glob. So "\*" doesn't
+match them. So if the pagespec is "\* and !foo and !bar", it won't match
 them. This is the much more common style.
 
 There's an odd inconsistency with entirely negated pagespecs. If "!foo"
@@ -21,3 +21,10 @@ pagespec, and implicitly add "and !internal()" to it.
 
 Either approach would require fully parsing the pagespec. And consider cases
 like "!(foo and !bar)". Doesn't seem at all easy to solve. --[[Joey]]
+
+> It occurs to me that at least one place in ikiwiki optimizes by assuming
+> that pagespecs not mentioning the word "internal" never match internal
+> pages. I wonder whether this bug could be solved by making that part of
+> the definition of a pagespec, rather than a risky optimization
+> like it is now? That seems strange, though - having this special case
+> would make pagespecs significantly harder to understand. --[[smcv]]