X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/897cf26ab2cf7b8fe3b2b03a096fc7e7c2d8ccb6..a07f048d9fc99928ebbb74b34f5d1932ff3d7884:/doc/ikiwiki/pagespec/discussion.mdwn diff --git a/doc/ikiwiki/pagespec/discussion.mdwn b/doc/ikiwiki/pagespec/discussion.mdwn index ac3038a22..2857a98ba 100644 --- a/doc/ikiwiki/pagespec/discussion.mdwn +++ b/doc/ikiwiki/pagespec/discussion.mdwn @@ -93,6 +93,78 @@ does not seem suitable for this, as also lists the current page and all its siblings. +--- + +I am a little lost. I want to match the start page `/index.mdwn`. So I use + + \[[!inline pages="/index"]] + +which does not work though. I also tried it in this Wiki. Just take a look at the end of the [[SandBox|sandbox]]. --[[PaulePanter]] + +> Unlike wikilinks, pagespecs match relative to the top of the wiki by +> default. So lose the "/" and it will work. --[[Joey]] + + ---- -I'm about to post [[bugs/pagespec can't match curly braces]]. --Ivan Z. +I'd like to create a collapsable tree with a map, eg + +* top level item + +* * second level item1 + +* * * content 1 + +* * * content 2 + +* * * content 3 + +* * second level item2 + +* * second level item3 + + +but I can't work out how to specify "all items at this level, and all directories at ../ and all the other directories to the root + +any ideas? + +> I don't think pagespecs currently support that. How would such a made-up +> pagespec look? I can imagine it supporting something like `glob(../*) and not +> glob(../*/*)` to match all "directories" of the parent page, and so on up +> to the root. --[[Joey]] + +>> I don't know, perhaps some way of nesting pagespecs +>>> glob(../* unless $_ eq 'second level item'{ glob 'second level item'/*}) + +>> but that could get messy, perhaps a new cmd 'pagetree' or something +>> might be better? --Colin + +>>> You could probably do a lot worse than stealing terminology from +>>> [XPath Axes](http://www.w3.org/TR/xpath/#axes), +>>> passing the "argument" through `bestlink` if there is one, and +>>> treating an empty argument as "this page", something like: +>>> +>>> * `ancestor(/plugins/contrib/album)` matches `plugins` or +>>> `plugins/contrib` +>>> but not `plugins/map` or `plugins/contrib/album` +>>> (does it match `index`? answers on a postcard) +>>> * `descendant(/plugins)` is basically `plugins/*` +>>> * `child(/plugins)` is basically `plugins/* and !plugins/*/*` +>>> * `self(/plugins)` is just `plugins` but without interpreting +>>> globs +>>> * `ancestor-or-self(/plugins)`, `descendant-or-self(/plugins)` +>>> are syntactic sugar for e.g. `ancestor(/plugins) or self(/plugins)` +>>> * `self()` always matches the current page (not destpage) +>>> * `ancestor-or-self()` always matches the current pages and all +>>> pages that would go in its [[plugins/parentlinks]] +>>> +>>> XPath has `following-sibling` and `preceding-sibling` axes for +>>> siblings, but pagespecs are unordered, so we'd probably want +>>> to invent `sibling()` - so `sibling(/plugins/map)` matches +>>> `plugins/inline` but not `plugins/map` or `plugins/contrib/album`. +>>> +>>> Then, the requested functionality would be `sibling() or ancestor()`, +>>> or possibly `sibling() or ancestor() or self()`? +>>> --[[smcv]] + +>>>> I like that idea! --[[KathrynAndersen]]