X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/aa7fc21824a8f8488e118e4e1e1091a291f7359b..135e5fc63a47d198e6ab6b0ebf30c87087d3f5d5:/doc/patchqueue/index.html_allowed.mdwn diff --git a/doc/patchqueue/index.html_allowed.mdwn b/doc/patchqueue/index.html_allowed.mdwn index c6fb96113..2431b802a 100644 --- 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 >>>> 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 ---- @@ -251,23 +252,201 @@ I'll attach an updated and slightly modified version below. 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? + 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.) -This is only a first pass, I still need to check to see if there are any -code paths where it adds expensive operations such as `abs2rel` that were -not needed before. And I have not audited all the plugins to see if any are -broken by the changes. + > 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: + +
+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
+
+ +* `linkmap.pm` uses `htmlpage` to construct a link and should probably be + changed like this (untested): + +
+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});
+ 		}
+ 	}
+
+ +> 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: + +
+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}));
+
+ +* `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]]