X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/4e4b43898742c78fbd0e8d0281f2297ba8239a8e..25e1a9dece90f4af7d83a25151788a890bac688c:/doc/todo/pagespec_expansions.mdwn diff --git a/doc/todo/pagespec_expansions.mdwn b/doc/todo/pagespec_expansions.mdwn index 58c622f7c..f89501ab9 100644 --- a/doc/todo/pagespec_expansions.mdwn +++ b/doc/todo/pagespec_expansions.mdwn @@ -6,4 +6,100 @@ A couple of suggestions for improving the usefulness of pagespecs: interface for pagespec_match. What do you think? I have lots of pages a/b/c.mdwn that inline "a/b/c/*". ---Ethan \ No newline at end of file +--Ethan + +> I want this too, so that the [[examples]] can use pagespecs that don't +> have to be changed when the pages are moved around. I don't know how I +> feel about the "@" thing, but "./" seems good. I take it you've looked at +> how to implement it? +> +> It's worth mentioning that there's a bit of an inconsistency; wikilinks +> match relative by default and absolute if prefixed with a "/", while +> pagespecs match absolute by default. It would be nice to clear up that +> inconsistency somehow, it's on my little list of things in ikiwiki that +> arn't ideal. :-) --[[Joey]] + +I've looked at how to implement "./", yes, and I was a little hesitant +to disturb the elegant implementation of pagespecs as it is now. That's +why I wrote this todo item rather than just a patch. :) As I see it, +the simplest thing to do is check globs when building the pagespec +expression and translate "./foo" to "$from.'/foo'" in the resulting +expression, and then add the $from paramater to pagespec_match. This does +require an API change for all plugins which use pagespecs but hopefully +it should be minor. I will work on a patch tomorrow. + +My use case for "@" (which is kind of a crummy symbol, but whatever) is +my [projects page](http://www.betacantrips.com/projects/). I want to inline +"summary" or "introduction" pages that are exactly one level below the +inlining page, but not tarballs or other junk that might be in +subdirectories. (The issue is confounded here because of my index.mdwn +patch, but the principle is the same.) I chose "@" because it's similar in +physical shape to "*" but enclosed, suggesting limitations. I also thought +it would be useful in simplifying hacks like in [[plugins/map]] but I see +now that I was mistaken.. "four or fewer levels deep" would be +"@ or @/@ or @/@/@ or @/@/@/@". Well, I think it has a certain appeal but +I can see why it might not be much of an improvement. :) --Ethan + +> Seems to me that ".." would be the natural thing to use, not "@". --[[Joey]] + +>> I don't understand.. "a/b/.." matches a/b/c but not a/b/c/d ? That doesn't +>> seem natural to me at all. --Ethan + +OK, I took a shot at implementing the changes. I was thinking about making +pagespecs relative by default but I couldn't decide whether page +`foo/bar` inlining `*` should match `foo/bar/*` or `foo/*`. +So I punted and left things as absolute, with `./*` matching +`foo/bar/*`, which I think is pretty clear. +The patch is at [ikidev](http://ikidev.betacantrips.com/patches/pagespec_enhancements.patch) +and you can see it work at +[this page](http://ikidev.betacantrips.com/one/two/three/index.html) or +[this page](http://ikidev.betacantrips.com/one/two/three/princess.html) --Ethan + +> Nice patch, though I see the following problems with it: +> * The sole pagespec_match in IkiWiki::Render probably should have `$p` +> as its third parameter. This will allow add_depends to add a +> dependency on a pagespec that matches relative to the page. I made this +> changes and it seems to work, new pages are noticed in updates. + +>> OK, word. + +> * `! $from` fails to match pages named "0" :-) + +>> I don't understand. How did you even get $from into the +>> translated pagespec? + +> * '/./ matches any letter, not just "." :-) :-) + +>> Oof, thanks for catching that. + +> * One other major problem. If you look at the doc/examples/blog/index.mdwn +> I changed it to use relative globs like "./posts/*", but they didn't work, +> because it looked for examples/blog/indexposts/* instead of +> examples/blog/index/posts/*. And, of course, what I really expected it to +> look for was examples/blog/posts/*. I think you may have made the wrong +> choice about that, so I changed it to go the other way. What do you think? + +>> I could have sworn I made a change like that -- I was gonna make a call to +>> basename() or something .. wait, I might have decided not to, because it +>> would interfere with my index patch. Yeah, I guess my code was wrong. +>> Don't "nice patches" usually work? :) My test cases were mostly "./*", +>> so it slipped under the radar. + +>> As for what it should have done, that's much harder! My gut feeling is that +>> "a/b/c.mdwn" inlining `./*` wants `a/b/c/*` and not `a/b/*`, and this is +>> what I programmed for. I also feel that "a/b/c" inlining `./d/*` could go +>> either way. Ideally we'd check for both, maybe using bestlink? + +>> The issue might be confounded some by your use of an index page, and +>> ikiwiki doesn't have good support for those yet :) . +>> I think ideally your index page would be treated as inlining from +>> examples/blog/. To resolve this issue we should consider, for example: +>> clothes/pants inlines `./jeans/*` -- probably means clothes/pants/jeans +>> vacation/bermuda/blog inlines `./pics/*` -- probably vacation/bermuda/pics + +> I've committed support for ./ to ikiwiki now, based on your patch. +> --[[Joey]] + +>> Cool! I haven't played with it yet, but looking over the patch, I see that +>> you added another parameter to match_glob, which is an approach that didn't +>> occur to me. I like it, it's more flexible. --Ethan \ No newline at end of file