+ @@ -879,7 +887,7 @@
+
+ # relative matching
+ if ($glob =~ m!^\./!) {
+ - $from=~s!/?[^/]+$!!;
+ + $from=~s!/?[^/]*$!!;
+ $glob=~s!^\./!!;
+ $glob="$from/$glob" if length $from;
+ }
+
+I independently implemented a similar, but smaller patch.
+(It's smaller because I only care about rendering; not CGI, for example.)
+The key to this patch is that "A/B/C" is treated as equivalent
+to "A/B/C/index".
+Here it is: --Per Bothner
+
+ --- IkiWiki/Render.pm~ 2007-01-11 15:01:51.000000000 -0800
+ +++ IkiWiki/Render.pm 2007-02-02 22:24:12.000000000 -0800
+ @@ -60,9 +60,9 @@
+ foreach my $dir (reverse split("/", $page)) {
+ if (! $skip) {
+ $path.="../";
+ - unshift @ret, { url => $path.htmlpage($dir), page => pagetitle($dir) };
+ + unshift @ret, { url => abs2rel(htmlpage(bestlink($page, $dir)), dirname($page)), page => pagetitle($dir) };
+ }
+ - else {
+ + elsif ($dir ne "index") {
+ $skip=0;
+ }
+ }
+
+ --- IkiWiki.pm~ 2007-01-12 12:47:09.000000000 -0800
+ +++ IkiWiki.pm 2007-02-02 18:02:16.000000000 -0800
+ @@ -315,6 +315,12 @@
+ elsif (exists $pagecase{lc $l}) {
+ return $pagecase{lc $l};
+ }
+ + else {
+ + my $lindex = $l . "/index";
+ + if (exists $links{$lindex}) {
+ + return $lindex;
+ + }
+ + }
+ } while $cwd=~s!/?[^/]+$!!;
+
+ if (length $config{userdir} && exists $links{"$config{userdir}/".lc($link)}) {
+
+Note I handle setting the url; slightly differently.
+Also note that an initial "index" is ignored. I.e. a
+page "A/B/index.html" is treated as "A/B".
+
+> This is actually a pretty cool hack. I'll have to think about
+> whether I like it better than my way though :) --Ethan
+
+---
+
+How about doing the index stuff only on the output side? (Or does the latter patch do it? I haven't tried them.) That is, render every `foo.type` for the rendered types (mdwn etc.) as `foo/index.html`, generating links to `foo/` instead of `foo.html`, but not earlier than the point where the .html as presently appended to the page name. Then you just flip a build time option on an existing wiki without any changes to that, and the pages appear elsewhere. The `index.type` files might be left out of this scheme, though (and the top-level one, of course, has to). --[[tuomov]]
+
+> Well, get around to wasting time on it after all, and [here's the patch](http://iki.fi/tuomov/use_dirs.diff). The `-use_dirs` option will cause everything to be rendered inside directories. There may still be some problems with it, that need looking into (it doesn't e.g. check for conflicts between foo/index.mdwn and foo.mdwn), but seems to work well enough for me... The patch also improves, I think, the parentlinks code a little, as it uses generic routines to actually find the target location now. The only places where the `use_dirs` option is used is `htmlpage`, in fact, although other specific kludges needed to be removed from other points in the code.
+
+>> FWIW, [use_dirs.diff](http://iki.fi/tuomov/use_dirs.diff) applies cleanly, and works well for me. Given that it makes this behaviour optional, how about merging it? I have some follow-up patches which I'm sitting on for now. ;-) -- Ben
+
+>>> How do you apply a patch created by svn diff? I've been curious about this for a long time. The use_dirs patch looks OK but I'd like to play with it. --Ethan
+
+>>>> Just do `svn co svn://ikiwiki.kitenet.net/ikiwiki/trunk ikiwiki` then `cd ikiwiki && patch -p0 <use_dirs.diff`. :-) Same would work with a tarball as well.
+
+>>>>> Sorry, I'm dumb. I'm so used to doing -p1 that doing -p0 never occurred to me; I thought the patch format generated by svn diff was just "wrong". --Ethan
+
+----
+
+First pass over Tumov's patch -- which doesn't cleanly apply anymore, so
+I'll attach an updated and slightly modified version below.
+
+* `urlto()` is O(N) to the number of pages in the wiki, which leads to
+ O(N^2) behavior, which could be a scalability problem. This happens because
+ of the lookup for `$to` in `%renderedfiles`, which shouldn't be necessary
+ most of the time. Couldn't it just be required that `$to` be a html page
+ name on input? Or require it be a non-html page name and always run
+ htmlpage on it.
+
+ > Perhaps it would be possible to require that, but it seems like a
+ > very artificial restriction. The renderedfiles search is just a
+ > copy-paste from htmllink, and I'm no perl (or ikiwiki internals)
+ > expert... maybe there would be a faster way to do the check whether
+ > name translation is needed? No more than O(log n) steps should be
+ > needed for a simple search, after all, and maybe there would be shortcuts
+ > for even constant-time (in n) checks. --[[tuomov]]
+
+ >> Ah, so much easier to critque other people's code than your own.
+ >> You're right, this is a general problem, and I can get it to log n
+ >> if I really want to. --[[Joey]]
+
+* As we discussed in email, this will break handling of `foo/index.mdwn`
+ pages. Needs to be changed to generate `foo/index/index.html` for such
+ pages (though not for the toplevel `index`).
+
+ >> Can someone elaborate on this? What's broken about it? Will pages
+ >> foo/index/index.html include foo/index in their parentlinks? --Ethan
+
+ >>> Presently the patch does not move `foo/index.type` as `foo/index/index.html`, but renders
+ >>> it as `foo/index.html`, not because I particularly want that (except for the top-level one, of
+ >>> course), but because it could be done :). This, however, conflicts with a `foo.mdwn`
+ >>> rendered as `foo/index.html`. The easiest and cleanest way to fix this, is to simply
+ >>> not handle `index` in such a special manner -- except for the top-level one. --[[tuomov]]
+
+ >>>> Oh, I see, this patch doesn't address wanting to use foo/index.mdwn as
+ >>>> an input page. Hmm. --Ethan
+
+ >>>>> No, it doesn't. I originally also was after that, but after discussing the
+ >>>>> complexities of supporting that with Joey, came up with this simpler scheme
+ >>>>> without many of those issues. It is the output that I primarily care about, anyway,
+ >>>>> and I do, in fact, find the present input file organisation quite nice. The output
+ >>>>> locations just aren't very good for conversion of an existing site to ikiwiki, and do
+ >>>>> make for rather ugly URLs with the .html extensions. (I do often type some URLs
+ >>>>> out of memory, when they're gone from the browser's completion history, and the
+ >>>>> .html makes that more laboursome.)
+
+ >>>>>> I support your decision, but now this wiki page serves two different patches :).
+ >>>>>> Can we split them somehow?
+ >>>>>> What are the complexities involved?
+ >>>>>> I think I overcomplicated it a little with my patch, and Per Bothner's gets
+ >>>>>> much closer to the heart of it. --Ethan
+
+* This does make the resulting wikis much less browsable directly on the
+ filesystem, since `dir` to `dir/index.html` conversion is only handled by web
+ servers and so you end up browsing to a directory index all the time.
+ Wouldn't it be better to make the links themselves include the index.html?
+ (Although that would mean that [[bugs/broken_parentlinks]] would not be
+ fixed en passant by this patch..)
+
+ > Yes, the sites are not that browsable on the FS (I blame the browsers
+ > for being stupid!), but linking to the directory produces so much
+ > cleaner URLs for the Web, that I specifically want it. This is,
+ > after all, an optional arrangement.
+
+ >> It's optional for *now* ... I suppose that I could make adding the
+ >> index.html yet another option. I'm not _that_ fond of optioons
+ >> however. --[[Joey]]
+
+ >>> It is worth noting, that with this patch, you _can_ render the local
+ >>> copy in the present manner, while rendering the Web copy under
+ >>> directories. So no extra options are really needed for local browsing,
+ >>> unless you also want to serve the same copy over the Web, which I
+ >>> doubt. --[[tuomov]]
+
+* Some of the generated links are missing the trailing / , which is
+ innefficient since it leads to a http redirect when clicking on that
+ link. Seems to be limited to ".." links, and possibly only to
+ parentlinks. (Already fixed it for "." links.)
+
+ > The solution seems to be to add to `urlto` the following snippet,
+ > which might also help with the next point. (Sorry, no updated patch
+ > yet. Should be on my way out in the cold anyway...)
+
+ if ( !length $to ) {
+ return baseurl($from);
+ }
+
+
+* It calles abs2rel about 16% more often with the patch, which makes it
+ a bit slower, since abs2rel is not very efficient. (This omits abs2rel
+ calls that might be memoized away already.) This seems to be due to one
+ extra abs2rel for the toplevel wiki page due to the nicely cleaned up code
+ in `parentlinks` -- so I'm not really complaining.. Especially since the
+ patch adds a new nice memoizable `urlto`.
+* The rss page name generation code seems unnecesarily roundabout, I'm sure
+ that can be cleaned up somehow, perhaps by making `htmlpage` more
+ generic.
+
+ > Something like `targetpage(basename, extension)`?
+
+ >> Yes exactly. It might also be possible to remove htmlpage from the
+ >> plugin interface entirely (in favour of urlto), which would be a
+ >> good time to make such a changes. Not required to accept this patch
+ >> though.
+
+* `aggregate.pm` uses htmlpage in a way that breaks with its new behavior.
+ It will need to be changed as follows:
+
+<pre>
+Index: aggregate.pm
+===================================================================
+--- aggregate.pm (revision 2700)
++++ aggregate.pm (working copy)
+@@ -320,7 +320,7 @@
+ # NB: This doesn't check for path length limits.
+ eval q{use POSIX};
+ my $max=POSIX::pathconf($config{srcdir}, &POSIX::_PC_NAME_MAX);
+- if (defined $max && length(htmlpage($page)) >= $max) {
++ if (defined $max && length(htmlfn($page)) >= $max) {
+ $c="";
+ $page=$feed->{dir}."/item";
+ while (exists $IkiWiki::pagecase{lc $page.$c} ||
+@@ -356,7 +356,7 @@
+ if (ref $feed->{tags}) {
+ $template->param(tags => [map { tag => $_ }, @{$feed->{tags}}]);
+ }
+- writefile(htmlpage($guid->{page}), $config{srcdir},
++ writefile(htmlfn($guid->{page}), $config{srcdir},
+ $template->output);
+
+ # Set the mtime, this lets the build process get the right creation
+@@ -434,4 +434,8 @@
+ return "$config{srcdir}/".htmlpage($page);
+ } #}}}
+
++sub htmlfn ($) { #{{{
++ return shift().".html";
++} #}}}
++
+ 1
+</pre>
+
+* `linkmap.pm` uses `htmlpage` to construct a link and should probably be
+ changed like this (untested):
+
+<pre>
+Index: linkmap.pm
+===================================================================
+--- linkmap.pm (revision 2700)
++++ linkmap.pm (working copy)
+@@ -50,8 +50,7 @@
+ foreach my $item (keys %links) {
+ if (pagespec_match($item, $params{pages}, $params{page})) {
+ my $link=htmlpage($item);
+- $link=IkiWiki::abs2rel($link, IkiWiki::dirname($params{page}));
+- $mapitems{$item}=$link;
++ $mapitems{$item}=urlto($link, $params{destpage});
+ }
+ }
+</pre>
+
+> This is probably supposed to be `$mapitems{$item}=urlto($item, $params{destpage});`,
+> which does indeed remove one more `htmlpage` call from the plugins. I can't actually
+> try it: "failed writing to dst/ts.png.ikiwiki-new: Inappropriate ioctl for device".
+
+>> Crazy perl bug that ioctl thing. Worked around now in svn. --[[Joey]]
+
+> After this probable fix, in fact, all uses of htmlpage in the plugins are used to
+> construct an absolute address: the absolute url in most cases, so an `absurl`
+> call could be added to be used instead of htmlpage, and something else in the
+> aggregate plugin (above), that I also think isn't what's wanted:
+> aren't `foo.html` pages also "rendered", so that they get moved as `foo/index.html`?
+> --[[tuomov]]
+
+* `inline.pm` uses htmlpage and `abs2rel` to generate a link, and probably
+ needs to be changed to either use `urlto` or to call `beautify_url` like
+ htmllink does. This might work:
+
+<pre>
+Index: inline.pm
+===================================================================
+--- inline.pm (revision 2700)
++++ inline.pm (working copy)
+@@ -150,10 +150,7 @@
+ # Don't use htmllink because this way the
+ # title is separate and can be overridden by
+ # other plugins.
+- my $link=bestlink($params{page}, $page);
+- $link=htmlpage($link) if defined $type;
+- $link=abs2rel($link, dirname($params{destpage}));
+- $template->param(pageurl => $link);
++ $template->param(pageurl => urlto(bestlink($params{page}, $page), $params{destpage}));
+ $template->param(title => pagetitle(basename($page)));
+ $template->param(ctime => displaytime($pagectime{$page}));
+</pre>
+
+* `img.pm` makes some assumptions about name of the page that will be
+ linking to the image, which are probably broken.
+
+* The changes to htmlpage's behavior probably call for the plugin
+ interface version number to be changed.
+
+--[[Joey]]