doc/todo/pagespec_expansions.mdwn

   1 A couple of suggestions for improving the usefulness of pagespecs:
   2
   3 * @ to match [^/]* (i.e. all pages exactly one level below this one)
   4 * initial ./ to mean "from the page the pagespec is running from".
   5   This would require some architectural changes and a change to the
   6   interface for pagespec_match. What do you think? I have
   7   lots of pages a/b/c.mdwn that inline "a/b/c/*".
   8
   9 --Ethan
  10
  11 > I want this too, so that the [[examples]] can use pagespecs that don't
  12 > have to be changed when the pages are moved around. I don't know how I
  13 > feel about the "@" thing, but "./" seems good. I take it you've looked at
  14 > how to implement it?
  15 >
  16 > It's worth mentioning that there's a bit of an inconsistency; wikilinks
  17 > match relative by default and absolute if prefixed with a "/", while
  18 > pagespecs match absolute by default. It would be nice to clear up that
  19 > inconsistency somehow, it's on my little list of things in ikiwiki that
  20 > arn't ideal. :-) --[[Joey]]
  21
  22 I've looked at how to implement "./", yes, and I was a little hesitant
  23 to disturb the elegant implementation of pagespecs as it is now. That's
  24 why I wrote this todo item rather than just a patch. :) As I see it,
  25 the simplest thing to do is check globs when building the pagespec
  26 expression and translate "./foo" to "$from.'/foo'" in the resulting
  27 expression, and then add the $from paramater to pagespec_match. This does
  28 require an API change for all plugins which use pagespecs but hopefully
  29 it should be minor. I will work on a patch tomorrow.
  30
  31 My use case for "@" (which is kind of a crummy symbol, but whatever) is
  32 my [projects page](http://www.betacantrips.com/projects/). I want to inline
  33 "summary" or "introduction" pages that are exactly one level below the
  34 inlining page, but not tarballs or other junk that might be in
  35 subdirectories. (The issue is confounded here because of my index.mdwn
  36 patch, but the principle is the same.) I chose "@" because it's similar in
  37 physical shape to "*" but enclosed, suggesting limitations. I also thought
  38 it would be useful in simplifying hacks like in [[plugins/map]] but I see
  39 now that I was mistaken.. "four or fewer levels deep" would be
  40 "@ or @/@ or @/@/@ or @/@/@/@". Well, I think it has a certain appeal but
  41 I can see why it might not be much of an improvement. :) --Ethan
  42
  43 > Seems to me that ".." would be the natural thing to use, not "@". --[[Joey]]
  44
  45 >> I don't understand.. "a/b/.." matches a/b/c but not a/b/c/d ? That doesn't
  46 >> seem natural to me at all. --Ethan
  47
  48 OK, I took a shot at implementing the changes. I was thinking about making
  49 pagespecs relative by default but I couldn't decide whether page
  50 `foo/bar` inlining `*` should match `foo/bar/*` or `foo/*`.
  51 So I punted and left things as absolute, with `./*` matching
  52 `foo/bar/*`, which I think is pretty clear.
  53 The patch is at [ikidev](http://ikidev.betacantrips.com/patches/pagespec_enhancements.patch)
  54 and you can see it work at
  55 [this page](http://ikidev.betacantrips.com/one/two/three/index.html) or
  56 [this page](http://ikidev.betacantrips.com/one/two/three/princess.html) --Ethan
  57
  58 > Nice patch, though I see the following problems with it:
  59 > * The sole pagespec_match in IkiWiki::Render probably should have `$p`
  60 >   as its third parameter. This will allow add_depends to add a
  61 >   dependency on a pagespec that matches relative to the page. I made this
  62 >   changes and it seems to work, new pages are noticed in updates.
  63
  64 >> OK, word.
  65
  66 > * `! $from` fails to match pages named "0" :-)
  67
  68 >> I don't understand. How did you even get $from into the
  69 >> translated pagespec?
  70
  71 > * '/./ matches any letter, not just "." :-) :-)
  72
  73 >> Oof, thanks for catching that.
  74
  75 > * One other major problem. If you look at the doc/examples/blog/index.mdwn
  76 >   I changed it to use relative globs like "./posts/*", but they didn't work,
  77 >   because it looked for examples/blog/indexposts/* instead of
  78 >   examples/blog/index/posts/*. And, of course, what I really expected it to
  79 >   look for was examples/blog/posts/*. I think you may have made the wrong
  80 >   choice about that, so I changed it to go the other way. What do you think?
  81
  82 >> I could have sworn I made a change like that -- I was gonna make a call to
  83 >> basename() or something .. wait, I might have decided not to, because it
  84 >> would interfere with my index patch. Yeah, I guess my code was wrong.
  85 >> Don't "nice patches" usually work? :) My test cases were mostly "./*",
  86 >> so it slipped under the radar.
  87
  88 >> As for what it should have done, that's much harder! My gut feeling is that
  89 >> "a/b/c.mdwn" inlining `./*` wants `a/b/c/*` and not `a/b/*`, and this is
  90 >> what I programmed for. I also feel that "a/b/c" inlining `./d/*` could go
  91 >> either way. Ideally we'd check for both, maybe using bestlink?
  92
  93 >> The issue might be confounded some by your use of an index page, and
  94 >> ikiwiki doesn't have good support for those yet :) .
  95 >> I think ideally your index page would be treated as inlining from
  96 >> examples/blog/. To resolve this issue we should consider, for example:
  97 >> clothes/pants inlines `./jeans/*` -- probably means clothes/pants/jeans
  98 >> vacation/bermuda/blog inlines `./pics/*` -- probably vacation/bermuda/pics
  99
 100 > I've committed support for ./ to ikiwiki now, based on your patch.
 101 > --[[Joey]]
 102
 103 >> Cool! I haven't played with it yet, but looking over the patch, I see that
 104 >> you added another parameter to match_glob, which is an approach that didn't
 105 >> occur to me. I like it, it's more flexible. --Ethan