]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/pagespec_expansions.mdwn
Added a comment
[git.ikiwiki.info.git] / doc / todo / pagespec_expansions.mdwn
index 74fe9c13c441364d94e89f2a2aa0f347761e5d8d..6107f5489673d847f20d86512eb9e3579b4c4e4a 100644 (file)
@@ -40,12 +40,112 @@ 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
 
-> 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
\ No newline at end of file
+> 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
+
+>>> Ah.. in that case, why not use "a/b/* and !a/b/*/*" ? No need for a new
+>>> symbol. --[[Joey]]
+
+>>>> I know it's not necessary, but it would be helpful. --Ethan
+
+>>>>> I don't see the need for a new syntax since it's only a little long
+>>>>> using the old one. And of course even that can now be shortened: 
+>>>>> "./* and !./*/*" --[[Joey]]
+
+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
+
+>>> What strikes me about your examples is that the "right thing" is
+>>> utterly contect dependent. Unfortunatly, I don't think that using
+>>> bestlink inside pagespec is possible. bestlinks change as pages are
+>>> added/removed, and dealing with the matches of a pagespec changing when
+>>> some page that is added or removed seems Hard.
+>>>
+>>> Since it seems we have to arbitrarily pick one of the two behaviors, I
+>>> prefer the one I picked for two reasons:
+>>> 1. The other behavior can be obtained easily from it, for example,
+>>>    use ./c/* to limit the matches to that subdir.
+>>> 2. The common case is a bunch of pages in a single directory, not lots
+>>>    of deeply nested subdirs.
+>>> --[[Joey]]
+
+>>>> Context-dependence was my conclusion too. My feeling is that inlining
+>>>> in a subdirectory of the current page is more common, but I don't 
+>>>> really know. However, I think the changes as written should work OK
+>>>> with my index patch and allowing inlining from a/b/c/, so I'm
+>>>> satisfied. --Ethan
+
+> I've committed support for ./ to ikiwiki now, based on your patch.
+> [[todo/done]]
+> --[[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
+
+One last thing -- could you either change:
+
+                $from=~s!/?[^/]+$!!;
+
+to 
+
+                $from=~s!/?[^/]*$!!;
+
+Or could you put in:
+
+                $glob =~ s!//!/!g;
+
+somewhere? Or should I just add this to my index patch? --Ethan
+
+> If it's specific to your index patch, let's put it in there. --[[Joey]]