X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/33046583917175c0dbbb028158a573a01eea80b1..b72ab47d70be1a0371b3de3c588967c2842dc75e:/doc/patchqueue/index.html_allowed.mdwn?ds=inline

diff --git a/doc/patchqueue/index.html_allowed.mdwn b/doc/patchqueue/index.html_allowed.mdwn
index c8b3b6b2b..5904b6096 100644
--- a/doc/patchqueue/index.html_allowed.mdwn
+++ b/doc/patchqueue/index.html_allowed.mdwn
@@ -263,6 +263,10 @@ I'll attach an updated and slightly modified version below.
       > 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`).
@@ -270,6 +274,30 @@ I'll attach an updated and slightly modified version below.
   >> 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.
@@ -282,10 +310,30 @@ I'll attach an updated and slightly modified version below.
      > 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
@@ -298,6 +346,11 @@ I'll attach an updated and slightly modified version below.
 
      > 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: