>>>> 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
* 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: