* perl is broken: print "" || die fails! Work around this insanity.

[git.ikiwiki.info.git] / doc / patchqueue / index.html_allowed.mdwn

diff --git a/doc/patchqueue/index.html_allowed.mdwn b/doc/patchqueue/index.html_allowed.mdwn
index 44b2a22055a662ecc4e0a171827b0fdba9a686d0..2431b802a8b7169c7b41354d332cea458353f5cf 100644 (file)
--- a/doc/patchqueue/index.html_allowed.mdwn
+++ b/doc/patchqueue/index.html_allowed.mdwn
@@ -241,6 +241,7 @@ How about doing the index stuff only on the output side? (Or does the latter pat
 
 >>>> 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.   
 
 
 >>>> 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

 
 ----
 
 
 ----
 


@@ -253,17 +254,86 @@ I'll attach an updated and slightly modified version below.
   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.
   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`).
 * 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?
 * 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.)
 * 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
 * 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


@@ -274,8 +344,109 @@ I'll attach an updated and slightly modified version below.
   that can be cleaned up somehow, perhaps by making `htmlpage` more
   generic.
 
   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>
+
+> 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]]
 
 
 --[[Joey]]