X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/12eb056b33e1f01a63c4fcee408c9ac0d96c6b5e..a5e84ae3fd07eee895520dcadd0294252539ffee:/doc/ikiwiki/pagespec/discussion.mdwn?ds=inline diff --git a/doc/ikiwiki/pagespec/discussion.mdwn b/doc/ikiwiki/pagespec/discussion.mdwn index 4eed3722c..2857a98ba 100644 --- a/doc/ikiwiki/pagespec/discussion.mdwn +++ b/doc/ikiwiki/pagespec/discussion.mdwn @@ -92,3 +92,79 @@ does not seem suitable for this, as > \[[!map pages="./*"]] 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'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]]