>>>> 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
----
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
that can be cleaned up somehow, perhaps by making `htmlpage` more
generic.
-This is only a first pass, I have not yet audited all the plugins to see if
-any are broken by the changes.
+ > 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>
+
+* `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]]