From f5322fa912250cb2859bb63aeae419a405f74544 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Sat, 1 Aug 2009 12:31:53 +0100 Subject: Mark todo/source_link as done --- doc/todo/source_link.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn index 9d9ec9697..a7203d06c 100644 --- a/doc/todo/source_link.mdwn +++ b/doc/todo/source_link.mdwn @@ -107,3 +107,5 @@ I just implemented this. There is one [[patch]] to the default page template, a } 1 + +[[done]] --[[smcv]] -- cgit v1.2.3 From c0c1e05daba09ce9c73c6c2f1ceca02b488613ba Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 8 Aug 2009 12:32:39 -0400 Subject: finish merging getsource --- debian/copyright | 2 +- doc/plugins/getsource.mdwn | 4 ++-- doc/todo/source_link.mdwn | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/debian/copyright b/debian/copyright index 762f9f445..b06d27f19 100644 --- a/debian/copyright +++ b/debian/copyright @@ -136,7 +136,7 @@ Files: 404.pm Copyright: © 2009 Simon McVittie License: GPL-2+ -Files: wmd.pm +Files: wmd.pm, getsource.pm Copyright: © 2009 William Uther License: GPL-2+ diff --git a/doc/plugins/getsource.mdwn b/doc/plugins/getsource.mdwn index 4fbf4be98..20040ccee 100644 --- a/doc/plugins/getsource.mdwn +++ b/doc/plugins/getsource.mdwn @@ -1,7 +1,7 @@ [[!template id=plugin name=getsource author="[[Will_Uther|Will]]"]] -This plugin adds a `getsource` action to the IkiWiki CGI, and a "Source" link -that uses it to display pages' source. +This plugin adds a "Source" link to the top of each page that uses +the CGI to display the page's source. Configuration for this plugin in the setup file: diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn index 0c639a314..dfc2766cc 100644 --- a/doc/todo/source_link.mdwn +++ b/doc/todo/source_link.mdwn @@ -13,6 +13,7 @@ All of this code is licensed under the GPLv2+. -- [[Will]] [[!template id=gitbranch branch=smcv/ready/getsource author="[[Will]]/[[smcv]]"]] +[[done]] >> I've applied the patch below in a git branch, fixed my earlier criticism, >> and also fixed a couple of other issues I noticed: -- cgit v1.2.3 From fd80cec18d4ad6f2f1ecbe1feb37f065b6bb1f26 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 10 Aug 2009 16:31:51 -0400 Subject: idea --- doc/todo/paste_plugin.mdwn | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 doc/todo/paste_plugin.mdwn (limited to 'doc/todo') diff --git a/doc/todo/paste_plugin.mdwn b/doc/todo/paste_plugin.mdwn new file mode 100644 index 000000000..83384a8d7 --- /dev/null +++ b/doc/todo/paste_plugin.mdwn @@ -0,0 +1,36 @@ +It was suggested that using ikiwiki as an alternative to pastebin services +could be useful, especially if you want pastes to not expire and be +cloneable. + +All you really need is a special purpose ikiwiki instance that you commit +to by git. But a web interface for pasting could also be nice. + +There could be a directive that inserts a paste form onto a page. The form +would have a big textarea for pasting into, and might also have a file +upload button (for uploading instead of pasting). It could also copy the +page edit form's dropdown of markup types, which would be especially useful +if using the highlight plugin to support programming languages. The default +should probably be txt, not mdwn, if the txt plugin is enabled. + +(There's a lot of overlap between that and editpage of course .. similar +to the overlap between the comment form and editpage.) + +When posted, the form would just come up with a new, numeric subpage +of the page it appears on, and save the paste there. + +Another thing that might be useful is a "copy" (or "paste as new") action +on the action bar. This would take an existing paste and copy it into the +paste edit form, for editing and saving under a new id. + +--- + +A sample wiki configuration using this might be: + +* enable highlight and txt +* enable anonok so anyone can paste; lock anonymous users down to only + creating new pastes, not editing other pages +* disable modification of existing pastes (how? disabling editpage would + work, but that would disallow setting up anonymous git push) +* enable comments, so that each paste can be commented on +* enable getsource, so the source to a paste can easily be downloaded +* optionally, enable untrusted git push -- cgit v1.2.3 From da1d046f61a51c9a2bb00f96d510f953fe73db9f Mon Sep 17 00:00:00 2001 From: lnussel Date: Thu, 13 Aug 2009 11:07:59 -0400 Subject: yes please --- doc/todo/Configurable_minimum_length_of_log_message_for_web_edits.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Configurable_minimum_length_of_log_message_for_web_edits.mdwn b/doc/todo/Configurable_minimum_length_of_log_message_for_web_edits.mdwn index 7870281ae..74a4fb1b1 100644 --- a/doc/todo/Configurable_minimum_length_of_log_message_for_web_edits.mdwn +++ b/doc/todo/Configurable_minimum_length_of_log_message_for_web_edits.mdwn @@ -1,3 +1,5 @@ It would be nice to specify a minimum length for the change log for web edits, and if it's only required vs. non-required. I realise this is not going to solve the problem of crap log messages, but it helps guard against accidental submissions which one would have logged. Mediawiki/wikipedia has that option, and I find it a useful reminder. --[[madduck]] +> +1 --[[lnussel]] + [[!tag wishlist]] -- cgit v1.2.3 From 1c2bdf835217f7424383e881380ec51f2bff2dff Mon Sep 17 00:00:00 2001 From: lnussel Date: Thu, 13 Aug 2009 11:45:38 -0400 Subject: add comment about automenu plugin --- doc/todo/a_navbar_based_on_page_properties.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/a_navbar_based_on_page_properties.mdwn b/doc/todo/a_navbar_based_on_page_properties.mdwn index 09be409ac..091e0a39b 100644 --- a/doc/todo/a_navbar_based_on_page_properties.mdwn +++ b/doc/todo/a_navbar_based_on_page_properties.mdwn @@ -38,4 +38,11 @@ well. There is a problem though if this navbar were included in a sidebar (the logical place): if a page is updated, the navbar needs to be rebuilt which causes the sidebar to be rebuilt, which causes the whole site to be rebuilt. Unless we can subscribe only to title changes, this will be pretty bad... --[[madduck]] + +> I've just written a plugin for a automatically created menu for use +> [here](http://www.ff-egersdorf-wachendorf.de/). The source is at +> [gitorious](http://gitorious.org/ikiwiki-plugins/automenu). The problem with +> rebuilding remains unsolved but doesn't matter that much for me as I always +> generate the web site myself, ie it's not really a wiki. --[[lnussel]] + [[!tag wishlist]] -- cgit v1.2.3 From c258160725a79953f28f799b31959b73e4beac77 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 15 Aug 2009 13:59:04 -0400 Subject: review of ready branch --- debian/changelog | 1 + doc/todo/should_optimise_pagespecs.mdwn | 29 +++++++++++++++++++++++++++++ 2 files changed, 30 insertions(+) (limited to 'doc/todo') diff --git a/debian/changelog b/debian/changelog index 147d279bb..5bef06aec 100644 --- a/debian/changelog +++ b/debian/changelog @@ -7,6 +7,7 @@ ikiwiki (3.141593) UNRELEASED; urgency=low * Add discussionpage configuration setting. * Several optimisations, including speedups to orphans and brokenlinks calculation. + * meta, img: Fix bugs in dependency code. (smcv) -- Joey Hess Wed, 12 Aug 2009 12:25:30 -0400 diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 3ccef62fe..1919e3584 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -105,4 +105,33 @@ I can think about reducung the size of my wiki source and making it available on >>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support >>>>> future features like [[tracking_bugs_with_dependencies]]). --[[smcv]] +--- + +Some questions on your optimize-depends branch. --[[Joey]] + +In saveindex it still or'd together the depends list, but the `{depends}` +field seems only useful for backwards compatability (ie, ikiwiki-transition +uses it still), and otherwise just bloats the index. + +Is an array the right data structure? `add_depends` has to loop through the +array to avoid dups, it would be better if a hash were used there. Since +inline (and other plugins) explicitly add all linked pages, each as a +separate item, the list can get rather long, and that single add_depends +loop has suddenly become O(N^2) to the number of pages, which is something +to avoid.. + +Also, since a lot of places are calling add_depends in a loop, it probably +makes sense to just make it accept a list of dependencies to add. It'll be +marginally faster, probably, and should allow for better optimisation +when adding a lot of depends at once. + +In Render.pm, we now have a triply nested loop, which is a bit +scary for efficiency. It seems there should be a way to +rework this code so it can use the optimised `pagespec_match_list`, +and/or hoist some of the inner loop calculations (like the `pagename`) +out. + +Very good catch on img/meta using the wrong dependency; verified in the wild! +(I've cherry-picked those bug fixes.) + [[!tag wishlist patch patch/core]] -- cgit v1.2.3 From bd34fcd87464708afc81dd3a4d3e07e3531e7f71 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 15 Aug 2009 14:26:07 -0400 Subject: reorg and cleanup --- doc/todo/l10n.mdwn | 61 ++++++++++++++---------------------------------------- 1 file changed, 16 insertions(+), 45 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/l10n.mdwn b/doc/todo/l10n.mdwn index bba103494..fed3f63b6 100644 --- a/doc/todo/l10n.mdwn +++ b/doc/todo/l10n.mdwn @@ -1,3 +1,19 @@ +ikiwiki should be fully internationalized. + +---- + +As to the hardcoded strings in ikiwiki, I've internationalized the program, +and there is a po/ikiwiki.pot in the source that can be translated. +--[[Joey]] + +---- + +> The now merged po plugin handles l10n of wiki pages. The only missing +> piece now is l10n of the templates. +> --[[Joey]] + +---- + From [[Recai]]: > Here is my initial work on ikiwiki l10n infrastructure (I'm sending it > before finalizing, there may be errors). @@ -54,48 +70,3 @@ kullanıcının ait IP adresi: [2] This could be easily worked around in tmpl_process3, but I wouldn't like to maintain a separate utility. ----- - -As to the hardcoded strings in ikiwiki, I've internationalized the program, -and there is a po/ikiwiki.pot in the source that can be translated. ---[[Joey]] - ----- - -Danish l10n of templates and basewiki is available with the following commands: - - git clone http://source.jones.dk/ikiwiki.git newsite - cd newsite - make - -Updates are retrieved with this single command: - - make - -l10n is maintained using po4a for basewiki, smiley and templates - please send me PO files if you -translate to other languagess than the few I know about myself: - -As upstream ikiwiki is now maintained in GIT too, keeping the master mirror in sync with upstream -could probably be automated even more - but an obstacle seems to be that content is not maintained -separately but as an integral part of upstream source (GIT seems to not support subscribing to -only parts of a repository). - -For example use, here's how to roll out a clone of the [Redpill support site](http://support.redpill.dk/): - - mkdir -p ~/public_cgi/support.redpill.dk - git clone git://source.jones.dk/bin - bin/localikiwikicreatesite -o git://source.redpill.dk/support rpdemo - -(Redpill support is inspired by but needs to be reusable for several similarly configured networks) - ---[[JonasSmedegaard]] - -> I don't understand at all why you're using git the way you are. -> -> I think that this needs to be reworked into a patch against the regular -> ikiwiki tree, that adds the po4a stuff needed to generate the pot files for the -> basewiki and template content, as well as the stuff that generates the -> translated versions of those from the po files. -> -> The now merged po plugin also handles some of this. -> --[[Joey]] -- cgit v1.2.3 From d3ec1a3af2f9a2265336ba376f3ee7b75bb6e534 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Sun, 16 Aug 2009 09:01:12 -0400 Subject: comment on part of Joey's comment --- doc/todo/should_optimise_pagespecs.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 1919e3584..9d2611249 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -120,6 +120,14 @@ separate item, the list can get rather long, and that single add_depends loop has suddenly become O(N^2) to the number of pages, which is something to avoid.. +> I was also thinking about this (I've been playing with some stuff based on the +> `remove-pagespec-merge` branch). A hash, by itself, is not optimal because +> the dependency list holds two things: page names and page specs. The hash would +> work well for the page names, but you'll still need to iterate through the page specs. +> I was thinking of keeping a list and a hash. You use the list for pagespecs +> and the hash for individual page names. To make this work you need to adjust the +> API so it knows which you're adding. -- [[Will]] + Also, since a lot of places are calling add_depends in a loop, it probably makes sense to just make it accept a list of dependencies to add. It'll be marginally faster, probably, and should allow for better optimisation -- cgit v1.2.3 From 611256ba1c6f9b5cfdaabed634a1be00eb32e7a7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 16 Aug 2009 16:32:35 -0400 Subject: clarification --- doc/todo/should_optimise_pagespecs.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 9d2611249..33bca677a 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -128,6 +128,9 @@ to avoid.. > and the hash for individual page names. To make this work you need to adjust the > API so it knows which you're adding. -- [[Will]] +> I wasn't thinking about a lookup hash, just a dedup hash, FWIW. +> --[[Joey]] + Also, since a lot of places are calling add_depends in a loop, it probably makes sense to just make it accept a list of dependencies to add. It'll be marginally faster, probably, and should allow for better optimisation -- cgit v1.2.3 From 89b5e2b8224a6e05e8f2a7d2d0affe7ae700fa97 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Mon, 17 Aug 2009 16:15:41 -0400 Subject: responses to code review (I'll try to get them implemented later this week) --- doc/todo/should_optimise_pagespecs.mdwn | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 33bca677a..0a3720b3c 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -113,6 +113,13 @@ In saveindex it still or'd together the depends list, but the `{depends}` field seems only useful for backwards compatability (ie, ikiwiki-transition uses it still), and otherwise just bloats the index. +> If it's acceptable to declare that downgrading IkiWiki requires a complete +> rebuild, I'm happy with that. I'd prefer to keep the (simple form of the) +> transition done automatically during a load/save cycle, rather than +> requiring ikiwiki-transition to be run; we should probably say in NEWS +> that the performance increase won't fully apply until the next +> rebuild. --[[smcv]] + Is an array the right data structure? `add_depends` has to loop through the array to avoid dups, it would be better if a hash were used there. Since inline (and other plugins) explicitly add all linked pages, each as a @@ -131,17 +138,31 @@ to avoid.. > I wasn't thinking about a lookup hash, just a dedup hash, FWIW. > --[[Joey]] +>> I was under the impression from previous code review that you preferred +>> to represent unordered sets as lists, rather than hashes with dummy +>> values. If I was wrong, great, I'll fix that and it'll probably go +>> a bit faster. --[[smcv]] + Also, since a lot of places are calling add_depends in a loop, it probably makes sense to just make it accept a list of dependencies to add. It'll be marginally faster, probably, and should allow for better optimisation when adding a lot of depends at once. +> That'd be an API change; perhaps marginally faster, but I don't +> see how it would allow better optimisation if we're de-duplicating +> anyway? --[[smcv]] + In Render.pm, we now have a triply nested loop, which is a bit scary for efficiency. It seems there should be a way to rework this code so it can use the optimised `pagespec_match_list`, and/or hoist some of the inner loop calculations (like the `pagename`) out. +> I don't think the complexity is any greater than it was: I've just +> moved one level of "loop" out of the generated Perl, to be +> in visible code. I'll see whether some of it can be hoisted, though. +> --[[smcv]] + Very good catch on img/meta using the wrong dependency; verified in the wild! (I've cherry-picked those bug fixes.) -- cgit v1.2.3 From 46adbbd1c377b6c4a55c466e27de0bdce2fcb52c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 17 Aug 2009 16:30:21 -0400 Subject: respond --- doc/todo/should_optimise_pagespecs.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 0a3720b3c..1594dcee7 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -120,6 +120,11 @@ uses it still), and otherwise just bloats the index. > that the performance increase won't fully apply until the next > rebuild. --[[smcv]] +>> It is acceptable not to support downgrades. +>> I don't think we need a NEWS file update since any sort of refresh, +>> not just a full rebuild, will cause the indexdb to be loaded and saved, +>> enabling the optimisation. --[[Joey]] + Is an array the right data structure? `add_depends` has to loop through the array to avoid dups, it would be better if a hash were used there. Since inline (and other plugins) explicitly add all linked pages, each as a @@ -143,6 +148,9 @@ to avoid.. >> values. If I was wrong, great, I'll fix that and it'll probably go >> a bit faster. --[[smcv]] +>>> It depends, really. And it'd certianly make sense to benchmark such a +>>> change. --[[Joey]] + Also, since a lot of places are calling add_depends in a loop, it probably makes sense to just make it accept a list of dependencies to add. It'll be marginally faster, probably, and should allow for better optimisation @@ -152,6 +160,11 @@ when adding a lot of depends at once. > see how it would allow better optimisation if we're de-duplicating > anyway? --[[smcv]] +>> Well, I was thinking that it might be sufficient to build a `%seen` +>> hash of dependencies inside `add_depends`, if the places that call +>> it lots were changed to just call it once. Of course the only way to +>> tell is benchmarking. --[[Joey]] + In Render.pm, we now have a triply nested loop, which is a bit scary for efficiency. It seems there should be a way to rework this code so it can use the optimised `pagespec_match_list`, @@ -163,6 +176,10 @@ out. > in visible code. I'll see whether some of it can be hoisted, though. > --[[smcv]] +>> The call to `pagename` is the only part I can see that's clearly +>> run more often than before. That function is pretty inexpensive, but.. +>> --[[Joey]] + Very good catch on img/meta using the wrong dependency; verified in the wild! (I've cherry-picked those bug fixes.) -- cgit v1.2.3 From 68b6926420172f69a05bccbdbe7776755cd92a27 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 24 Aug 2009 15:51:05 -0400 Subject: fixed via getsource plugin --- doc/todo/Raw_view_link.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Raw_view_link.mdwn b/doc/todo/Raw_view_link.mdwn index fd64074c2..b62a9022b 100644 --- a/doc/todo/Raw_view_link.mdwn +++ b/doc/todo/Raw_view_link.mdwn @@ -4,7 +4,7 @@ The configuration setting for Mercurial could be something like this: rawurl => "http://localhost:8000//raw-file/tip/\[[file]]", -> What I want to do when I want to see if the raw source is either +> What I do when I want to see if the raw source is either > click on the edit link, or click on history and navigate to it in the > history browser (easier to do in viewvc than in gitweb, IIRC). > Not that I'm opposed to the idea of a plugin that adds a Raw link @@ -14,4 +14,6 @@ The configuration setting for Mercurial could be something like this: >> to gitweb/etc. I think Will's patch is a good approach, and have improved >> on it a bit in a git branch. +>>> Since that is merged in now, I'm marking this [[done]] --[[Joey]] + [[!tag wishlist]] -- cgit v1.2.3 From 6b97e8f0ee74bb2f3189f669deefe0a227b0fc6f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 24 Aug 2009 15:52:56 -0400 Subject: close as wontfix --- doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn b/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn index 0fb14bafe..4489dd5d2 100644 --- a/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn +++ b/doc/todo/Suggested_location_should_be_subpage_if_siblings_exist.mdwn @@ -23,4 +23,4 @@ that we're at the root of a (sub-)hierarchy. >> This sounds like WONTFIX to me? --[[smcv]] -[[!tag wishlist]] +[[!tag wishlist done]] -- cgit v1.2.3 From bc6e50a075b164100d3144a13633647613a3dc8e Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Sat, 1 Aug 2009 12:43:04 +0100 Subject: Mark "should optimise pagespecs" as done --- doc/todo/should_optimise_pagespecs.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 1594dcee7..5ed24d333 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -90,6 +90,8 @@ I can think about reducung the size of my wiki source and making it available on >> rather than a single pagespec. This does turn out to be faster, although >> not as much as I'd like. --[[smcv]] +>>> [[Merged|done]] --[[smcv]] + >>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]] >>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`). -- cgit v1.2.3 From 848bb66c37b94b633a378e186e561aebb7bab43a Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Sat, 1 Aug 2009 12:43:37 +0100 Subject: Indicate that pagespec_merge() is no longer needed (much rejoicing?) --- doc/todo/tracking_bugs_with_dependencies.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index a198530fc..bfdbf0875 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -410,8 +410,8 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>>>> then the last definition (baz) takes precedence. >>>>> In the process of writing this I think I've come up with a way to change this back the way it was, still using closures. -- [[Will]] ->>> Alternatively, my [[remove-pagespec-merge|should_optimise_pagespecs]] ->>> branch solves this, in a Gordian knot sort of way :-) --[[smcv]] +>>> My [[remove-pagespec-merge|should_optimise_pagespecs]] branch has now +>>> solved all this by deleting the offending function :-) --[[smcv]] >> Secondly, it seems that there are two types of dependency, and ikiwiki >> currently only handles one of them. The first type is "Rebuild this -- cgit v1.2.3 From 68fd245addb9b96b473949349440b86796955cce Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 25 Aug 2009 00:45:28 +0100 Subject: Respond with benchmarks and an updated branch --- doc/todo/should_optimise_pagespecs.mdwn | 79 +++++++++++++++++++++++++++++++-- 1 file changed, 76 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 1594dcee7..3dfa8e1f2 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -123,7 +123,12 @@ uses it still), and otherwise just bloats the index. >> It is acceptable not to support downgrades. >> I don't think we need a NEWS file update since any sort of refresh, >> not just a full rebuild, will cause the indexdb to be loaded and saved, ->> enabling the optimisation. --[[Joey]] +>> enabling the optimisation. --[[Joey]] + +>>> A refresh will load the current dependencies from `{depends}` and save +>>> them as-is as a one-element `{dependslist}`; only a rebuild will replace +>>> the single complex pagespec with a long list of simpler pagespecs. +>>> --[[smcv]] Is an array the right data structure? `add_depends` has to loop through the array to avoid dups, it would be better if a hash were used there. Since @@ -149,7 +154,9 @@ to avoid.. >> a bit faster. --[[smcv]] >>> It depends, really. And it'd certianly make sense to benchmark such a ->>> change. --[[Joey]] +>>> change. --[[Joey]] + +>>>> Benchmarked, below. --[[smcv]] Also, since a lot of places are calling add_depends in a loop, it probably makes sense to just make it accept a list of dependencies to add. It'll be @@ -163,7 +170,10 @@ when adding a lot of depends at once. >> Well, I was thinking that it might be sufficient to build a `%seen` >> hash of dependencies inside `add_depends`, if the places that call >> it lots were changed to just call it once. Of course the only way to ->> tell is benchmarking. --[[Joey]] +>> tell is benchmarking. --[[Joey]] + +>>> It doesn't seem that it significantly affects performance either way. +>>> --[[smcv]] In Render.pm, we now have a triply nested loop, which is a bit scary for efficiency. It seems there should be a way to @@ -180,7 +190,70 @@ out. >> run more often than before. That function is pretty inexpensive, but.. >> --[[Joey]] +>>> I don't see anything that can be hoisted without significant refactoring, +>>> actually. Beware that there are two pagename calls in the loop: one for +>>> `$f` (which is the page we might want to rebuild), and one for `$file` +>>> (which is the changed page that it might depend on). Note that I didn't +>>> choose those names! +>>> +>>> The three loops are over source files, their lists of dependency pagespecs, +>>> and files that might have changed. I see the following things we might be +>>> doing redundantly: +>>> +>>> * If `$file` is considered as a potential dependency for more than +>>> one `$f`, we evaluate `pagename($file)` more than once. Potential fix: +>>> cache them (this turns out to save about half a second on the docwiki, +>>> see below). +>>> * If several pages depend on the same pagespec, we evaluate whether each +>>> changed page matches that pagespec more than once: however, we do so +>>> with a different location parameter every time, so repeated calls are, +>>> in the general case, the only correct thing to do. Potential fix: +>>> perhaps special-case "page x depends on page y and nothing else" +>>> (i.e. globs that have no wildcards) into a separate hash? I haven't +>>> done anything in this direction. +>>> * Any preparatory work done by pagespec_match (converting the pagespec +>>> into Perl, mostly?) is done in the inner loop; switching to +>>> pagespec_match_list (significant refactoring) saves more than half a +>>> second on the docwiki. +>>> +>>> --[[smcv]] + Very good catch on img/meta using the wrong dependency; verified in the wild! (I've cherry-picked those bug fixes.) +---- + +Benchmarking results: I benchmarked by altering docwiki.setup to switch off +verbose, running "make clean && ./Makefile.PL && make", and timing one rebuild +of the docwiki followed by three refreshes. Before each refresh I used +`touch plugins/*.mdwn` to have something significant to refresh. + +I'm assuming that "user" CPU time is the important thing here (system time was +relatively small in all cases, up to 0.35 seconds per run). + +master at the time of rebasing: 14.20s to rebuild, 10.04/12.07/14.01s to +refresh. I think you can see the bug clearly here - the pagespecs are getting +more complicated every time! + +After the initial optimization: 14.27s to rebuild, 8.26/8.33/8.26 to refresh. +Success! + +Not pre-joining dependencies actually took about ~0.2s more; I don't know why. +I'm worried that duplicates will just build up (again) in less simple cases, +though, so 0.2s is probably a small price to pay for that not happening (it +might well be experimental error, for that matter). + +Not saving {depends} to the index, using a hash instead of a list to +de-duplicate, and allowing add_depends to take an arrayref instead of a single +pagespec had no noticable positive or negative effect on this test. + +Memoizing the results of pagename brought the rebuild time down to 14.06s +and the refresh time down to 7.96/7.92/7.92, a significant win. + +Refactoring to use pagespec_match_list looks more risky from a code churn +point of view; rebuild now takes 14.35s, but refresh is only 7.30/7.29/7.28, +another significant win. + +--[[smcv]] + [[!tag wishlist patch patch/core]] -- cgit v1.2.3 From 96936899da3037fa28f8be73003a14aa829878ee Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 24 Aug 2009 21:54:22 -0400 Subject: at this point I'm down to deciding which specific commits to merge and which were dead ends --- doc/todo/should_optimise_pagespecs.mdwn | 42 +++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 3dfa8e1f2..f3048f328 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -235,6 +235,21 @@ master at the time of rebasing: 14.20s to rebuild, 10.04/12.07/14.01s to refresh. I think you can see the bug clearly here - the pagespecs are getting more complicated every time! +> I can totally see a bug here, and it's one I didn't think existed. Ie, +> I thought that after the first refresh, the pagespec should stabalize, +> and what it stabalized to was probably unnecessarily long, but not +> growing w/o bounds! +> +> a) Explains why ikiwiki.info has been so slow lately. Well that and some +> other things that overloaded the system. +> b) Suggests to me we will probably want to force a rebuild on upgrade +> when fixing this (via the mechanism in the postinst). +> +> BTW, the underlying bug here is really horribly simple: +> When refreshing, `loadindex` preserves the previous depends list, +> and `add_depends` adds stuff to it. So it doubles every time a page is +> re-rendered during refresh. --[[Joey]] + After the initial optimization: 14.27s to rebuild, 8.26/8.33/8.26 to refresh. Success! @@ -243,17 +258,44 @@ I'm worried that duplicates will just build up (again) in less simple cases, though, so 0.2s is probably a small price to pay for that not happening (it might well be experimental error, for that matter). +> It's weird that the suggested optimisations to +> `add_depends` had no effect. So, the commit message to +> b6fcb1cb0ef27e5a63184440675d465fad652acf is actually wrong.. ? --[[Joey]] + Not saving {depends} to the index, using a hash instead of a list to de-duplicate, and allowing add_depends to take an arrayref instead of a single pagespec had no noticable positive or negative effect on this test. +> I see e4cd168ebedd95585290c97ff42234344bfed46c is still in your branch +> though. I don't like using an arrayref, it could just take `($page, @depends)`. +> and I don't see the need to keep it if it doesn't currently help. +> +> Is there any reason to keep 7227c2debfeef94b35f7d81f42900aa01820caa3 +> if it doesn't improve speed? +> --[[Joey]] + Memoizing the results of pagename brought the rebuild time down to 14.06s and the refresh time down to 7.96/7.92/7.92, a significant win. +> Ok, that seems safe to memoize. (It's a real function and it isn't +> called with a great many inputs.) Why did you chose to memoize it +> explicitly rather than adding it to the memoize list at the top? + Refactoring to use pagespec_match_list looks more risky from a code churn point of view; rebuild now takes 14.35s, but refresh is only 7.30/7.29/7.28, another significant win. --[[smcv]] +> I had mostly convinced myself that +> `pagespec_match_list` would not lead to a speed gain here. My reasoning +> was that you want to stop after finding one match, while `pagespec_match_list` +> checks all pages for matches. So what we're seeing is that +> on a rebuild, `@changed` is all pages, and not short-circuiting leads +> to unnecessary work. OTOH, on refresh, `@changed` is small and I suppose +> `pagespec_match_list`'s other slight efficiencies win out somehow. +> +> Welcome to the "I made ikiwiki twice as fast +> and all I got was this lousy git sha1sum" club BTW :-) --[[Joey]] + [[!tag wishlist patch patch/core]] -- cgit v1.2.3 From 134a25d1633513afd9506318aeb4349381dc061e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 24 Aug 2009 22:10:12 -0400 Subject: better analysis of why the depends keep growing --- doc/todo/should_optimise_pagespecs.mdwn | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index f3048f328..2dd1f7b9e 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -244,11 +244,13 @@ more complicated every time! > other things that overloaded the system. > b) Suggests to me we will probably want to force a rebuild on upgrade > when fixing this (via the mechanism in the postinst). -> -> BTW, the underlying bug here is really horribly simple: -> When refreshing, `loadindex` preserves the previous depends list, -> and `add_depends` adds stuff to it. So it doubles every time a page is -> re-rendered during refresh. --[[Joey]] +> +> I've investigated why the pagespecs keep growing: When page A changes, +> its old depends are cleared. Then +> page B that inlines A gets rebuilt, and its old depends are also cleared. +> But page B also inlines page C; which means C gets re-rendered. And this +> happens w/o its old depends being cleared, so C's depends are doubled. +> --[[Joey]] After the initial optimization: 14.27s to rebuild, 8.26/8.33/8.26 to refresh. Success! -- cgit v1.2.3 From aeea77e5c434bf432ea574c62e685cf655af15bd Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 25 Aug 2009 22:18:52 +0100 Subject: reply --- doc/todo/should_optimise_pagespecs.mdwn | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 2dd1f7b9e..5dd3b1e34 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -264,6 +264,9 @@ might well be experimental error, for that matter). > `add_depends` had no effect. So, the commit message to > b6fcb1cb0ef27e5a63184440675d465fad652acf is actually wrong.. ? --[[Joey]] +>> I'll try benchmarking again on the non-public wiki where I had the 4% +>> speedup. The docwiki is so small that 4% is hard to measure... --[[smcv]] + Not saving {depends} to the index, using a hash instead of a list to de-duplicate, and allowing add_depends to take an arrayref instead of a single pagespec had no noticable positive or negative effect on this test. @@ -271,11 +274,17 @@ pagespec had no noticable positive or negative effect on this test. > I see e4cd168ebedd95585290c97ff42234344bfed46c is still in your branch > though. I don't like using an arrayref, it could just take `($page, @depends)`. > and I don't see the need to keep it if it doesn't currently help. -> + +>> I'll drop it. --[[smcv]] + > Is there any reason to keep 7227c2debfeef94b35f7d81f42900aa01820caa3 > if it doesn't improve speed? > --[[Joey]] +>> I'll try benchmarking on a more complex wiki and see whether it has a +>> positive or negative effect. It does avoid being O(n**2) in number of +>> dependencies. --[[smcv]] + Memoizing the results of pagename brought the rebuild time down to 14.06s and the refresh time down to 7.96/7.92/7.92, a significant win. @@ -283,6 +292,9 @@ and the refresh time down to 7.96/7.92/7.92, a significant win. > called with a great many inputs.) Why did you chose to memoize it > explicitly rather than adding it to the memoize list at the top? +>> It does depend on global variables, so using Memoize seemed like asking for +>> trouble. I suppose what I did is equivalent to Memoize though... --[[smcv]] + Refactoring to use pagespec_match_list looks more risky from a code churn point of view; rebuild now takes 14.35s, but refresh is only 7.30/7.29/7.28, another significant win. -- cgit v1.2.3 From cc76cd64024ed09eff2a3e2da1282497e8c4e21b Mon Sep 17 00:00:00 2001 From: martin Date: Wed, 26 Aug 2009 09:59:39 -0400 Subject: suggestion --- doc/todo/tmplvars_plugin/discussion.mdwn | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc/todo/tmplvars_plugin/discussion.mdwn (limited to 'doc/todo') diff --git a/doc/todo/tmplvars_plugin/discussion.mdwn b/doc/todo/tmplvars_plugin/discussion.mdwn new file mode 100644 index 000000000..93cb9b414 --- /dev/null +++ b/doc/todo/tmplvars_plugin/discussion.mdwn @@ -0,0 +1 @@ +I find this plugin quite usefull. But one thing, I would like to be able to do is set a tmplvar e.g. in a sidebar so that it affects all Pages this sidebar is used in. --martin -- cgit v1.2.3 From dc1399fa809dc38e070a3c160b26926c27a04ddd Mon Sep 17 00:00:00 2001 From: intrigeri Date: Wed, 26 Aug 2009 21:19:55 -0400 Subject: initial patch proposal --- ...irrorlist_with_per-mirror_usedirs_settings.mdwn | 24 ++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn (limited to 'doc/todo') diff --git a/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn new file mode 100644 index 000000000..6ca9962ba --- /dev/null +++ b/doc/todo/mirrorlist_with_per-mirror_usedirs_settings.mdwn @@ -0,0 +1,24 @@ +I've got a wiki that is built at two places: + +* a static copy, aimed at being viewed without any web server, using + a web browser's `file:///` urls => usedirs is disabled to get nice + and working links +* an online copy, with usedirs enabled in order to benefit from the + language negotiation using the po plugin + +I need to use mirrorlist on the static copy, so that one can easily +reach the online, possibly updated, pages. But as documented, "pages are +assumed to exist in the same location under the specified url on each +mirror", so the generated urls are wrong. + +My `mirrorlist` branch contains a patch that allows one to configure usedirs +per-mirror. Note: the old configuration format is still supported, so this should +not break existing wikis. + +OT: as a bonus, this branch contains a patch to support {hashes,arrays} of +{hashes,arrays} in `$config`, which I missed a bit when writing the po plugin, +and decided this time it was really needed to implement this feature. + +--[[intrigeri]] + +[[!tag patch]] -- cgit v1.2.3 From 545029fe4bc11e828da193745c7555c1e8322768 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 28 Aug 2009 01:13:43 +0100 Subject: Explain my depends-exact branch --- doc/todo/optimize_simple_dependencies.mdwn | 48 ++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 doc/todo/optimize_simple_dependencies.mdwn (limited to 'doc/todo') diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn new file mode 100644 index 000000000..c3ccd5ad0 --- /dev/null +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -0,0 +1,48 @@ +[[!template id=gitbranch branch=smcv/ready/depends-exact author="[[smcv]]"]] + +I'm still trying to optimize ikiwiki for a site using +[[plugins/contrib/album]], and checking which pages depend on which pages +is still taking too long. Here's another go at fixing that, using [[Will]]'s +suggestion from [[todo/should_optimise_pagespecs]]: + +> A hash, by itself, is not optimal because +> the dependency list holds two things: page names and page specs. The hash would +> work well for the page names, but you'll still need to iterate through the page specs. +> I was thinking of keeping a list and a hash. You use the list for pagespecs +> and the hash for individual page names. To make this work you need to adjust the +> API so it knows which you're adding. -- [[Will]] + +If you have P pages and refresh after changing C of them, where an average +page has E dependencies on exact page names and D other dependencies, this +branch should drop the complexity of checking dependencies from +O(P * (D+E) * C) to O(C + P*E + P*D*C). Pages that use inline or map have +a large value for E (e.g. one per inlined page) and a small value for D (e.g. +one per inline). + +Benchmarking: + +Test 1: a wiki with about 3500 pages and 3500 photos, and a change that +touches about 350 pages and 350 photos + +Test 2: the docwiki (about 700 objects not excluded by docwiki.setup, mostly +pages), docwiki.setup modified to turn off verbose, and a change that touches +the 98 pages of plugins/*.mdwn + +In both tests I rebuilt the wiki with the target ikiwiki version, then touched +the appropriate pages and refreshed. + +Results of test 1: without this branch it took around 5:45 to rebuild and +around 5:45 again to refresh (so rebuilding 10% of the pages, then deciding +that most of the remaining 90% didn't need to change, took about as long as +rebuilding everything). With this branch it took 5:47 to rebuild and 1:16 +to refresh. + +Results of test 2: rebuilding took 14.11s without, 13.96s with; refreshing +three times took 7.29/7.40/7.37s without, 6.62/6.56/6.63s with. + +(This benchmarking was actually done with my [[plugins/contrib/album]] branch, +since that's what the huge wiki needs; that branch doesn't alter core code +beyond the ready/depends-exact branch point, so the results should be +equally valid.) + +--[[smcv]] -- cgit v1.2.3 From b7a3fbec78a7584f24b8dcc38e5e9537ad95c7f5 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 27 Aug 2009 21:36:55 -0400 Subject: response --- doc/todo/optimize_simple_dependencies.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn index c3ccd5ad0..44163311b 100644 --- a/doc/todo/optimize_simple_dependencies.mdwn +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -46,3 +46,23 @@ beyond the ready/depends-exact branch point, so the results should be equally valid.) --[[smcv]] + +> We discussed this on irc; I had some worries that things may have been +> switched to `add_depends_exact` that were not pure page names. My current +> feeling is it's all safe, but who knows. It's easy to miss something. +> Which makes me think this is not a good interface. +> +> Why not, instead, make `add_depends` smart. If it's passed something +> that is clearly a raw page name, it can add it to the exact depends hash. +> Else, add it to the pagespec hash. You can tell if it's a pure page name +> by matching on `$config{wiki_file_regexp}`. +> +> Also I think there may be little optimisation value left in +> 7227c2debfeef94b35f7d81f42900aa01820caa3, since the "regular" dependency +> lists will be much shorter. +> +> Sounds like inline pagenames has an already exstant bug WRT +> pages moving, which this should not make worse. Would be good to verify. +> +> Re coding, it would be nice if `refresh()` could avoid duplicating +> the debug message, etc in the two cases. --[[Joey]] -- cgit v1.2.3 From 3f303cc853426a1ddb8e36b8fb544a69bced3721 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Fri, 28 Aug 2009 15:25:05 +0200 Subject: follow-up Signed-off-by: intrigeri --- .../language_definition_for_the_meta_plugin.mdwn | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/language_definition_for_the_meta_plugin.mdwn b/doc/todo/language_definition_for_the_meta_plugin.mdwn index 90bfbef3b..44fcf32bb 100644 --- a/doc/todo/language_definition_for_the_meta_plugin.mdwn +++ b/doc/todo/language_definition_for_the_meta_plugin.mdwn @@ -95,7 +95,24 @@ This may be useful for sites with a few pages in different languages, but no ful >>> Now that po has been merged, this patch should probably also be adapted >>> so that the po plugin forces the meta::lang of every page to what po ->>> thinks it should be. Perhaps [[the_special_po_pagespecs|ikiwiki/pagespec/po]] ->>> should also work with meta-assigned languages? --[[smcv]] +>>> thinks it should be. --[[smcv]] + +>>>> Agreed, users of the po plugin would greatly benefit from it. +>>>> Seems doable. --[[intrigeri]] + +>>> Perhaps [[the_special_po_pagespecs|ikiwiki/pagespec/po]] should +>>> also work with meta-assigned languages? --[[smcv]] + +>>>> Yes. But then, these special pagespecs should be moved outside of +>>>> [[plugins/po]], as they could be useful to anyone using the +>>>> currently discussed patch even when not using the po plugin. +>>>> +>>>> We could add these pagespecs to the core and make them use +>>>> a simple language-guessing system based on a new hook. Any plugin +>>>> that implements such a hook could decide whether it should +>>>> overrides the language guessed by another one, and optionally use +>>>> the `first`/`last` options (e.g. the po plugin will want to be +>>>> authoritative on the pages of type po, and will then use +>>>> `last`). --[[intrigeri]] [[!tag wishlist patch plugins/meta translation]] -- cgit v1.2.3 From de4dc8befe7ede3cd34daf3f2bce5dd6305599f0 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 28 Aug 2009 15:48:51 +0100 Subject: Updated branch, thanks for the feedback --- doc/todo/optimize_simple_dependencies.mdwn | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn index 44163311b..10c6c7272 100644 --- a/doc/todo/optimize_simple_dependencies.mdwn +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -56,13 +56,33 @@ equally valid.) > that is clearly a raw page name, it can add it to the exact depends hash. > Else, add it to the pagespec hash. You can tell if it's a pure page name > by matching on `$config{wiki_file_regexp}`. -> + +>> Good thinking. Done in commit 68ce514a 'Auto-detect "simple dependencies"', +>> with a related bugfix in e8b43825 "Force %depends_exact to lower case". +>> +>> Performance impact: Test 2 above takes 0.2s longer to rebuild (probably +>> from all the calls to lc, which are, however, necessary for correctness) +>> and has indistinguishable performance for a refresh. --[[smcv]] + > Also I think there may be little optimisation value left in > 7227c2debfeef94b35f7d81f42900aa01820caa3, since the "regular" dependency > lists will be much shorter. -> + +>> You're probably right, but IMO it's not worth reverting it - a set (hash with +>> dummy values) is still the right data structure. --[[smcv]] + > Sounds like inline pagenames has an already exstant bug WRT > pages moving, which this should not make worse. Would be good to verify. -> + +>> If you mean the standard "add a better match for a link-like construct" bug +>> that also affects sidebar, then yes, it does have the bug, but I'm pretty +>> sure this branch doesn't make it any worse. I could solve this at the cost +>> of making pagenames less useful for interactive use, by making it not +>> respect [[ikiwiki/subpage/LinkingRules]], but instead always interpret +>> its paths as relative to the top of the wiki - that's actually all that +>> [[plugins/contrib/album]] needs. --[[smcv]] + > Re coding, it would be nice if `refresh()` could avoid duplicating -> the debug message, etc in the two cases. --[[Joey]] +> the debug message, etc in the two cases. --[[Joey]] + +>> Fixed in commit f805d566 "Avoid duplicating debug message..." --[[smcv]] -- cgit v1.2.3 From 54b3d55aadf9c6ee2b4b3aa68b3a1794a9394fd4 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 28 Aug 2009 15:50:02 +0100 Subject: Mark as done --- doc/todo/optimize_simple_dependencies.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn index 44163311b..50ecafa05 100644 --- a/doc/todo/optimize_simple_dependencies.mdwn +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -47,6 +47,10 @@ equally valid.) --[[smcv]] +> Now [[merged|done]] --[[smcv]] + +---- + > We discussed this on irc; I had some worries that things may have been > switched to `add_depends_exact` that were not pure page names. My current > feeling is it's all safe, but who knows. It's easy to miss something. -- cgit v1.2.3 From 54f94e6bc88415990db5b5095b6a52890797f6f7 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Fri, 28 Aug 2009 16:11:52 +0100 Subject: Some crude benchmarking on a larger wiki --- doc/todo/optimize_simple_dependencies.mdwn | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn index 10c6c7272..da75ff177 100644 --- a/doc/todo/optimize_simple_dependencies.mdwn +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -62,7 +62,12 @@ equally valid.) >> >> Performance impact: Test 2 above takes 0.2s longer to rebuild (probably >> from all the calls to lc, which are, however, necessary for correctness) ->> and has indistinguishable performance for a refresh. --[[smcv]] +>> and has indistinguishable performance for a refresh. +>> +>> Test 1 took about 6 minutes to rebuild and 1:25 to refresh; those are +>> pessimistic figures, since I've added 90 more photos and 90 more pages +>> (both to the wiki as a whole, and the number touched before refreshing) +>> since testing the previous version of this branch. --[[smcv]] > Also I think there may be little optimisation value left in > 7227c2debfeef94b35f7d81f42900aa01820caa3, since the "regular" dependency -- cgit v1.2.3 From 79d3bb16ea54520cffbb4e120b1a87a3b2967cb4 Mon Sep 17 00:00:00 2001 From: "http://emptty.myopenid.com/" Date: Fri, 28 Aug 2009 12:18:30 -0400 Subject: my first edit to this site, please forgive mistakes --- doc/todo/Restrict_page_viewing.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 doc/todo/Restrict_page_viewing.mdwn (limited to 'doc/todo') diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn new file mode 100644 index 000000000..b25b7de0a --- /dev/null +++ b/doc/todo/Restrict_page_viewing.mdwn @@ -0,0 +1,11 @@ +I'd like to have some pages of my wiki to be only viewable by some users. + +I could use htaccess for that, but it would force the users to have 2 authentication mecanisms, so I'd prefer to use openID for that too. + +* I'm thinking of adding a "show" parameter to the cgi script, thanks to a plugin similar to goto. +* When called, it would check the credential using the session stuff (that I don't understand yet). If not enough, it would serve a 403 error of course. +* If enough, it would read the file locally on the server side and return this as a content. + +Then, I'd have to generate the private page the regular way with ikiwiki, and prevent apache from serving them with an appropriate and much more maintainable htaccess file. + +-- [[users/emptty]] -- cgit v1.2.3 From 4236eb5f688944d70c19427e1150285238ce61ce Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 28 Aug 2009 15:00:58 -0400 Subject: response --- doc/todo/Restrict_page_viewing.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn index b25b7de0a..ec7b05a51 100644 --- a/doc/todo/Restrict_page_viewing.mdwn +++ b/doc/todo/Restrict_page_viewing.mdwn @@ -9,3 +9,7 @@ I could use htaccess for that, but it would force the users to have 2 authentica Then, I'd have to generate the private page the regular way with ikiwiki, and prevent apache from serving them with an appropriate and much more maintainable htaccess file. -- [[users/emptty]] + +> While I'm sure a plugin could do this, it adds so much scalability cost +> and is so counter to ikiwiki's design.. Have you considered using the +> [[plugins/httpauth]] plugin to unify around htaccess auth? --[[Joey]] -- cgit v1.2.3 From a4c9a8461cc85377f8c88a62f2f980a0c7e2a042 Mon Sep 17 00:00:00 2001 From: "http://emptty.myopenid.com/" Date: Sat, 29 Aug 2009 04:28:01 -0400 Subject: Answer to Joey, and justify my text (in the source) --- doc/todo/Restrict_page_viewing.mdwn | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn index ec7b05a51..0b2a65a66 100644 --- a/doc/todo/Restrict_page_viewing.mdwn +++ b/doc/todo/Restrict_page_viewing.mdwn @@ -1,15 +1,27 @@ I'd like to have some pages of my wiki to be only viewable by some users. -I could use htaccess for that, but it would force the users to have 2 authentication mecanisms, so I'd prefer to use openID for that too. +I could use htaccess for that, but it would force the users to have +2 authentication mecanisms, so I'd prefer to use openID for that too. -* I'm thinking of adding a "show" parameter to the cgi script, thanks to a plugin similar to goto. -* When called, it would check the credential using the session stuff (that I don't understand yet). If not enough, it would serve a 403 error of course. -* If enough, it would read the file locally on the server side and return this as a content. +* I'm thinking of adding a "show" parameter to the cgi script, thanks + to a plugin similar to goto. +* When called, it would check the credential using the session stuff + (that I don't understand yet). +* If not enough, it would serve a 403 error of course. +* If enough, it would read the file locally on the server side and + return this as a content. -Then, I'd have to generate the private page the regular way with ikiwiki, and prevent apache from serving them with an appropriate and much more maintainable htaccess file. +Then, I'd have to generate the private page the regular way with ikiwiki, +and prevent apache from serving them with an appropriate and +much more maintainable htaccess file. -- [[users/emptty]] > While I'm sure a plugin could do this, it adds so much scalability cost > and is so counter to ikiwiki's design.. Have you considered using the > [[plugins/httpauth]] plugin to unify around htaccess auth? --[[Joey]] + +>> I'm not speaking of rendering the pages on demand, but to serve them on demand. +>> They would still be compiled the regular way; +>> I'll have another look at [[plugins/httpauth]] but I really like the openID whole idea. +>> --[[emptty]] -- cgit v1.2.3 From 517432273b96fc9e6bad9b7667ef6d1b04c699ee Mon Sep 17 00:00:00 2001 From: "http://schmonz.livejournal.com/" Date: Sat, 29 Aug 2009 10:47:45 -0400 Subject: mod_auth_openid --- doc/todo/Restrict_page_viewing.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn index 0b2a65a66..089d27fff 100644 --- a/doc/todo/Restrict_page_viewing.mdwn +++ b/doc/todo/Restrict_page_viewing.mdwn @@ -25,3 +25,12 @@ much more maintainable htaccess file. >> They would still be compiled the regular way; >> I'll have another look at [[plugins/httpauth]] but I really like the openID whole idea. >> --[[emptty]] + +>>> How about +>>> [mod_auth_openid](http://trac.butterfat.net/public/mod_auth_openid), then? +>>> A plugin for ikiwiki to serve its own pages is far afield from ikiwiki's roots, +>>> as Joey pointed out, but might be a neat option to have anyway -- for unifying +>>> authentication across views and edits, for systems not otherwise running +>>> web servers, for systems with web servers you don't have access to, and +>>> doubtless for other purposes. Such a plugin would add quite a bit of flexibility, +>>> and in that sense (IMO, of course) it'd be in the spirit of ikiwiki. --[[schmonz]] -- cgit v1.2.3 From b83cb1d9f5ad1bc3eab332a75ecd958d63610ce9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 30 Aug 2009 14:54:52 -0400 Subject: note --- doc/todo/Restrict_page_viewing.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Restrict_page_viewing.mdwn b/doc/todo/Restrict_page_viewing.mdwn index 089d27fff..9c1889d63 100644 --- a/doc/todo/Restrict_page_viewing.mdwn +++ b/doc/todo/Restrict_page_viewing.mdwn @@ -34,3 +34,6 @@ much more maintainable htaccess file. >>> web servers, for systems with web servers you don't have access to, and >>> doubtless for other purposes. Such a plugin would add quite a bit of flexibility, >>> and in that sense (IMO, of course) it'd be in the spirit of ikiwiki. --[[schmonz]] + +>>>> Yes, I think this could probably be used in combination with ikiwiki's +>>>> httpauth and openid plugins. --[[Joey]] -- cgit v1.2.3 From 904c16a68b07078750e5906ffb2c568d22d955e3 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Tue, 1 Sep 2009 14:17:51 +0100 Subject: Remove references to merged-and-deleted git branches --- doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn | 2 -- doc/todo/backlinks_result_is_lossy.mdwn | 1 - doc/todo/generated_po_stuff_not_ignored_by_git.mdwn | 1 - doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn | 2 -- doc/todo/optimize_simple_dependencies.mdwn | 2 -- doc/todo/pagestats_among_a_subset_of_pages.mdwn | 1 - doc/todo/should_optimise_pagespecs.mdwn | 4 ---- doc/todo/source_link.mdwn | 2 -- 8 files changed, 15 deletions(-) (limited to 'doc/todo') diff --git a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn index 5e842ca7f..ad0f506f2 100644 --- a/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn +++ b/doc/bugs/map_fails_to_close_ul_element_for_empty_list.mdwn @@ -66,8 +66,6 @@ Patch: >>>>>> The current arrangement looks fine to me. Thanks. --[[harishcm]] -[[!template id=gitbranch author="[[harishcm]]" branch=smcv/ready/harishcm-map-fix]] - > [[merged|done]] --[[Joey]] Patch: diff --git a/doc/todo/backlinks_result_is_lossy.mdwn b/doc/todo/backlinks_result_is_lossy.mdwn index 11b5fbcae..2a9fc4a0a 100644 --- a/doc/todo/backlinks_result_is_lossy.mdwn +++ b/doc/todo/backlinks_result_is_lossy.mdwn @@ -1,5 +1,4 @@ [[!tag patch patch/core]] -[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]] IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a lossy transformation (to get it in the form that page templates want), making diff --git a/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn b/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn index 1d24fd385..29c017c5d 100644 --- a/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn +++ b/doc/todo/generated_po_stuff_not_ignored_by_git.mdwn @@ -1,4 +1,3 @@ -[[!template id=gitbranch branch=smcv/gitignore author="[[smcv]]"]] [[!tag patch]] The recent merge of the po branch didn't come with a .gitignore. diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn index bbde04f83..85bb4ff5a 100644 --- a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn +++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn @@ -1,5 +1,3 @@ -[[!template id=gitbranch branch=smcv/ready/inline-pagenames author="[[smcv]]"]] - A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds the following parameter to the [[ikiwiki/directive/inline]] directive: diff --git a/doc/todo/optimize_simple_dependencies.mdwn b/doc/todo/optimize_simple_dependencies.mdwn index 91e184c29..6f6284303 100644 --- a/doc/todo/optimize_simple_dependencies.mdwn +++ b/doc/todo/optimize_simple_dependencies.mdwn @@ -1,5 +1,3 @@ -[[!template id=gitbranch branch=smcv/ready/depends-exact author="[[smcv]]"]] - I'm still trying to optimize ikiwiki for a site using [[plugins/contrib/album]], and checking which pages depend on which pages is still taking too long. Here's another go at fixing that, using [[Will]]'s diff --git a/doc/todo/pagestats_among_a_subset_of_pages.mdwn b/doc/todo/pagestats_among_a_subset_of_pages.mdwn index fd15d6a42..33f9258fd 100644 --- a/doc/todo/pagestats_among_a_subset_of_pages.mdwn +++ b/doc/todo/pagestats_among_a_subset_of_pages.mdwn @@ -1,5 +1,4 @@ [[!tag patch plugins/pagestats]] -[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]] My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that to provide pagestats for links from a subset of pages. From the docs included diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 4b4e267f0..728ab8994 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -79,8 +79,6 @@ I can think about reducung the size of my wiki source and making it available on > > --[[Joey]] -[[!template id=gitbranch branch=smcv/ready/optimize-depends author="[[smcv]]"]] - >> I've been looking at optimizing ikiwiki for a site using >> [[plugins/contrib/album]] (which produces a lot of pages) and it seems >> that checking which pages depend on which pages does take a significant @@ -100,8 +98,6 @@ I can think about reducung the size of my wiki source and making it available on >>>> I haven't actually deleted it), because the "or" operation is now done in >>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]] -[[!template id=gitbranch branch=smcv/ready/remove-pagespec-merge author="[[smcv]]"]] - >>>>> I've now added a patch to the end of that branch that deletes >>>>> `pagespec_merge` almost entirely (we do need to keep a copy around, in >>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn index dfc2766cc..cf3e69487 100644 --- a/doc/todo/source_link.mdwn +++ b/doc/todo/source_link.mdwn @@ -11,8 +11,6 @@ All of this code is licensed under the GPLv2+. -- [[Will]] > by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does? > --[[smcv]] -[[!template id=gitbranch branch=smcv/ready/getsource - author="[[Will]]/[[smcv]]"]] [[done]] >> I've applied the patch below in a git branch, fixed my earlier criticism, -- cgit v1.2.3 From a149d54fbf110000b3980bba87cac0e86dd03e07 Mon Sep 17 00:00:00 2001 From: "http://eric.shared.dre.am/" Date: Fri, 4 Sep 2009 19:17:14 -0400 Subject: --- ...e_link_target_search_all_paths_as_fallback.mdwn | 27 ++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 doc/todo/make_link_target_search_all_paths_as_fallback.mdwn (limited to 'doc/todo') diff --git a/doc/todo/make_link_target_search_all_paths_as_fallback.mdwn b/doc/todo/make_link_target_search_all_paths_as_fallback.mdwn new file mode 100644 index 000000000..f971fd8e0 --- /dev/null +++ b/doc/todo/make_link_target_search_all_paths_as_fallback.mdwn @@ -0,0 +1,27 @@ +[[!tag wishlist]] + +## Idea + +After searching from the most local to the root for a wikilinkable page, descend into the tree of pages looking for a matching page. + +For example, if I link to \[\[Pastrami\]\] from /users/eric, the current behavior is to look for + + * /users/eric/pastrami + * /users/pastrami + * /users/eric/pastrami + +I'd like it to find /sandwiches/pastrami. + +## Issues + +I know this is a tougher problem, especially to scale efficiently. There is also not a clear ordering unless it is the recursive dictionary ordering (ie the order of a breadth-first search with natural ordering). It would probably require some sort of static lookup table keyed by pagename and yielding a path. This could be generated initially by a breadth-first search and then updated incrementally when pages are added/removed/renamed. In some ways a global might not be ideal, since one might argue that the link above should match /users/eric/sandwiches/pastrami before /sandwiches/pastrami. I guess you could put all matching paths in the lookup table and then evaluate the ordering at parse-time. + +## Motivation + +Since I often access my documents using a text editor, I find it useful to keep them ordered in a heirarchy, about 3 levels deep with a branching factor of perhaps 10. When linking though, I'd like the wiki to find the document for me, since I am lazy. + +Also, many of my wiki pages comprise the canonical local representation of some unique entity, for example I might have /software/ikiwiki. The nesting, however, is only to aid navigation, and shouldn't be considered as part of resource's name. + +## Alternatives + +If an alias could be specified in the page body (for example, /ikiwiki for /software/ikiwiki) which would then stand in for a regular page when searching, then the navigational convenience of folders could be preserved while selectively flattening the search namespace. -- cgit v1.2.3 From 507d8ace625317072bfed7925b516fe3c573a568 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 6 Sep 2009 13:26:42 -0400 Subject: thoughts on translating the templates files --- doc/todo/l10n.mdwn | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/l10n.mdwn b/doc/todo/l10n.mdwn index fed3f63b6..a539f0424 100644 --- a/doc/todo/l10n.mdwn +++ b/doc/todo/l10n.mdwn @@ -14,6 +14,8 @@ and there is a po/ikiwiki.pot in the source that can be translated. ---- +## template i18n + From [[Recai]]: > Here is my initial work on ikiwiki l10n infrastructure (I'm sending it > before finalizing, there may be errors). @@ -64,9 +66,19 @@ Birisi[1], ki muhtemelen bu sizsiniz, [2] üzerindeki bulundu. Parola: -- ikiwiki [1] Parolayı isteyen kullanıcının ait IP adresi: [2] -> Looks like, tmpl_process3 cannot preserve line breaks in template files. -> For example, it processed the following template: - This could be easily worked around in tmpl_process3, but I wouldn't like to maintain a separate utility. +---- + +Another way to approach this would be to write a small program that outputs +the current set of templates. Now i18n of that program is trivial, +and it can be run once per language to generate localized templates. + +Then it's just a matter of installing the templates somewhere, and having +them be used when a different language is enabled. + +It would make sense to make the existing `locale` setting control which +templates are used. But the [[plugins/po]] plugin would probably want to do +something more, and use the actual language the page is written in. +--[[Joey]] -- cgit v1.2.3 From 55474f44d93ffb35f650ab8ba8b32f4478eba1c3 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 8 Sep 2009 15:17:39 -0400 Subject: Expand banned_users; it can now include PageSpecs, which allows banning by IP address. --- IkiWiki/CGI.pm | 28 +++++++++++++++++++++------- debian/changelog | 2 ++ doc/banned_users.mdwn | 8 +++++++- doc/todo/blocking_ip_ranges.mdwn | 3 +++ 4 files changed, 33 insertions(+), 8 deletions(-) (limited to 'doc/todo') diff --git a/IkiWiki/CGI.pm b/IkiWiki/CGI.pm index af58d7cb5..52cafade0 100644 --- a/IkiWiki/CGI.pm +++ b/IkiWiki/CGI.pm @@ -252,16 +252,30 @@ sub check_banned ($$) { my $q=shift; my $session=shift; + my $banned=0; my $name=$session->param("name"); - if (defined $name) { - if (grep { $name eq $_ } @{$config{banned_users}}) { - $session->delete(); - cgi_savesession($session); - cgi_custom_failure( - $q->header(-status => "403 Forbidden"), - gettext("You are banned.")); + if (defined $name && + grep { $name eq $_ } @{$config{banned_users}}) { + $banned=1; + } + + foreach my $b (@{$config{banned_users}}) { + if (pagespec_match("", $b, + ip => $ENV{REMOTE_ADDR}, + name => defined $name ? $name : "", + )) { + $banned=1; + last; } } + + if ($banned) { + $session->delete(); + cgi_savesession($session); + cgi_custom_failure( + $q->header(-status => "403 Forbidden"), + gettext("You are banned.")); + } } sub cgi_getsession ($) { diff --git a/debian/changelog b/debian/changelog index 6109a7012..86e8513f7 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,8 @@ ikiwiki (3.14159265) UNRELEASED; urgency=low * Add French basewiki translation from the Debian French l10n team, including Philippe Batailler, Alexandre Dupas, and Steve Petruzzello. + * Expand banned_users; it can now include PageSpecs, which + allows banning by IP address. -- Joey Hess Wed, 02 Sep 2009 15:01:27 -0400 diff --git a/doc/banned_users.mdwn b/doc/banned_users.mdwn index d2bec90f0..c44f8c587 100644 --- a/doc/banned_users.mdwn +++ b/doc/banned_users.mdwn @@ -1,4 +1,10 @@ -Banned users can be configured in the setup file. +Banned users can be configured in the setup file via the `banned_users` +setting. This is a list of user names, or [[PageSpecs|ikiwiki/PageSpec]] +to ban. Using a PageSpec is useful to block an IP address. + +For example: + + banned_users => ['evilspammer', 'ip(192.168.1.1)'], If a banned user attempts to use the ikiwiki CGI, they will receive a 403 Forbidden webpage indicating they are banned. diff --git a/doc/todo/blocking_ip_ranges.mdwn b/doc/todo/blocking_ip_ranges.mdwn index 95026eef1..ac2344ece 100644 --- a/doc/todo/blocking_ip_ranges.mdwn +++ b/doc/todo/blocking_ip_ranges.mdwn @@ -2,3 +2,6 @@ Admins need the ability to block IP ranges. They can already ban users. See [[fileupload]] for a propsal that grew to encompass the potential to do this. + +[[done]] (well, there is no pagespec for IP ranges yet, but we can block +individual IPs) -- cgit v1.2.3 From 290db7808f8dc9ee1bfd0caa33d5c3205c0651f8 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 10 Sep 2009 17:03:19 -0400 Subject: update a few cvs things --- doc/post-commit/discussion.mdwn | 2 +- doc/todo/CVS_backend.mdwn | 4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/post-commit/discussion.mdwn b/doc/post-commit/discussion.mdwn index c78709e94..fc0a27ee4 100644 --- a/doc/post-commit/discussion.mdwn +++ b/doc/post-commit/discussion.mdwn @@ -91,7 +91,7 @@ Can you offer an educated guess what's going wrong here? --[[Schmonz]] >>> Aaaaaand I was wrong about the second half of the conjecture being >>> wrong. The wrapper script wasn't correctly identifying directories; >>> with that fixed, everything works. I've created a ->>> [[plugins/contrib/cvs]] plugin page. Thanks for listening. :-) +>>> [[rcs/cvs]] page. Thanks for listening. :-) >>> --[[Schmonz]] >> Here is a comment I committed to my laptop from Madrid Airport before diff --git a/doc/todo/CVS_backend.mdwn b/doc/todo/CVS_backend.mdwn index 3c6527290..c450542e2 100644 --- a/doc/todo/CVS_backend.mdwn +++ b/doc/todo/CVS_backend.mdwn @@ -9,6 +9,8 @@ Original discussion: >> No, although the existing svn backend could fairly esily be modified into >> a CVS backend, by someone who doesn't mind working with CVS. --[[Joey]] >> ->>> Wouldn't say I don't mind, but I needed it. See [[plugins/contrib/cvs]]. --[[Schmonz]] +>>> Wouldn't say I don't mind, but I needed it. See [[rcs/cvs]]. --[[Schmonz]] + +[[done]] [[!tag wishlist]] -- cgit v1.2.3 From 6559e68a3dff2e934d8e586d5ab0a44bd083d278 Mon Sep 17 00:00:00 2001 From: simonraven Date: Sat, 12 Sep 2009 20:41:37 -0400 Subject: sort= param wishlist for map --- doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn (limited to 'doc/todo') diff --git a/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn b/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn new file mode 100644 index 000000000..3ecc6a241 --- /dev/null +++ b/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn @@ -0,0 +1,5 @@ +## sort= parameter + +Having a `sort=` parameter for the map plugin/directive would be real nice; like `inline`'s parameter, with `age`, `title`, etc. + +I may hack one in from `inline` if it seem within my skill level. -- cgit v1.2.3 From 1c8dcc9bcd27e2bc882c84d45061fb09b5602c94 Mon Sep 17 00:00:00 2001 From: simonraven Date: Sat, 12 Sep 2009 20:43:07 -0400 Subject: --- doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn b/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn index 3ecc6a241..f6ccaf538 100644 --- a/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn +++ b/doc/todo/sort_parameter_for_map_plugin_and_directive.mdwn @@ -3,3 +3,5 @@ Having a `sort=` parameter for the map plugin/directive would be real nice; like `inline`'s parameter, with `age`, `title`, etc. I may hack one in from `inline` if it seem within my skill level. + +[[!tag wishlist]] -- cgit v1.2.3 From 950ce19c03ed14c4ed14408384e37ee2769e8b11 Mon Sep 17 00:00:00 2001 From: simonraven Date: Sat, 12 Sep 2009 20:44:02 -0400 Subject: --- doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn index 8a4b852b7..fb942a495 100644 --- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn +++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn @@ -10,4 +10,8 @@ those contents instead. --[[madduck]] + +> In mine I just copied sidebar out and made some extra "sidebars", but they go elsewhere. Ugly hack, but it works. --[[simonraven]] + + [[!tag wishlist]] -- cgit v1.2.3 From b9d2ee880ccfe54035a7c5e2d14917d84ec8fd45 Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Thu, 17 Sep 2009 11:29:23 -0400 Subject: Resolve native reStructuredText links to ikiwiki pages --- ...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 124 +++++++++++++++++++++ 1 file changed, 124 insertions(+) create mode 100644 doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn new file mode 100644 index 000000000..c90261dc3 --- /dev/null +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -0,0 +1,124 @@ +I have a working minimal implementation letting the rst renderer resolve undefined native rST links to ikiwiki pages. I have posted it as one patch at: + +Preview commit: http://github.com/engla/ikiwiki/commit/486fd79e520da1d462f00f40e7a90ab07e9c6fdf +Repository: git://github.com/engla/ikiwiki.git + +Design issues of the patch: + +Right now it changes rendering so that undefined pages (previous errors) are resolved to either ikiwiki pages or link to "#". It could be changed (trivially) so that undefined pages give the same error as before. Since it only resolves links that would previously error out, impact on current installations should be minimal. + +I don't know why backlinks don't show up with the patch as it is; they are registered, but not rendered on the linked-to page. + +Desing issues in general: + +We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately. + +Many other issues with rST are of course unresolved, but some might be solved by implementing custom rST directives (which is a supported extension mechanism). + +Patch follows: + +---- +
+	From 486fd79e520da1d462f00f40e7a90ab07e9c6fdf Mon Sep 17 00:00:00 2001
+	From: Ulrik Sverdrup 
+	Date: Thu, 17 Sep 2009 15:18:50 +0200
+	Subject: [PATCH] rst: Resolve native reStructuredText links to ikiwiki pages
+
+	Links in rST use syntax `Like This`_ or OneWordLink_, and are
+	generally used for relative or absolue links, with an auxiliary
+	definition:
+
+	.. _`Like This`: http://ikiwiki.info
+	.. _OneWordLink: relative
+
+	We can hook into docutils to resolve unresolved links so that rST
+	links without definition can be resolved to wiki pages. This enables
+	WikiLink_ to link to [[WikiLink]] (if no .. _WikiLink is specified).
+
+	Comparing to Ikiwiki's wikilinks
+
+	[[blogging|blog]] specifies a link to the page blog, with the name
+	blogging. In rST we should use blogging_
+
+	.. _blogging: blog
+
+	*However*, note that this patch does not hook into this. What we
+	resolve in this patch is finding the appropriate "_blogging" if it is
+	not found, not resolving the address 'blog'.
+	---
+	 plugins/rst |   46 +++++++++++++++++++++++++++++++++++++++++-----
+	 1 files changed, 41 insertions(+), 5 deletions(-)
+
+	diff --git a/plugins/rst b/plugins/rst
+	index a2d07eb..a74baa8 100755
+	--- a/plugins/rst
+	+++ b/plugins/rst
+	@@ -6,22 +6,58 @@
+	 # based a little bit on rst.pm by Sergio Talens-Oliag, but only a little bit. :)
+	 #
+	 # Copyright © martin f. krafft 
+	+# Copyright © Ulrik Sverdrup , 2009
+	+#
+	 # Released under the terms of the GNU GPL version 2
+	 #
+	+
+	 __name__ = 'rst'
+	 __description__ = 'xml-rpc-based ikiwiki plugin to process RST files'
+	-__version__ = '0.3'
+	+__version__ = '0.3+'
+	 __author__ = 'martin f. krafft '
+	 __copyright__ = 'Copyright © ' + __author__
+	 __licence__ = 'GPLv2'
+	 
+	 from docutils.core import publish_parts;
+	+from docutils.writers import html4css1
+	 from proxy import IkiWikiProcedureProxy
+	 
+	-def rst2html(proxy, *kwargs):
+	-    # FIXME arguments should be treated as a hash, the order could change
+	-    # at any time and break this.
+	-    parts = publish_parts(kwargs[3], writer_name='html',
+	+class IkiwikiWriter(html4css1.Writer):
+	+    def resolve_node(self, node):
+	+        refname = node.get('refname', None)
+	+        if not refname:
+	+            return False
+	+
+	+        bestlink = self.proxy.rpc('bestlink', self.page, refname)
+	+
+	+        node.resolved = 1
+	+        node['class'] = 'wiki'
+	+        del node['refname']
+	+
+	+        if not bestlink:
+	+            rel_url = "#"
+	+        else:
+	+            rel_url = self.proxy.rpc('urlto', bestlink, self.page)
+	+            self.proxy.rpc('add_link', self.page, bestlink)
+	+        node['refuri'] = rel_url
+	+        self.proxy.rpc('debug', "Emitting link %s => %s" % (refname, rel_url))
+	+        return True
+	+
+	+    resolve_node.priority = 1
+	+
+	+    def __init__(self, proxy, page):
+	+        html4css1.Writer.__init__(self)
+	+        self.proxy = proxy
+	+        self.page = page
+	+        self.unknown_reference_resolvers = (self.resolve_node, )
+	+
+	+def rst2html(proxy, *args):
+	+    # args is a list paired by key, value, so we turn it into a dict
+	+    kwargs = dict((k, v) for k, v in zip(*[iter(args)]*2))
+	+    page = kwargs['page']
+	+
+	+    parts = publish_parts(kwargs['content'],
+	+                          writer=IkiwikiWriter(proxy, page),
+	                           settings_overrides = { 'halt_level': 6
+	                                                , 'file_insertion_enabled': 0
+	                                                , 'raw_enabled': 1
+	-- 
+	1.6.4
+
+
+---- -- cgit v1.2.3 From 470712618401fb3cd322c84d1c57e4b8835850d5 Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Thu, 17 Sep 2009 12:07:23 -0400 Subject: The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused? --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index c90261dc3..7adcb5c09 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -7,7 +7,7 @@ Design issues of the patch: Right now it changes rendering so that undefined pages (previous errors) are resolved to either ikiwiki pages or link to "#". It could be changed (trivially) so that undefined pages give the same error as before. Since it only resolves links that would previously error out, impact on current installations should be minimal. -I don't know why backlinks don't show up with the patch as it is; they are registered, but not rendered on the linked-to page. +The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused? Desing issues in general: -- cgit v1.2.3 From 356188f7c65c0e9b78e8be1e477acb785d48d3c2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 17 Sep 2009 12:42:40 -0400 Subject: response --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 7adcb5c09..c98723f2d 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -9,6 +9,11 @@ Right now it changes rendering so that undefined pages (previous errors) are res The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused? +> The page content fed to htmlize may be different than that fed to scan, +> as directives can change the content. If you cached the input and output +> at scan time, you could reuse the cached data at htmlize time for inputs +> that are the same -- but that could be a very big cache! --[[Joey]] + Desing issues in general: We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately. -- cgit v1.2.3 From fc1cc57cdca9a7bdab41f0d63e34a98a2d7c78e5 Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Thu, 17 Sep 2009 15:38:40 -0400 Subject: about replacements in rst (renaming links) --- ...Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index c98723f2d..642382b47 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -18,6 +18,16 @@ Desing issues in general: We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately. +> I found out this is possible by using rST subsitutions. So to do [[Version history...|releases]] +> you would use: +> +> `|releases|_` +> `.. |releases| replace:: Version history...` +> Which does not seem to have an inline replacement. Using non-resolved links there is the alternative: +> +> ``Version history `_`. --ulrik [kaizer.se] + + Many other issues with rST are of course unresolved, but some might be solved by implementing custom rST directives (which is a supported extension mechanism). Patch follows: -- cgit v1.2.3 From b7db2ca37f400e09a663b01800e3bc5477a304df Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Thu, 17 Sep 2009 15:42:34 -0400 Subject: word use, equivalent is better. --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 642382b47..aa96fc431 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -23,7 +23,7 @@ We resolve rST links without definition, we don't help resolving defined relativ > > `|releases|_` > `.. |releases| replace:: Version history...` -> Which does not seem to have an inline replacement. Using non-resolved links there is the alternative: +> Which does not seem to have an inline equivalent. Using non-resolved links there is the alternative: > > ``Version history `_`. --ulrik [kaizer.se] -- cgit v1.2.3 From e19d0c5bbdcd45d810688f990381b639485434bb Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 18 Sep 2009 16:08:16 +0200 Subject: on caching --- .../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index aa96fc431..c8d7ba5ed 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -14,6 +14,12 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera > at scan time, you could reuse the cached data at htmlize time for inputs > that are the same -- but that could be a very big cache! --[[Joey]] +>> I would propose using a simple heuristic: If you see `[[` anywhere on the +>> page, don't cache it. It would be an effective cache for pure-rst wikis +>> (without any ikiwiki directives or wikilinks). +>> However, I think that if the cache does not work for a big load, it should +>> not work at all; small loads are small so they don't matter. --ulrik + Desing issues in general: We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately. -- cgit v1.2.3 From 5cd338fe16ede5aa1dbbf80cdfe027f8bfa09cd3 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 18 Sep 2009 16:10:43 +0200 Subject: escape markup (oops) --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index c8d7ba5ed..682229469 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -14,7 +14,7 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera > at scan time, you could reuse the cached data at htmlize time for inputs > that are the same -- but that could be a very big cache! --[[Joey]] ->> I would propose using a simple heuristic: If you see `[[` anywhere on the +>> I would propose using a simple heuristic: If you see \[[ anywhere on the >> page, don't cache it. It would be an effective cache for pure-rst wikis >> (without any ikiwiki directives or wikilinks). >> However, I think that if the cache does not work for a big load, it should -- cgit v1.2.3 From 25eafa8522a9480ca2abb6df45a613ac3d0b9880 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 18 Sep 2009 16:46:41 +0200 Subject: Refactor, and Propose :wiki: syntax for rST wikilinks --- ...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 112 +++++++++++++++++---- 1 file changed, 94 insertions(+), 18 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 682229469..49be3f30a 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -1,28 +1,84 @@ -I have a working minimal implementation letting the rst renderer resolve undefined native rST links to ikiwiki pages. I have posted it as one patch at: +_NB! this page has been refactored, hopefully it is clearer now_ +_I propose putting discussion posts somewhere in the vincity of +the secttion Individual reStructuredText Issues_ -Preview commit: http://github.com/engla/ikiwiki/commit/486fd79e520da1d462f00f40e7a90ab07e9c6fdf -Repository: git://github.com/engla/ikiwiki.git +**Goal** -Design issues of the patch: +To be able to use rst as a first-class markup language in ikiwiki. I think +most believe this is almost impossible (ikiwiki is built around markdown). -Right now it changes rendering so that undefined pages (previous errors) are resolved to either ikiwiki pages or link to "#". It could be changed (trivially) so that undefined pages give the same error as before. Since it only resolves links that would previously error out, impact on current installations should be minimal. +**Design** -The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused? +**WikiLinks**, first and foremost, are needed for a wiki. rST already allows +specifying absolue and relative URL links, and relative links can be used to +tie together wiki of rst documents. -> The page content fed to htmlize may be different than that fed to scan, -> as directives can change the content. If you cached the input and output -> at scan time, you could reuse the cached data at htmlize time for inputs -> that are the same -- but that could be a very big cache! --[[Joey]] +1. Below are links to a small, working implementation for resolving + undefined rST references using ikiwiki's mechanism. This is **Proposal 1** + for rst WikiLinks. ->> I would propose using a simple heuristic: If you see \[[ anywhere on the ->> page, don't cache it. It would be an effective cache for pure-rst wikis ->> (without any ikiwiki directives or wikilinks). ->> However, I think that if the cache does not work for a big load, it should ->> not work at all; small loads are small so they don't matter. --ulrik +2. Looking over at rST-using systems such as trac and MoinMoin; I think it + would be wiser to implement wikilinks by the `:role:` mechanism, together + with allowing a custom URL scheme to point to wiki links. This is + **Proposal 2**. + + This is a simple wiki page, with :wiki:`WikiLinks` and other_ links + + .. _other: wiki:wikilink + +Benefits of using a `:role:` and a `wiki: page/subpage` URL scheme are +following: + +1. rST documents taken out of the context (the wiki) will not fail as bad as + if they have lots of Proposal-1 links: They look just the same as valid + references, and you have to edit them all. + In contrast, should the `:wiki:` role disappear, one line is enough + to redefined it and silence all the warnings for the document: + + .. role:: wiki (title) + +*Implementation* there is no implementation of Proposal 2 but it should be +doable; adding a local role is trivial. Rewriting `wiki:` links could be +done in the format phase(?). + +Now **Directives**: As it is now, ikiwiki goes though (roughly): +filter, preprocess, htmlize, format as major stages of content +transformation. rST has major problems to work with any HTML that enters the +picture before it. + +1. Formatting rST in `htmlize` (as is done now): Raw html can be escaped by + raw blocks: + + .. raw:: html + + \[[!inline and do stuff]] + + (This can be simplified to alias the above as `.. ikiwiki::`) + This escape method works, if ikwiki can be persuaded to maintain the + indent when inserting html, so that it stays inside the raw block. + +2. Formatting rST in `filter` (idea) + 1. rST does not have to see any HTML (raw not needed) + 2. rST directives can alias ikiwiki syntax: + + ..ikiwiki:: inline pages= ... -Desing issues in general: + 3. Using rST directives as ikiwiki directives can be complicated; + but rST directives allow a direct line (after :: on first line), + an option list, and a content block. -We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately. + +**Discussion** + +I guess you (or someone) has been through this before and knows why it +simply won't work. But I hoped there was something original in the above; +and I know there are wiki installations where rST works. --ulrik + +**Individual reStructuredText Issues** + +* We resolve rST links without definition, we don't help resolving defined + relative links, so we don't support specifying link name and target + separately. > I found out this is possible by using rST subsitutions. So to do [[Version history...|releases]] > you would use: @@ -33,8 +89,28 @@ We resolve rST links without definition, we don't help resolving defined relativ > > ``Version history `_`. --ulrik [kaizer.se] +**A first implementation: Resolving unmatched links** + +I have a working minimal implementation letting the rst renderer resolve +undefined native rST links to ikiwiki pages. I have posted it as one patch at: + +Preview commit: http://github.com/engla/ikiwiki/commit/486fd79e520da1d462f00f40e7a90ab07e9c6fdf +Repository: git://github.com/engla/ikiwiki.git + +Design issues of the patch: + +The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to generate backlinks). Can the parse output be safely reused? + +> The page content fed to htmlize may be different than that fed to scan, +> as directives can change the content. If you cached the input and output +> at scan time, you could reuse the cached data at htmlize time for inputs +> that are the same -- but that could be a very big cache! --[[Joey]] -Many other issues with rST are of course unresolved, but some might be solved by implementing custom rST directives (which is a supported extension mechanism). +>> I would propose using a simple heuristic: If you see \[[ anywhere on the +>> page, don't cache it. It would be an effective cache for pure-rst wikis +>> (without any ikiwiki directives or wikilinks). +>> However, I think that if the cache does not work for a big load, it should +>> not work at all; small loads are small so they don't matter. --ulrik Patch follows: -- cgit v1.2.3 From 18151b8152f01421bb42ab62d9fabd56038126e1 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 18 Sep 2009 20:07:18 +0200 Subject: about default-role --- .../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 49be3f30a..ba9440b43 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -23,9 +23,16 @@ tie together wiki of rst documents. **Proposal 2**. This is a simple wiki page, with :wiki:`WikiLinks` and other_ links - + .. _other: wiki:wikilink + We can get rid of the role part as well for WikiLinks:: + + .. default-role:: wiki + + Enables `WikiLinks` but does not impact references such as ``other`` + This can be made the default for ikiwiki. + Benefits of using a `:role:` and a `wiki: page/subpage` URL scheme are following: -- cgit v1.2.3 From 254046edcb4c2ed66bf14dbe3526d39acac9cfe3 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Mon, 21 Sep 2009 23:50:42 +0200 Subject: Posting patch series for rst Wikilinks and Preproc indent --- ...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 163 ++++++--------------- 1 file changed, 42 insertions(+), 121 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index ba9440b43..54d9a6c4b 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -2,12 +2,14 @@ _NB! this page has been refactored, hopefully it is clearer now_ _I propose putting discussion posts somewhere in the vincity of the secttion Individual reStructuredText Issues_ +## Design ## + **Goal** To be able to use rst as a first-class markup language in ikiwiki. I think most believe this is almost impossible (ikiwiki is built around markdown). -**Design** +## Wikilinks ## **WikiLinks**, first and foremost, are needed for a wiki. rST already allows specifying absolue and relative URL links, and relative links can be used to @@ -44,9 +46,37 @@ following: .. role:: wiki (title) -*Implementation* there is no implementation of Proposal 2 but it should be -doable; adding a local role is trivial. Rewriting `wiki:` links could be -done in the format phase(?). +### Implementation ### + +Implementation of Proposal-2 wikilinks are in the branch +[rst-wikilinks][rst-wl] + + + This is a simple wiki page, with :wiki:`WikiLinks` and |named| links + + .. |named| wiki:: Some Page + + We can get rid of the role part as well for WikiLinks:: + + .. default-role:: wiki + + Enables `WikiLinks` but does not impact references such as ``named`` + This can be made the default for ikiwiki. + +[rst-wl]: http://github.com/engla/ikiwiki/commits/rst-wikilinks + +On top of **rst-wikilinks** is [rst-customize][rst-custom] which adds two +power user features: Global (python) file to read in custom directives +(unsafe), and a wikifile as "header" file for all parsed .rst files (safe, +but disruptive since all .rst depend on it). Well, the customizations have +to be picked and chosen from this, but at least the global python file can +be very convenient. + +Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/) + +[rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize + +## Directives ## Now **Directives**: As it is now, ikiwiki goes though (roughly): filter, preprocess, htmlize, format as major stages of content @@ -74,8 +104,13 @@ picture before it. but rST directives allow a direct line (after :: on first line), an option list, and a content block. +### Implementation ### + +Preserving indents in the preprocessor are in branch [pproc-indent][ppi] -**Discussion** +[ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent + +## Discussion ## I guess you (or someone) has been through this before and knows why it simply won't work. But I hoped there was something original in the above; @@ -86,15 +121,8 @@ and I know there are wiki installations where rST works. --ulrik * We resolve rST links without definition, we don't help resolving defined relative links, so we don't support specifying link name and target separately. - -> I found out this is possible by using rST subsitutions. So to do [[Version history...|releases]] -> you would use: -> -> `|releases|_` -> `.. |releases| replace:: Version history...` -> Which does not seem to have an inline equivalent. Using non-resolved links there is the alternative: -> -> ``Version history `_`. --ulrik [kaizer.se] + + * Resolved by |replacement| links with the wiki:: directive. **A first implementation: Resolving unmatched links** @@ -119,110 +147,3 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera >> However, I think that if the cache does not work for a big load, it should >> not work at all; small loads are small so they don't matter. --ulrik -Patch follows: - ----- -
-	From 486fd79e520da1d462f00f40e7a90ab07e9c6fdf Mon Sep 17 00:00:00 2001
-	From: Ulrik Sverdrup 
-	Date: Thu, 17 Sep 2009 15:18:50 +0200
-	Subject: [PATCH] rst: Resolve native reStructuredText links to ikiwiki pages
-
-	Links in rST use syntax `Like This`_ or OneWordLink_, and are
-	generally used for relative or absolue links, with an auxiliary
-	definition:
-
-	.. _`Like This`: http://ikiwiki.info
-	.. _OneWordLink: relative
-
-	We can hook into docutils to resolve unresolved links so that rST
-	links without definition can be resolved to wiki pages. This enables
-	WikiLink_ to link to [[WikiLink]] (if no .. _WikiLink is specified).
-
-	Comparing to Ikiwiki's wikilinks
-
-	[[blogging|blog]] specifies a link to the page blog, with the name
-	blogging. In rST we should use blogging_
-
-	.. _blogging: blog
-
-	*However*, note that this patch does not hook into this. What we
-	resolve in this patch is finding the appropriate "_blogging" if it is
-	not found, not resolving the address 'blog'.
-	---
-	 plugins/rst |   46 +++++++++++++++++++++++++++++++++++++++++-----
-	 1 files changed, 41 insertions(+), 5 deletions(-)
-
-	diff --git a/plugins/rst b/plugins/rst
-	index a2d07eb..a74baa8 100755
-	--- a/plugins/rst
-	+++ b/plugins/rst
-	@@ -6,22 +6,58 @@
-	 # based a little bit on rst.pm by Sergio Talens-Oliag, but only a little bit. :)
-	 #
-	 # Copyright © martin f. krafft 
-	+# Copyright © Ulrik Sverdrup , 2009
-	+#
-	 # Released under the terms of the GNU GPL version 2
-	 #
-	+
-	 __name__ = 'rst'
-	 __description__ = 'xml-rpc-based ikiwiki plugin to process RST files'
-	-__version__ = '0.3'
-	+__version__ = '0.3+'
-	 __author__ = 'martin f. krafft '
-	 __copyright__ = 'Copyright © ' + __author__
-	 __licence__ = 'GPLv2'
-	 
-	 from docutils.core import publish_parts;
-	+from docutils.writers import html4css1
-	 from proxy import IkiWikiProcedureProxy
-	 
-	-def rst2html(proxy, *kwargs):
-	-    # FIXME arguments should be treated as a hash, the order could change
-	-    # at any time and break this.
-	-    parts = publish_parts(kwargs[3], writer_name='html',
-	+class IkiwikiWriter(html4css1.Writer):
-	+    def resolve_node(self, node):
-	+        refname = node.get('refname', None)
-	+        if not refname:
-	+            return False
-	+
-	+        bestlink = self.proxy.rpc('bestlink', self.page, refname)
-	+
-	+        node.resolved = 1
-	+        node['class'] = 'wiki'
-	+        del node['refname']
-	+
-	+        if not bestlink:
-	+            rel_url = "#"
-	+        else:
-	+            rel_url = self.proxy.rpc('urlto', bestlink, self.page)
-	+            self.proxy.rpc('add_link', self.page, bestlink)
-	+        node['refuri'] = rel_url
-	+        self.proxy.rpc('debug', "Emitting link %s => %s" % (refname, rel_url))
-	+        return True
-	+
-	+    resolve_node.priority = 1
-	+
-	+    def __init__(self, proxy, page):
-	+        html4css1.Writer.__init__(self)
-	+        self.proxy = proxy
-	+        self.page = page
-	+        self.unknown_reference_resolvers = (self.resolve_node, )
-	+
-	+def rst2html(proxy, *args):
-	+    # args is a list paired by key, value, so we turn it into a dict
-	+    kwargs = dict((k, v) for k, v in zip(*[iter(args)]*2))
-	+    page = kwargs['page']
-	+
-	+    parts = publish_parts(kwargs['content'],
-	+                          writer=IkiwikiWriter(proxy, page),
-	                           settings_overrides = { 'halt_level': 6
-	                                                , 'file_insertion_enabled': 0
-	                                                , 'raw_enabled': 1
-	-- 
-	1.6.4
-
-
----- -- cgit v1.2.3 From c399f65b627064de80107f8ee695a9a811604bcd Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Mon, 21 Sep 2009 19:39:03 -0400 Subject: a remark about pproc-indent: I'm not a perl coder. --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 54d9a6c4b..d5c92ed6f 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -108,6 +108,9 @@ picture before it. Preserving indents in the preprocessor are in branch [pproc-indent][ppi] +(These simple patches come with a warning: _Those are the first lines of +Perl I've ever written!_) + [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent ## Discussion ## -- cgit v1.2.3 From d163b06cd6c4a3018a10ced73ec2e74108c3da2a Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Tue, 22 Sep 2009 07:52:10 -0400 Subject: What is missing: Create-links, htmllink --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index d5c92ed6f..4bde25bd2 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -76,6 +76,10 @@ Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/) [rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize +**What is missing?** links to nonexistant pages are not resolved. +Perhaps the "link resolver" part should use Ikiwiki's htmllink instead +of its simple subsitutions. + ## Directives ## Now **Directives**: As it is now, ikiwiki goes though (roughly): -- cgit v1.2.3 From 92b3be2f3ef4123f2e5d9afb761cfd7251c2511d Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Tue, 22 Sep 2009 17:17:11 -0400 Subject: rst-wikilinks uses 'htmllink' --- .../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 4bde25bd2..1782af824 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -65,6 +65,11 @@ Implementation of Proposal-2 wikilinks are in the branch [rst-wl]: http://github.com/engla/ikiwiki/commits/rst-wikilinks +**rst-wikilinks** patch series includes changes at the end to use ikiwiki's +'htmllink' for the links (which is the only sane thing to do to work in all configurations). +This means a :wiki:`Link` should render just exactly like [[Link]] whether +the target exists or not. + On top of **rst-wikilinks** is [rst-customize][rst-custom] which adds two power user features: Global (python) file to read in custom directives (unsafe), and a wikifile as "header" file for all parsed .rst files (safe, @@ -76,10 +81,6 @@ Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/) [rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize -**What is missing?** links to nonexistant pages are not resolved. -Perhaps the "link resolver" part should use Ikiwiki's htmllink instead -of its simple subsitutions. - ## Directives ## Now **Directives**: As it is now, ikiwiki goes though (roughly): -- cgit v1.2.3 From 2aa93377e8845b4dd19af5a470e270c23e4e7e15 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 30 Sep 2009 13:57:36 -0400 Subject: comments and some code review --- ...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 1782af824..5f21b2272 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -109,6 +109,25 @@ picture before it. but rST directives allow a direct line (after :: on first line), an option list, and a content block. +> You've done a lot of work already, but ... +> +> The filter approach seems much simpler than the other approaches +> for users to understand, since they can just use identical ikiwiki +> markup on rst pages as they would use anywhere else. This is very desirable +> if the wiki allows rst in addition to mdwn, since then users don't have +> to learn two completly different ways of doing wikilinks and directives. +> I also wonder if even those familiar with rst would find entirely natural +> the ways you've found to shoehorn in wikilinks, named wikilinks, and ikiwiki +> directives? +> +> Htmlize in filter avoids these problems. It also leaves open the possibility +> that ikiwiki could become smarter about the rendering chain later, and learn +> to use a better order for rst (ie, htmlize first). If that later happened, +> the htmlize in filter hack could go away. --[[Joey]] + +> (BTW, the [[plugins/txt]] plugin already does html formatting +> in filter, for similar reasons.) --[[Joey]] + ### Implementation ### Preserving indents in the preprocessor are in branch [pproc-indent][ppi] @@ -116,6 +135,20 @@ Preserving indents in the preprocessor are in branch [pproc-indent][ppi] (These simple patches come with a warning: _Those are the first lines of Perl I've ever written!_) +> This seems like a good idea, since it solves issues for eg, indented +> directives in mdwn as well. But, looking at the diff, I see a clear bug: +> +> - return "[[!$command ". +> + $result = "[[!$command ". +> +> That makes it go on and parse an infinitely nested directive chain, instead +> of immediatly throwing an error. +> +> Also, it seems that the "indent" matching in the regexps may be too broad, +> wouldn't it also match whitespace before a directive that was not at the beginning +> of a line, and treat it as an indent? With some bad luck, that could cause mdwn +> to put the indented output in a pre block. --[[Joey]] + [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent ## Discussion ## -- cgit v1.2.3 From 4f37413050d4c17cb428820991541595e4645c66 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Wed, 30 Sep 2009 20:54:21 +0200 Subject: Comment, type, discuss and otherwise type wayy to much sorry!! --- ...ve_reStructuredText_links_to_ikiwiki_pages.mdwn | 71 ++++++++++++++++++++++ 1 file changed, 71 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 5f21b2272..4468ce1e9 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -128,6 +128,54 @@ picture before it. > (BTW, the [[plugins/txt]] plugin already does html formatting > in filter, for similar reasons.) --[[Joey]] +>> Thank you for the comments! Forget the work, it's not so much. +>> I'd rank the :wiki: link addition pretty high, and the other changes way +>> behind that: +>> +>> The :wiki:`Wiki Link` syntax is *very* appropriate as rst syntax +>> since it fits well with other uses of roles (notice that :RFC:`822` +>> inserts a link to RFC822 etc, and that the default role is a *title* role +>> (title of some work); thus very appropriate for medium-specific links like +>> wiki links. So I'd rank :wiki: links a worthwhile addition regardless of +>> outcome here, since it's a very rst-like alternative for those who wish to +>> use more rst-like syntax (and documents degrades better outside the wiki as +>> noted). +>> +>> The named link syntax (just like the :wiki: role) are inspired from trac +>> and a good fit, but only if the wiki is committed to using only rst, +>> which I don't think is the case. +>> +>> The rst-customize changes are very useful for custom directive +>> installations (like the sourcecode directive, or shortcut roles I show +>> in the examples page), but there might be a way for the user to inject +>> docutils addons that I'm missing (one very ugly way would be to stick +>> them in sitecustomize.py which affects all Python programs). +>> +>> With the presented changes, I already have a working RestructuredText +>> wiki, but I'm admitting that using .. raw:: html around all directives is +>> very ugly (I use few directives: inline, toggle, meta, tag, map) +>> +>> On filter/htmlize: Well **rst** is clearly antisocial: It can't see HTML, +>> and ikiwiki directives are wrappend in paragraph tags. (For wikilinks +>> this is probably no problem). So the suggestion about `.. ikiwiki:` is +>> partly because it looks good in rst syntax, but also since it would emit +>> a div to wrap around the element instead of a paragraph. +>> +>> I don't know if you mean that rst could be reordered to do htmlize before +>> other phases? rst must be before any preprocess hook to avoid seeing any +>> HTML. +>> +>> With the presented changes, I already have a working RestructuredText +>> wiki, but I'm admitting that using .. raw:: html around all directives is +>> very ugly (I use few directives: inline, toggle, meta, tag, map) +>> +>> If I'm thinking right, processing to HTML already in filter means any +>> processing in scan can be reused directly (or skipped if it's legal to +>> emit 'add_link' in filter.) +>> +>> -- [[ulrik]] + + ### Implementation ### Preserving indents in the preprocessor are in branch [pproc-indent][ppi] @@ -148,6 +196,29 @@ Perl I've ever written!_) > wouldn't it also match whitespace before a directive that was not at the beginning > of a line, and treat it as an indent? With some bad luck, that could cause mdwn > to put the indented output in a pre block. --[[Joey]] +> +>> You are probably right about the bug. I'm not quite sure what the nested +>> directives examples looks like, but I must have overlooked how the +>> recursion counter works; I thought simply changing if to elif the next +>> few lines would solve that. I'm sorry for that! +>> +>> We don't have to change the `$handle` function at all, if it is possible +>> to do the indent substitution all in one line instead of passing it to +>> handle, I don't know if it is possible to turn: +>> +>> $content =~ s{$regex}{$handle->($1, $2, $3, $4, $5)}eg; +>> +>> into +>> +>> $content =~ s{$regex}{s/^/$1/gm{$handle->($2, $3, $4, $5)}}eg; +>> +>> Well, no idea how that would be expressed, but I mean, replace the indent +>> directly in $handle's return value. +>> +>> The indent-catching regex is wrong in the way you mention, it has been +>> nagigng my mind a bit as well; I think matching start of line + spaces +>> and tabs is the only thing we want. +>> -- [[ulrik]] [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent -- cgit v1.2.3 From e04e9ccea930aefb3b1dbeb8203dce8c6f8bef13 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 30 Sep 2009 15:39:51 -0400 Subject: response --- ..._native_reStructuredText_links_to_ikiwiki_pages.mdwn | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 4468ce1e9..0f8e63aae 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -77,6 +77,9 @@ but disruptive since all .rst depend on it). Well, the customizations have to be picked and chosen from this, but at least the global python file can be very convenient. +> Did you consider just including the global rst header text into an item +> in the setup file? --[[Joey]] + Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/) [rst-custom]: http://github.com/engla/ikiwiki/commits/rst-customize @@ -141,6 +144,11 @@ picture before it. >> use more rst-like syntax (and documents degrades better outside the wiki as >> noted). >> +>>> Unsure about the degredation argument. It will work some of +>>> the time, but ikiwiki's [[ikiwiki/subpage/linkingrules]] +>>> are sufficiently different from normal html relative link +>>> rules that it often won't work. --[[Joey]] +>> >> The named link syntax (just like the :wiki: role) are inspired from trac >> and a good fit, but only if the wiki is committed to using only rst, >> which I don't think is the case. @@ -165,9 +173,11 @@ picture before it. >> other phases? rst must be before any preprocess hook to avoid seeing any >> HTML. >> ->> With the presented changes, I already have a working RestructuredText ->> wiki, but I'm admitting that using .. raw:: html around all directives is ->> very ugly (I use few directives: inline, toggle, meta, tag, map) +>>> One of my long term goals is to refactor all the code in ikiwiki +>>> that manually runs the various stages of the render pipeline, +>>> into one centralized place. Once that's done, that place can get +>>> smart about what order to run the stages, and use a different +>>> order for rst. --[[Joey]] >> >> If I'm thinking right, processing to HTML already in filter means any >> processing in scan can be reused directly (or skipped if it's legal to @@ -175,6 +185,7 @@ picture before it. >> >> -- [[ulrik]] +>>> Seems it could be, yes. --[[Joey]] ### Implementation ### -- cgit v1.2.3 From e7de3f0762d9b9ae64bd40d9fe07b00d9d6dc4d7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 30 Sep 2009 15:45:16 -0400 Subject: furthermore --- .../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 0f8e63aae..bee57f7e7 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -226,10 +226,16 @@ Perl I've ever written!_) >> Well, no idea how that would be expressed, but I mean, replace the indent >> directly in $handle's return value. >> +>> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]] +>> >> The indent-catching regex is wrong in the way you mention, it has been >> nagigng my mind a bit as well; I think matching start of line + spaces >> and tabs is the only thing we want. >> -- [[ulrik]] +>> +>>> Well, seems you want to match the indent at the start of the line containing +>>> the directive, even if the directive does not start the line. That would +>>> be quite hard to make a regexp do, though. --[[Joey]] [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent -- cgit v1.2.3 From f8ad5988da8676bfeff6db9375f2518a12f79a48 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Wed, 30 Sep 2009 21:59:11 +0200 Subject: clarifications. and indent one of joey's oneliner responses. --- ...ative_reStructuredText_links_to_ikiwiki_pages.mdwn | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index bee57f7e7..084f03304 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -79,6 +79,14 @@ be very convenient. > Did you consider just including the global rst header text into an item > in the setup file? --[[Joey]] +> +>> Then `rst_header` would not be much different from the python script +>> `rst_customize`. rst_header is as safe as other files (though disruptive +>> as noted), so it should/could be a editable file in the Wiki. A Python +>> script of course can not be. There is nothing you can do in the +>> rst_header (that you sensibly would do, I think) that couldn't be done in +>> the Python script. `rst_header` has very limited use, but it is another +>> possibility, mainly for the user-editable aspect. --[[ulrik]] Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/) @@ -148,6 +156,15 @@ picture before it. >>> the time, but ikiwiki's [[ikiwiki/subpage/linkingrules]] >>> are sufficiently different from normal html relative link >>> rules that it often won't work. --[[Joey]] +>>> +>>>> With degradation I mean that if you take a file out of the wiki; the +>>>> links degrade to stylized text. If using default role, they degrade to +>>>> :title: which renders italicized text (which I find is exactly +>>>> appropriate). There is no way for them to degrade into links, except of +>>>> course if you reimplement the :wiki: role. You can also respecify +>>>> either the default role (the `wikilink` syntax) or the :wiki: role (the +>>>> :wiki:`wikilink` syntax) to any other markup, for example None. +>>>> --[[ulrik]] >> >> The named link syntax (just like the :wiki: role) are inspired from trac >> and a good fit, but only if the wiki is committed to using only rst, @@ -226,7 +243,7 @@ Perl I've ever written!_) >> Well, no idea how that would be expressed, but I mean, replace the indent >> directly in $handle's return value. >> ->> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]] +>>> Yes, in effect just `indent($1, handle->($2,$,4))` --[[Joey]] >> >> The indent-catching regex is wrong in the way you mention, it has been >> nagigng my mind a bit as well; I think matching start of line + spaces -- cgit v1.2.3 From 9584dfddd89a0b65632201c6aa280b7c5bc964f2 Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Thu, 1 Oct 2009 14:55:36 +0200 Subject: Link to trac's Wiki-RestructuredText syntax description --- .../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 084f03304..afe50cf07 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -166,9 +166,9 @@ picture before it. >>>> :wiki:`wikilink` syntax) to any other markup, for example None. >>>> --[[ulrik]] >> ->> The named link syntax (just like the :wiki: role) are inspired from trac ->> and a good fit, but only if the wiki is committed to using only rst, ->> which I don't think is the case. +>> The named link syntax (just like the :wiki: role) are inspired from +>> [trac][tracrst] and a good fit, but only if the wiki is committed to +>> using only rst, which I don't think is the case. >> >> The rst-customize changes are very useful for custom directive >> installations (like the sourcecode directive, or shortcut roles I show @@ -204,6 +204,8 @@ picture before it. >>> Seems it could be, yes. --[[Joey]] +[tracrst]: http://trac.edgewall.org/wiki/WikiRestructuredText + ### Implementation ### Preserving indents in the preprocessor are in branch [pproc-indent][ppi] -- cgit v1.2.3 From 009f7ffded7446f1b3954ab1973faed5b96acf4d Mon Sep 17 00:00:00 2001 From: Ulrik Sverdrup Date: Fri, 2 Oct 2009 15:03:14 +0200 Subject: link to docutils mailing list discussion. also ask about

[[!directives]]

--- ...e_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index afe50cf07..e42f22970 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -87,6 +87,17 @@ be very convenient. >> rst_header (that you sensibly would do, I think) that couldn't be done in >> the Python script. `rst_header` has very limited use, but it is another >> possibility, mainly for the user-editable aspect. --[[ulrik]] +>> +>> (I foresaw only two things to be added to the rst_header: the default +>> role could be configured there (as with rst_wikirole), and if you have a +>> meta-role like :shortcut:, shortcuts could be defined there.) +> +> I have some discussion on the [docutils mailing list][dml], the developers +> of docutils seems to favor "Proposal 1", while I defend my ideas. They +> want all users of ReST to use only the basic featureset to remain +> compatible, of course. -- [[ulrik]] + +[dml]: http://thread.gmane.org/gmane.text.docutils.user/5376 Some rst-custom [examples are here](http://kaizer.se/wiki/rst_examples/) @@ -203,6 +214,11 @@ picture before it. >> -- [[ulrik]] >>> Seems it could be, yes. --[[Joey]] +>>> +>>>> It is not clear how we can work around reST wrapping directives with +>>>> paragraph tags. Also, some escaping of xml characters & <> might +>>>> happen, but I can't imagine right now what breakage can come from that. +>>>> -- [[ulrik]] [tracrst]: http://trac.edgewall.org/wiki/WikiRestructuredText -- cgit v1.2.3 From 4f9c5896b242ac08be181047ad426bd458a0bf49 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 2 Oct 2009 15:15:23 -0400 Subject: add bug about transitive dependencies --- doc/bugs/transitive_dependencies.mdwn | 47 +++++++++++++++++++++++++++ doc/plugins/sidebar/discussion.mdwn | 2 ++ doc/todo/tracking_bugs_with_dependencies.mdwn | 5 +-- 3 files changed, 50 insertions(+), 4 deletions(-) create mode 100644 doc/bugs/transitive_dependencies.mdwn (limited to 'doc/todo') diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn new file mode 100644 index 000000000..c61afe81e --- /dev/null +++ b/doc/bugs/transitive_dependencies.mdwn @@ -0,0 +1,47 @@ +If a sidebar contains a map, or inline (etc), one would expect a +change/add/remove of any of the mapped/inlined pages to cause a full wiki +rebuild. But this does not happen. + +If page A inlines page B, which inlines page C, a change to C will cause B +to be updated, but A will not "notice" that this means A needs to be +updated. + +One way to look at this bug is that it's a bug in where dependencies are +recorded when preprocessing the rendered or sidebar page. The current code +does: + + add_depends($params{page}, $somepage); + +Where `$params{page}` is page B. If this is changed to `$params{destpage}`, +then the dependency is added to page A, and updates to C cause it to +change. This does result in the page A's getting lots more dependency info +recorded than before (essentially a copy of all the B's dependency info). + +It's also a fragile, since all plugins that handle dependencies have to be +changed, and do this going forward. And it seems non-obvious that this should +be done. Or really, whether to use `page` or `destpage` there. Currently, +making the "wrong" choice and using `destpage` instead of `page` (which nearly +everything uses) will just result in semi-redundant dependency info being +recorded. If we make destpage mandatory to fix this, goofing up will lead to +this bug coming back. Ugh. + +Another approach to fix it could be to say that anything that causes a +rebuild of B is treated as a change of B. Then when C is changed, B is +rebuilt due to dependencies, and in turn this means A is rebuild because B +"changed". + +This is essentially what is done with wikilinks now, and why, if a sidebar +links to page C, add/remove of C causes all pages to be rebuilt, as seen +here: + + removing old page meep + building sidebar.mdwn, which links to meep + building TourBusStop.mdwn, which depends on sidebar + building contact.mdwn, which depends on sidebar + ... + +The only downside I can see with this approach is that it involves more work. +Does the dep resolver have to keep looping until no new pages are rebuilt? +Seems worth a try to implement this approach. + +--[[Joey]] diff --git a/doc/plugins/sidebar/discussion.mdwn b/doc/plugins/sidebar/discussion.mdwn index 78af3525c..eb441529c 100644 --- a/doc/plugins/sidebar/discussion.mdwn +++ b/doc/plugins/sidebar/discussion.mdwn @@ -1,3 +1,5 @@ > Warning: Any change to the sidebar will cause a rebuild of the whole wiki, since every page includes a copy that has to be updated. This can especially be a problem if the sidebar includes inline or map directives, since any changes to pages inlined or mapped onto the sidebar will change the sidebar and cause a full wiki rebuild. I tried exactly that, namely having an inline in my sidebar to include an rss feed from some other side. I think the complete wiki rebuild should be doable every few days when a new article appears in that feed. But contrary to that warning there is no complete wiki rebuild, only the sidebar page is rebuilt by the "ikiwiki --aggregate" from cron. Is that a bug or a feature? + +> It's a bug, discussed in [[bugs/transitive_dependencies]]. --[[Joey]] diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index bfdbf0875..3894df5f6 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -472,10 +472,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>>>> possibly by adding a dependency of the second type along with the dependency of the first type. >>>>>> An example of the current system not tracking enough data is ->>>>>> where A inlines B which inlines C. A change to C will cause B to ->>>>>> rebuild, but A will not "notice" that B has implicitly changed. ->>>>>> That example suggests it might be fixable without explicitly storing ->>>>>> data, by causing a rebuild of B to be treated as a change to B. +>>>>>> described in [[bugs/transitive_dependencies]]. >>>>>> --[[Joey]] >>>>> The second type of dependency is a little more tricky. For each page, we'd need a list of pagespecs that -- cgit v1.2.3 From 8bb94bb197714fcac1ac48f9b330bef4d17dd800 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 2 Oct 2009 15:56:44 -0400 Subject: split out dependency type issue into its own todo --- doc/todo/dependency_types.mdwn | 83 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 83 insertions(+) create mode 100644 doc/todo/dependency_types.mdwn (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn new file mode 100644 index 000000000..db7d06914 --- /dev/null +++ b/doc/todo/dependency_types.mdwn @@ -0,0 +1,83 @@ +Moved this relevant discussion to here from +[[tracking_bugs_with_dependencies]]: --[[Joey]] + +>> it seems that there are two types of dependency, and ikiwiki +>> currently only handles one of them. The first type is "Rebuild this +>> page when any of these other pages changes" - ikiwiki handles this. +>> The second type is "rebuild this page when set of pages referred to by +>> this pagespec changes" - ikiwiki doesn't seem to handle this. I +>> suspect that named pagespecs would make that second type of dependency +>> more important. I'll try to come up with a good example. -- [[Will]] + +>>> Hrm, I was going to build an example of this with backlinks, but it +>>> looks like that is handled as a special case at the moment (line 458 of +>>> render.pm). I'll see if I can breapk +>>> things another way. Fixing this properly would allow removal of that special case. -- [[Will]] + +>>>> I can't quite understand the distinction you're trying to draw +>>>> between the two types of dependencies. Backlinks are a very special +>>>> case though and I'll be suprised if they fit well into pagespecs. +>>>> --[[Joey]] + +>>>>> The issue is that the existential pagespec matching allows you to build things that have similar +>>>>> problems to backlinks. +>>>>> e.g. the following inline: + + \[[!inline pages="define(~done, link(done)) and link(~done)" archive=yes]] + +>>>>> includes any page that links to a page that links to done. Now imagine I add a new link to 'done' on +>>>>> some random page somewhere - a page which some other page links to which didn't previously get included - the set of pages accepted by the pagespec, and hence the set of +>>>>> pages inlined, will change. But, there is no dependency anywhere on the page that I altered, so +>>>>> ikiwiki will not rebuild the page with the inline in it. What is happening is that the page that I altered affects +>>>>> the set of pages matched by the pagespec without itself being matched by the pagespec, and hence included in the dependency list. + +>>>>> To make this work well, I think you need to recognise two types of dependencies for each page (and no +>>>>> special cases for particular types of links, eg backlinks). The first type of dependency says, "The content of +>>>>> this page depends upon the content of these other pages". The `add_depends()` in the shortcuts +>>>>> plugin is of this form: any time the shortcuts page is edited, any page with a shortcut on it +>>>>> is rebuilt. The inline plugin also needs to add dependencies of this form to detect when the inlined +>>>>> content changes. By contrast, the map plugin does not need a dependency of this form, because it +>>>>> doesn't actually care about the content of any pages, just which pages it needs to include (which we'll handle next). + +>>>>> The second type of dependency says, "The content of this page depends upon the exact set of pages matched +>>>>> by this pagespec". The first type of dependency was about the content of some pages, the second type is about +>>>>> which pages get matched by a pagespec. This is the type of dependency tracking that the map plugin needs. +>>>>> If the set of pages matched by map pagespec changes, then the page with the map on it needs to be rebuilt to show a different list of pages. +>>>>> Inline needs this type of dependency as well as the previous type - This type handles a change in which pages +>>>>> are inlined, the previous type handles a change in the content of any of those pages. Shortcut does not need this type of +>>>>> dependency. Most of the places that use `add_depends()` seem to need this type of dependency rather than the first type. + +>>>>>> Note that inline and map currently achieve the second type of dependency by +>>>>>> explicitly calling `add_depends` for each page the displayed. +>>>>>> If any of those pages are removed, the regular pagespec would not +>>>>>> match them -- since they're gone. However, the explicit dependency +>>>>>> on them does cause them to match. It's an ugly corner I'd like to +>>>>>> get rid of. --[[Joey]] + +>>>>> Implementation Details: The first type of dependency can be handled very similarly to the current +>>>>> dependency system. You just need to keep a list of pages that the content depends upon. You could +>>>>> keep that list as a pagespec, but if you do this you might want to check that the pagespec doesn't change, +>>>>> possibly by adding a dependency of the second type along with the dependency of the first type. + +>>>>>> An example of the current system not tracking enough data is +>>>>>> described in [[bugs/transitive_dependencies]]. +>>>>>> --[[Joey]] + +>>>>> The second type of dependency is a little more tricky. For each page, we'd need a list of pagespecs that +>>>>> the page depended on, and for each pagespec you'd want to store the list of pages that currently match it. +>>>>> On refresh, you'd need to check each pagespec to see if the set of pages that match it has changed, and if +>>>>> that set has changed, then rebuild the dependent page(s). Oh, and for this second type of dependency, I +>>>>> don't think you can merge pagespecs. If I wanted to know if either "\*" or "link(done)" changes, then just checking +>>>>> to see if the set of pages matched by "\* or link(done)" changes doesn't work. + +>>>>> The current system works because even though you usually want dependencies of the second type, the set of pages +>>>>> referred to by a pagespec can only change if one of those pages itself changes. i.e. A dependency check of the +>>>>> first type will catch a dependency change of the second type with current pagespecs. +>>>>> This doesn't work with backlinks, and it doesn't work with existential matching. Backlinks are currently special-cased. I don't know +>>>>> how to special-case existential matching - I suspect you're better off just getting the dependency tracking right. + +>>>>> I also tried to come up with other possible solutions: e.g. can we find the dependencies for a pagespec? That +>>>>> would be the set of pages where a change on one of those pages could lead to a change in the set of pages matched by the pagespec. +>>>>> For old-style pagespecs without backlinks, the dependency set for a pagespec is the same as the set of pages the pagespec matches. +>>>>> Unfortunately, with existential matching, the set of pages that each +>>>>> pagespec depends upon can quickly become "*", which is not very useful. -- [[Will]] -- cgit v1.2.3 From 8c2d221ca93ed6fbe8f093408c4e2cea835e5b4c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 2 Oct 2009 16:17:56 -0400 Subject: split off todo item for multiple dependency types --- doc/bugs/transitive_dependencies.mdwn | 2 +- doc/todo/dependency_types.mdwn | 46 +++++++++++++- doc/todo/tracking_bugs_with_dependencies.mdwn | 86 ++------------------------- 3 files changed, 50 insertions(+), 84 deletions(-) (limited to 'doc/todo') diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn index d5571cb6a..546f4f3aa 100644 --- a/doc/bugs/transitive_dependencies.mdwn +++ b/doc/bugs/transitive_dependencies.mdwn @@ -59,6 +59,6 @@ Downsides here: pass, plugins/map is then updated, because it depends on plugins/brokenlinks. (Of course, this is just a special case of the issue that a real modification to plugins/brokenlinks causes an unnecessary update of plugins/map, - because we have only one kind of dependency.) + because we have [[only_one_kind_of_dependency|todo/dependency_types]].) --[[Joey]] diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index db7d06914..6d722aab9 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -1,5 +1,24 @@ -Moved this relevant discussion to here from -[[tracking_bugs_with_dependencies]]: --[[Joey]] +Ikiwiki currently only has one type of dependency between pages +(plus wikilinks special cased in on the side). This has resulted in various +problems, and it's seemed for a long time to me that ikiwiki needs to get +smarter about what types of dependencies are supported. + +### unnecessary work + +The current single dependency type causes the depending page to be rebuilt +whenever a matching dependency is added, removed, or *modified*. But a +great many things don't care about the modification case, and often cause +unnecessary page rebuilds: + +* meta only cares if the pages are added or removed. Content change does + not matter (unless show=title is used). +* brokenlinks, orphans, pagecount, ditto +* inline in archive mode cares about page title, author changing, but + not content. (Ditto for meta with show=title.) +* Causes extra work when solving the [[bug/transitive_dependencies]] + problem. + +### two types of dependencies needed for [[tracking_bugs_with_dependencies]] >> it seems that there are two types of dependency, and ikiwiki >> currently only handles one of them. The first type is "Rebuild this @@ -81,3 +100,26 @@ Moved this relevant discussion to here from >>>>> For old-style pagespecs without backlinks, the dependency set for a pagespec is the same as the set of pages the pagespec matches. >>>>> Unfortunately, with existential matching, the set of pages that each >>>>> pagespec depends upon can quickly become "*", which is not very useful. -- [[Will]] + +### proposal + +I propose the following. --[[Joey]] + +* Add a second type of dependency, call it an "contentless dependency". +* `add_depends` defaults to adding a regular ("full") dependency, as + before. (So nothing breaks.) +* `add_depends($page, $spec, content => 0)` adds an contentless dependency. +* Contentless dependencies are stored in `%depends_contentless` and + `%depends_contentless_simple`, which are stored in the index similarly + to the existing hashes. +* `refresh` only looks at added/removed pages when resolving contentless + dependencies. + +This seems straightforwardly doable. I'd like [[Will]]'s feedback on it, if +possible. The type types of dependencies I am proposing are not identical +to the two types he talks about above, but I hope are close enough that +they can be used. + +This doesn't deal with the stuff that only depend on the metadata of a +page, as collected in the scan pass, changing. But it does leave a window +open for adding such a dependency type later. diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 3894df5f6..5f3ece290 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -360,7 +360,10 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W > --[[Joey]] >> There is one issue that I've been thinking about that I haven't raised anywhere (or checked myself), and that is how this all interacts with page dependencies. ->> Firstly, I'm not sure anymore that the `pagespec_merge` function will continue to work in all cases. +>> +>>> I've moved the discussion of that to [[dependency_types]]. --[[Joey]] +>> +>> I'm not sure anymore that the `pagespec_merge` function will continue to work in all cases. >>> The problem I can see there is that if two pagespecs >>> get merged and both use `~foo` but define it differently, @@ -413,86 +416,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W >>> My [[remove-pagespec-merge|should_optimise_pagespecs]] branch has now >>> solved all this by deleting the offending function :-) --[[smcv]] ->> Secondly, it seems that there are two types of dependency, and ikiwiki ->> currently only handles one of them. The first type is "Rebuild this ->> page when any of these other pages changes" - ikiwiki handles this. ->> The second type is "rebuild this page when set of pages referred to by ->> this pagespec changes" - ikiwiki doesn't seem to handle this. I ->> suspect that named pagespecs would make that second type of dependency ->> more important. I'll try to come up with a good example. -- [[Will]] - ->>> Hrm, I was going to build an example of this with backlinks, but it ->>> looks like that is handled as a special case at the moment (line 458 of ->>> render.pm). I'll see if I can breapk ->>> things another way. Fixing this properly would allow removal of that special case. -- [[Will]] - ->>>> I can't quite understand the distinction you're trying to draw ->>>> between the two types of dependencies. Backlinks are a very special ->>>> case though and I'll be suprised if they fit well into pagespecs. ->>>> --[[Joey]] - ->>>>> The issue is that the existential pagespec matching allows you to build things that have similar ->>>>> problems to backlinks. ->>>>> e.g. the following inline: - - \[[!inline pages="define(~done, link(done)) and link(~done)" archive=yes]] - ->>>>> includes any page that links to a page that links to done. Now imagine I add a new link to 'done' on ->>>>> some random page somewhere - a page which some other page links to which didn't previously get included - the set of pages accepted by the pagespec, and hence the set of ->>>>> pages inlined, will change. But, there is no dependency anywhere on the page that I altered, so ->>>>> ikiwiki will not rebuild the page with the inline in it. What is happening is that the page that I altered affects ->>>>> the set of pages matched by the pagespec without itself being matched by the pagespec, and hence included in the dependency list. - ->>>>> To make this work well, I think you need to recognise two types of dependencies for each page (and no ->>>>> special cases for particular types of links, eg backlinks). The first type of dependency says, "The content of ->>>>> this page depends upon the content of these other pages". The `add_depends()` in the shortcuts ->>>>> plugin is of this form: any time the shortcuts page is edited, any page with a shortcut on it ->>>>> is rebuilt. The inline plugin also needs to add dependencies of this form to detect when the inlined ->>>>> content changes. By contrast, the map plugin does not need a dependency of this form, because it ->>>>> doesn't actually care about the content of any pages, just which pages it needs to include (which we'll handle next). - ->>>>> The second type of dependency says, "The content of this page depends upon the exact set of pages matched ->>>>> by this pagespec". The first type of dependency was about the content of some pages, the second type is about ->>>>> which pages get matched by a pagespec. This is the type of dependency tracking that the map plugin needs. ->>>>> If the set of pages matched by map pagespec changes, then the page with the map on it needs to be rebuilt to show a different list of pages. ->>>>> Inline needs this type of dependency as well as the previous type - This type handles a change in which pages ->>>>> are inlined, the previous type handles a change in the content of any of those pages. Shortcut does not need this type of ->>>>> dependency. Most of the places that use `add_depends()` seem to need this type of dependency rather than the first type. - ->>>>>> Note that inline and map currently achieve the second type of dependency by ->>>>>> explicitly calling `add_depends` for each page the displayed. ->>>>>> If any of those pages are removed, the regular pagespec would not ->>>>>> match them -- since they're gone. However, the explicit dependency ->>>>>> on them does cause them to match. It's an ugly corner I'd like to ->>>>>> get rid of. --[[Joey]] - ->>>>> Implementation Details: The first type of dependency can be handled very similarly to the current ->>>>> dependency system. You just need to keep a list of pages that the content depends upon. You could ->>>>> keep that list as a pagespec, but if you do this you might want to check that the pagespec doesn't change, ->>>>> possibly by adding a dependency of the second type along with the dependency of the first type. - ->>>>>> An example of the current system not tracking enough data is ->>>>>> described in [[bugs/transitive_dependencies]]. ->>>>>> --[[Joey]] - ->>>>> The second type of dependency is a little more tricky. For each page, we'd need a list of pagespecs that ->>>>> the page depended on, and for each pagespec you'd want to store the list of pages that currently match it. ->>>>> On refresh, you'd need to check each pagespec to see if the set of pages that match it has changed, and if ->>>>> that set has changed, then rebuild the dependent page(s). Oh, and for this second type of dependency, I ->>>>> don't think you can merge pagespecs. If I wanted to know if either "\*" or "link(done)" changes, then just checking ->>>>> to see if the set of pages matched by "\* or link(done)" changes doesn't work. - ->>>>> The current system works because even though you usually want dependencies of the second type, the set of pages ->>>>> referred to by a pagespec can only change if one of those pages itself changes. i.e. A dependency check of the ->>>>> first type will catch a dependency change of the second type with current pagespecs. ->>>>> This doesn't work with backlinks, and it doesn't work with existential matching. Backlinks are currently special-cased. I don't know ->>>>> how to special-case existential matching - I suspect you're better off just getting the dependency tracking right. - ->>>>> I also tried to come up with other possible solutions: e.g. can we find the dependencies for a pagespec? That ->>>>> would be the set of pages where a change on one of those pages could lead to a change in the set of pages matched by the pagespec. ->>>>> For old-style pagespecs without backlinks, the dependency set for a pagespec is the same as the set of pages the pagespec matches. ->>>>> Unfortunately, with existential matching, the set of pages that each ->>>>> pagespec depends upon can quickly become "*", which is not very useful. -- [[Will]] + Patch updated to use closures rather than inline generated code for named pagespecs. Also includes some new use of ErrorReason where appropriate. -- [[Will]] -- cgit v1.2.3 From 1df5c5a22c7e04635c669f7d977da0318dfde9cf Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 2 Oct 2009 16:22:47 -0400 Subject: fix --- doc/todo/dependency_types.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 6d722aab9..215a65c8a 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -15,7 +15,7 @@ unnecessary page rebuilds: * brokenlinks, orphans, pagecount, ditto * inline in archive mode cares about page title, author changing, but not content. (Ditto for meta with show=title.) -* Causes extra work when solving the [[bug/transitive_dependencies]] +* Causes extra work when solving the [[bugs/transitive_dependencies]] problem. ### two types of dependencies needed for [[tracking_bugs_with_dependencies]] -- cgit v1.2.3 From 1d0d98eec4370f6daaf513f9553c5813e57e837e Mon Sep 17 00:00:00 2001 From: "http://jmtd.livejournal.com/" Date: Fri, 2 Oct 2009 17:30:46 -0400 Subject: wishlist/todo item: disable/enable directives by pagespec --- doc/todo/pagespec_to_disable_ikiwiki_directives.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/pagespec_to_disable_ikiwiki_directives.mdwn (limited to 'doc/todo') diff --git a/doc/todo/pagespec_to_disable_ikiwiki_directives.mdwn b/doc/todo/pagespec_to_disable_ikiwiki_directives.mdwn new file mode 100644 index 000000000..4211c2d10 --- /dev/null +++ b/doc/todo/pagespec_to_disable_ikiwiki_directives.mdwn @@ -0,0 +1,5 @@ +I would like some pages (identified by pagespec) to not expand ikiwiki directives (wikilinks, or \[[!, or both, or perhaps either). + +I will tag this [[wishlist]]. It's something I might try myself. It's part of my thinking about how to handle [[comments]], as I'm still ruminating on alternatives to [[smcv]]'s approach. (with the greatest of respect to smcv!) (Perhaps my attempt will try to factor out the no-directives-allowed logic from the comments plugin). + + -- [[Jon]] -- cgit v1.2.3 From 06a1ad7e760258eb0689e327825c15e2aa5234b2 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Fri, 2 Oct 2009 18:28:11 -0400 Subject: Add reference to new plugin --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn new file mode 100644 index 000000000..4cfbbbf3c --- /dev/null +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -0,0 +1,5 @@ +At the moment, IkiWiki allows you to set the template for individual pages using the [[plugins/pagetemplate]] directive/plugin, but not for whole sections of the wiki. + +I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch of my git repository that allows setting the template by pagespec in the config file. + +-- [[Will]] -- cgit v1.2.3 From db64972b65c7504b6d2bbed69e438203eef0a518 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 2 Oct 2009 18:51:52 -0400 Subject: combine with pagetemplate? --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn index 4cfbbbf3c..ed9740068 100644 --- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -3,3 +3,9 @@ At the moment, IkiWiki allows you to set the template for individual pages using I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch of my git repository that allows setting the template by pagespec in the config file. -- [[Will]] + +> This is an excellent idea and looks ready for merging. +> Before I do though, would it perhaps make sense to merge +> this in with the pagetemplate plugin? They do such a similar thing, +> and unless letting users control the template by editing a page is not +> wanted, I can't see any reason not to combine them. --[[Joey]] -- cgit v1.2.3 From 9673806a6d94b320bf2289dd091175a742bcee26 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 2 Oct 2009 18:58:07 -0400 Subject: consistency with edittemplate? --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn index ed9740068..b9c397358 100644 --- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -8,4 +8,10 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch > Before I do though, would it perhaps make sense to merge > this in with the pagetemplate plugin? They do such a similar thing, > and unless letting users control the template by editing a page is not -> wanted, I can't see any reason not to combine them. --[[Joey]] +> wanted, I can't see any reason not to combine them. --[[Joey]] + +> One other idea is moving the pagespec from setup file to a directive. +> The edittemplate plugin does that, and it might be nice +> to be consistent with that. To implement it, you'd have to +> make the scan hook store the template pagespecs in `%pagestate`, +> so a bit more complicated. --[[Joey]] -- cgit v1.2.3 From 5de7ba82911ee1ab966a755e97931d5b6a3bacb1 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Sat, 3 Oct 2009 01:39:06 -0400 Subject: response --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn index b9c397358..cd57c1257 100644 --- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -15,3 +15,11 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch > to be consistent with that. To implement it, you'd have to > make the scan hook store the template pagespecs in `%pagestate`, > so a bit more complicated. --[[Joey]] + +>> I started with the pagetemplate plugin, which is why they're so similar. I guess they could be combined. +>> I had a brief think about having the specs and templates defined in a directive rather than the config file, but it got tricky. +>> How do you know what needs to be rebuilt when? There is probably a solution, maybe even an obvious one, but I thought that getting something done was more important than polishing it. +>> In the worst case, admins can always use the web interface to change the setup :). + +>> I wanted this to put comments on my new blog, and was more interested in that goal than this subgoal. I've moved most of my web pages to IkiWiki and there is only one small part that is the blog. +>> I wanted to use [[Disqus comments|tips/Adding_Disqus_to_your_wiki/]], but only on the blog pages. (I'm using Disqus rather than IkiWiki comments because I don't want to have to deal with spam, security, etc. I'll happily just let someone else host the comments.) -- [[Will]] -- cgit v1.2.3 From bd958f91a2b71761e9aa20fa25a6702dab3b4b8d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 3 Oct 2009 17:38:47 -0400 Subject: did a scratch implementation of dependancy types, but found it more complex --- doc/todo/dependency_types.mdwn | 37 ++++++++++++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 215a65c8a..6218222f7 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -12,7 +12,7 @@ unnecessary page rebuilds: * meta only cares if the pages are added or removed. Content change does not matter (unless show=title is used). -* brokenlinks, orphans, pagecount, ditto +* brokenlinks, orphans, pagecount, ditto (generally) * inline in archive mode cares about page title, author changing, but not content. (Ditto for meta with show=title.) * Causes extra work when solving the [[bugs/transitive_dependencies]] @@ -109,9 +109,6 @@ I propose the following. --[[Joey]] * `add_depends` defaults to adding a regular ("full") dependency, as before. (So nothing breaks.) * `add_depends($page, $spec, content => 0)` adds an contentless dependency. -* Contentless dependencies are stored in `%depends_contentless` and - `%depends_contentless_simple`, which are stored in the index similarly - to the existing hashes. * `refresh` only looks at added/removed pages when resolving contentless dependencies. @@ -121,5 +118,35 @@ to the two types he talks about above, but I hope are close enough that they can be used. This doesn't deal with the stuff that only depend on the metadata of a -page, as collected in the scan pass, changing. But it does leave a window +page, as collected in the scan pass, changing. But it does leave a window open for adding such a dependency type later. + +---- + +I implemented the above in a branch. +[[!template id=gitbranch branch=origin/dependency-types author="[[joey]]"]] + +Then I found some problems: + +* pagestats is often used with a pagespec that uses `tagged()`. + A pure contentless dependency does not work for that, it needs to look + at link info. +* orphans and brokenlinks cannot use contentless dependencies because they + need to update when links change. +* Something simple like pagecount, that seems like it could use a + contentless dependency, can have a pagespec that uses metadata, like + `author()` or `copyright()`. + +Now I'm thinking about having a contentless dependency look at page +metadata, and fire if the metadata changes. And it seems links should +either be included in that, or there should be a way to make a dependency +that fires when a page's links change. (And what about backlinks?) + +It's easy to see when a page's links change, since there is `%oldlinks`. +To see when metadata is changed is harder, since it's stored in the +pagestate by the meta plugin. + +(Alternative: Make add_depends look at the pagespec. Ie, if it is a simple +page name, or a glob, we know a contentless dependency can be valid. +If's more complex, convert the dependency from contentless to full. Finding +a non-ad-hoc, non-sucky way to do that could be hard.) -- cgit v1.2.3 From ba11568f1e1e0b0da0490d817262f13539736262 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 3 Oct 2009 17:43:23 -0400 Subject: response --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn index cd57c1257..d0c09796f 100644 --- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -23,3 +23,9 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch >> I wanted this to put comments on my new blog, and was more interested in that goal than this subgoal. I've moved most of my web pages to IkiWiki and there is only one small part that is the blog. >> I wanted to use [[Disqus comments|tips/Adding_Disqus_to_your_wiki/]], but only on the blog pages. (I'm using Disqus rather than IkiWiki comments because I don't want to have to deal with spam, security, etc. I'll happily just let someone else host the comments.) -- [[Will]] + +>>> Yes, handing the rebuild is a good reason not to use directives for +>>> this. +>>> +>>> I do still think combining this with pagetemplate would be good. +>>> --[[Joey]] -- cgit v1.2.3 From 7b692b5d6ec2c1cf86b627c4e3ed7a5d0a751580 Mon Sep 17 00:00:00 2001 From: "http://kaizer.se/" Date: Sun, 4 Oct 2009 14:43:38 -0400 Subject: Updated pproc-indent by catching only indent at beginning of line --- ...esolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index e42f22970..ca7b282fa 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -271,6 +271,17 @@ Perl I've ever written!_) >>> Well, seems you want to match the indent at the start of the line containing >>> the directive, even if the directive does not start the line. That would >>> be quite hard to make a regexp do, though. --[[Joey]] +>> +>> I wasted a long time getting the simpler `indent($1, handle->($2,$,4))` to +>> work (remember, I don't know perl at all). Somehow `$1` does not arrive, I +>> made a simple testcase that worked, and I conclude something inside $handle +>> results in the value of $1 not arriving as it should! +>> +>> Anyway, instead a very simple incremental patch is in [pproc-indent][ppi] +>> where the indentation regex is `(^[ \t]+|)` instead, which seems to work +>> very well (and the regex is multiline now as well). I'm happy to rebase the +>> changes if you want or you can just squash the four patches 1+3 => 1+1 +>> -- [[ulrik]] [ppi]: http://github.com/engla/ikiwiki/commits/pproc-indent -- cgit v1.2.3 From 6f1ebdd6922a2c96fd57c71cd2052992d13f9c22 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 4 Oct 2009 15:53:54 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 6218222f7..58b5ee955 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -10,7 +10,7 @@ whenever a matching dependency is added, removed, or *modified*. But a great many things don't care about the modification case, and often cause unnecessary page rebuilds: -* meta only cares if the pages are added or removed. Content change does +* map only cares if the pages are added or removed. Content change does not matter (unless show=title is used). * brokenlinks, orphans, pagecount, ditto (generally) * inline in archive mode cares about page title, author changing, but @@ -128,14 +128,11 @@ I implemented the above in a branch. Then I found some problems: -* pagestats is often used with a pagespec that uses `tagged()`. - A pure contentless dependency does not work for that, it needs to look - at link info. -* orphans and brokenlinks cannot use contentless dependencies because they - need to update when links change. * Something simple like pagecount, that seems like it could use a contentless dependency, can have a pagespec that uses metadata, like `author()` or `copyright()`. +* pagestats, orphans and brokenlinks cannot use contentless dependencies + because they need to update when links change. Now I'm thinking about having a contentless dependency look at page metadata, and fire if the metadata changes. And it seems links should @@ -146,7 +143,14 @@ It's easy to see when a page's links change, since there is `%oldlinks`. To see when metadata is changed is harder, since it's stored in the pagestate by the meta plugin. -(Alternative: Make add_depends look at the pagespec. Ie, if it is a simple -page name, or a glob, we know a contentless dependency can be valid. -If's more complex, convert the dependency from contentless to full. Finding -a non-ad-hoc, non-sucky way to do that could be hard.) +Quick alternative: Make add_depends look at the pagespec. Ie, if it +is a simple page name, or a glob, we know a contentless dependency +can be valid. If's more complex, convert the dependency from +contentless to full. + +There is a lot to dislike about this method. Its parsing of the +pagespec, as currently implemented, does not let plugins add new types of +pagespecs that are contentless. Its pagespec parsing is also subject to +false negatives (though these should be somewhat rare, and no false +positives). Still, it does work, and it makes things like simple maps and +pagecounts much more efficient. -- cgit v1.2.3 From bcad00b0467c9435636dff3feb540d17fb2296d4 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 4 Oct 2009 20:35:26 -0400 Subject: update, add spec for link dependencies --- doc/todo/dependency_types.mdwn | 43 ++++++++++++++++++++++++++++++------------ 1 file changed, 31 insertions(+), 12 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 58b5ee955..f13f1448e 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -105,11 +105,11 @@ unnecessary page rebuilds: I propose the following. --[[Joey]] -* Add a second type of dependency, call it an "contentless dependency". +* Add a second type of dependency, call it an "presence dependency". * `add_depends` defaults to adding a regular ("full") dependency, as before. (So nothing breaks.) -* `add_depends($page, $spec, content => 0)` adds an contentless dependency. -* `refresh` only looks at added/removed pages when resolving contentless +* `add_depends($page, $spec, presence => 0)` adds an presence dependency. +* `refresh` only looks at added/removed pages when resolving presence dependencies. This seems straightforwardly doable. I'd like [[Will]]'s feedback on it, if @@ -129,28 +129,47 @@ I implemented the above in a branch. Then I found some problems: * Something simple like pagecount, that seems like it could use a - contentless dependency, can have a pagespec that uses metadata, like + presence dependency, can have a pagespec that uses metadata, like `author()` or `copyright()`. -* pagestats, orphans and brokenlinks cannot use contentless dependencies +* pagestats, orphans and brokenlinks cannot use presence dependencies because they need to update when links change. -Now I'm thinking about having a contentless dependency look at page +Now I'm thinking about having a special dependency look at page metadata, and fire if the metadata changes. And it seems links should either be included in that, or there should be a way to make a dependency that fires when a page's links change. (And what about backlinks?) It's easy to see when a page's links change, since there is `%oldlinks`. To see when metadata is changed is harder, since it's stored in the -pagestate by the meta plugin. +pagestate by the meta plugin. Also, there are many different types of +metadata, that would need to be matched with the pagespecs somehow. Quick alternative: Make add_depends look at the pagespec. Ie, if it -is a simple page name, or a glob, we know a contentless dependency +is a simple page name, or a glob, we know a presence dependency can be valid. If's more complex, convert the dependency from -contentless to full. +presence to full. -There is a lot to dislike about this method. Its parsing of the -pagespec, as currently implemented, does not let plugins add new types of -pagespecs that are contentless. Its pagespec parsing is also subject to +There is a lot to dislike about this method. Its parsing of the pagespec, +as currently implemented, does not let plugins add new types of pagespecs +that only care about presence. Its pagespec parsing is also subject to false negatives (though these should be somewhat rare, and no false positives). Still, it does work, and it makes things like simple maps and pagecounts much more efficient. + +---- + +Link dependencies: + +* `add_depends($page, $spec, links => 1, presence => 1)` + adds a links + presence dependency. +* `refresh` only rebuilds a page with a links dependency if + pages matched by the pagespec gain or lose links. (What the link + actually points to may change independent of this, due to changes + elsewhere, without it firing.) +* So, brokenlinks can fire whenever any links in any of the + pages it's tracking change, or when pages are added or + removed. + +TODO: How to determine if a pagespec is valid to be used with a links +dependency? Use the same simple pagespecs that are valid for presence +dependencies? -- cgit v1.2.3 From bccea01c07a112f4ded504724557085c870b56f6 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 5 Oct 2009 15:27:03 +0100 Subject: would you accept patches for this? --- doc/todo/CSS_classes_for_links.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/CSS_classes_for_links.mdwn b/doc/todo/CSS_classes_for_links.mdwn index 5013a9d12..43a480be8 100644 --- a/doc/todo/CSS_classes_for_links.mdwn +++ b/doc/todo/CSS_classes_for_links.mdwn @@ -75,3 +75,20 @@ I find CSS3 support still spotty... Here are some notes on how to do this in Ik > [[rel_attribute|rel_attribute_for_links]] now that CSS can use.) > > --[[Joey]] + +>> I had a little look at this, last weekend. I added a class definition to +>> the `htmllink` call in `linkify` in `link.pm`. It works pretty well, but +>> I'd also need to adjust other `htmllink` calls (map, inline, etc.). I found +>> other methods (CSS3 selectors, etc.) to be unreliable. +>> +>> Would you potentially accept a patch that added `class="internal"` to +>> various `htmllink` calls in ikiwiki? +>> +>> How configurable do you think this behaviour should be? I'm considering a +>> config switch to enable or disable this behaviour, or possibly a +>> configurable list of class names to append for internal links (defaulting +>> to an empty list for backwards compatibility)> +>> +>> As an alternative to patching the uses of `htmllink`, what do you think +>> about patching `htmllink` itself? Are there circumstances where it might be +>> used to generate a non-internal link? -- [[Jon]] -- cgit v1.2.3 From 61a36de432c58a8d7703b1ecc5d5704981e10e2d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 5 Oct 2009 15:40:18 -0400 Subject: closures --- doc/bugs/transitive_dependencies.mdwn | 2 +- doc/todo/dependency_types.mdwn | 9 ++++----- 2 files changed, 5 insertions(+), 6 deletions(-) (limited to 'doc/todo') diff --git a/doc/bugs/transitive_dependencies.mdwn b/doc/bugs/transitive_dependencies.mdwn index 9586bc9b0..0a2e9ec28 100644 --- a/doc/bugs/transitive_dependencies.mdwn +++ b/doc/bugs/transitive_dependencies.mdwn @@ -65,4 +65,4 @@ Downsides here: modification to plugins/brokenlinks causes an unnecessary update of plugins, and could be solved by adding more dependency types.) ---[[Joey]] +[[done]] --[[Joey]] diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index f13f1448e..f46a6a7c6 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -162,14 +162,13 @@ Link dependencies: * `add_depends($page, $spec, links => 1, presence => 1)` adds a links + presence dependency. -* `refresh` only rebuilds a page with a links dependency if - pages matched by the pagespec gain or lose links. (What the link - actually points to may change independent of this, due to changes - elsewhere, without it firing.) +* Use backlinks change code to detect changes to link dependencies too. * So, brokenlinks can fire whenever any links in any of the pages it's tracking change, or when pages are added or removed. TODO: How to determine if a pagespec is valid to be used with a links dependency? Use the same simple pagespecs that are valid for presence -dependencies? +dependencies? Seems ok. + +[[done]] -- cgit v1.2.3 From 4b2eaac156433d6e16b4b63660654bb26561b77f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 5 Oct 2009 16:18:54 -0400 Subject: response --- doc/todo/CSS_classes_for_links.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/CSS_classes_for_links.mdwn b/doc/todo/CSS_classes_for_links.mdwn index 43a480be8..38db87724 100644 --- a/doc/todo/CSS_classes_for_links.mdwn +++ b/doc/todo/CSS_classes_for_links.mdwn @@ -92,3 +92,12 @@ I find CSS3 support still spotty... Here are some notes on how to do this in Ik >> As an alternative to patching the uses of `htmllink`, what do you think >> about patching `htmllink` itself? Are there circumstances where it might be >> used to generate a non-internal link? -- [[Jon]] + +>>> I think that the minimum configurability to get something that +>>> can be used by CSS to style the links however the end user wants +>>> is the best thing to shoot for. Ideally, no configurability. And +>>> a tip or something documenting how to use the classes in your CSS +>>> to style links so that eg, external links have a warning icon. +>>> +>>> `htmllink` can never be used to generate an external link. So, +>>> patching it seems the best approach. --[[Joey]] -- cgit v1.2.3 From 9f4c5d2466b71d6a80fc1af3c1d0367aafde3112 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 5 Oct 2009 22:59:33 -0400 Subject: new todo --- doc/todo/cache_backlinks.mdwn | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/todo/cache_backlinks.mdwn (limited to 'doc/todo') diff --git a/doc/todo/cache_backlinks.mdwn b/doc/todo/cache_backlinks.mdwn new file mode 100644 index 000000000..dc13d464e --- /dev/null +++ b/doc/todo/cache_backlinks.mdwn @@ -0,0 +1,25 @@ +I'm thinking about caching the backlinks between runs. --[[Joey]] + +* It would save some time (spent resolving every single link + on every page, every run). The cached backlinks could be + updated by only updating backlinks from changed pages. + (Saved time is less than 1/10th of a second for docwiki.) + +* It may allow attacking [[bugs/bestlink_change_update_issue]], + since that seems to need a copy of the old backlinks. + Actually, just the next change will probably solve that: + +* It should allow removing the `%oldlink_targets`, `%backlinkchanged`, + and `%linkchangers` calculation code. Instead, just generate + a record of which pages' backlinks have changed when updating + the backlinks, and then rebuild those pages. + +Proposal: + +* Store a page's backlinks in the index, same as everything else. + +* Do *something* to generate or store the `%brokenlinks` data. + This is currently generated when calculating backlinks, and + is only used by the brokenlinks plugin. It's not the right + "shape" to be stored in the index, but could be changed around + to fit. -- cgit v1.2.3 From 348a6aaee3c13e0afababc4b9bb41743d7227f12 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 6 Oct 2009 18:20:11 -0400 Subject: pagespec for links dependencies --- doc/todo/dependency_types.mdwn | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index f46a6a7c6..19294bba0 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -166,9 +166,10 @@ Link dependencies: * So, brokenlinks can fire whenever any links in any of the pages it's tracking change, or when pages are added or removed. - -TODO: How to determine if a pagespec is valid to be used with a links -dependency? Use the same simple pagespecs that are valid for presence -dependencies? Seems ok. +* To determine if a pagespec is valid to be used with a links dependency, + use the same set that are valid for presence dependencies. But also + allow `backlinks()` to be used in it, since that matches pages + that the page links to, which is just what link dependencies are + triggered on. [[done]] -- cgit v1.2.3 From 0582365a56aedaee8dd53ec2f86ea189aff01a38 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 6 Oct 2009 20:19:17 -0400 Subject: notes on removal problem --- doc/todo/dependency_types.mdwn | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index f13f1448e..59ccc7591 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -158,7 +158,7 @@ pagecounts much more efficient. ---- -Link dependencies: +### Link dependencies * `add_depends($page, $spec, links => 1, presence => 1)` adds a links + presence dependency. @@ -173,3 +173,33 @@ Link dependencies: TODO: How to determine if a pagespec is valid to be used with a links dependency? Use the same simple pagespecs that are valid for presence dependencies? + +---- + +### the removal problem + +So far I have not addressed fixing the removal problem (which Will +discusses above). + +Summary of problem: A has a dependency on a pagespec such as +"bugs/* and !link(done)". B currently matches. Then B is updated, +in a way that makes A's dependency not match it (ie, it links to done). +Now A is not updated, because ikiwiki does not realize that it +depended on B before. + +This was worked around to fix [[bugs/inline_page_not_updated_on_removal]] +by inline and map adding explicit dependencies on each page that appears +on them. Then a change to B triggers the explicit dep. While this works, +it's 1) ugly 2) probably not implemented by all plugins that could +be affected by this problem (ie, linkmap) and 3) is most of the reason why +we grew the complication of `depends_simple`. + +One way to fix this is to include with each dependency, a list of pages +that currently match it. If the list changes, the dependency is triggered. + +Should be doable, but seems to involve a more work than +currently. Consider that a dependency on "bugs/*" currently +is triggered by just checking until *one* page is found to match it. +But to store the list, *every* page would have to be tried against it. +Unless the list can somehow be intelligently updated, looking at only the +changed pages. -- cgit v1.2.3 From d8607f5e73990e7802e03eef2065ebac102fbd2f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 6 Oct 2009 20:20:05 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 59ccc7591..7e940543c 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -169,10 +169,11 @@ pagecounts much more efficient. * So, brokenlinks can fire whenever any links in any of the pages it's tracking change, or when pages are added or removed. - -TODO: How to determine if a pagespec is valid to be used with a links -dependency? Use the same simple pagespecs that are valid for presence -dependencies? +* To determine if a pagespec is valid to be used with a links dependency, + use the same set that are valid for presence dependencies. But also + allow `backlinks()` to be used in it, since that matches pages + that the page links to, which is just what link dependencies are + triggered on. ---- -- cgit v1.2.3 From 3d609928e5d166897f26d2afe1b39e518f67a22c Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Wed, 7 Oct 2009 02:40:32 -0400 Subject: Comments (maybe not so helpful - sorry) --- doc/todo/dependency_types.mdwn | 61 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 7e940543c..0503b47af 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -156,6 +156,67 @@ false negatives (though these should be somewhat rare, and no false positives). Still, it does work, and it makes things like simple maps and pagecounts much more efficient. +---- + +#### Will's first pass feedback. + +If the API is going to be updated, then it would be good to make it forward compatible. +I'd like for the API to be extendible to what is useful for complex pagespecs, even if we +that is a little redundant at the moment. + +My attempt to play with this is in my git repo. [[!template id=gitbranch branch=origin/depends-spec author="[[will]]"]] +That branch is a little out of date, but if you just look at the changes in IkiWiki.pm you'll see the concept I was looking at. +I added an "add_depends_spec()" function that adds a dependency on the pagespec passed to it. If the set of matched pages +changes, then the dependent page is rebuilt. At the moment the implementation uses the same hack used by map and inline - +just add all the pages that currently exist as traditional content dependencies. + +Getting back to commenting on your proposal: + +Just talking about the definition of a "presence dependency" for the moment, and ignoring implementation. Is a +"presence dependency" supposed to cause an update when a page disappears? I assume so. Is a presence dependency +supposed to cause an update when a pages existence hasn't changed, but it no longer matches the pagespec. +(e.g. you use `created_before(test_page)` in a pagespec, and there was a page, `new_page`, that was created +after `test_page`. `new_page` will not match the spec. Now we'll delete and then re-create `test_page`. Now +`new_page` will match the spec, and yet `new_page` itself hasn't changed. Nor has its 'presence' - it was present +before and it is present now. Should this cause a re-build of any page that has a 'presence' dependency on the spec? + +I think that is another version of the problem you encountered with meta-data. + +In the longer term I was thinking we'd have to introduce a concept of 'internal pagespec dependencies'. Note that I'm +defining 'internal' pagespec dependencies differently to the pagespec dependencies I defined above. Perhaps an example: +If you had a pagespec that was `created_before(test_page)`, then you could list all pages created before `test_page` +with a `map` directive. The map directive would add a pagespec dependency on `created_before(test_page)`. +Internally, there would be a second page-spec parsing function that discovers which pages a given pagespec +depends on. As well as the function `match_created_before()`, we'd have to add a new function `depend_created_before()`. +This new function would return a list of pages, which when any of them change, the output of `match_created_before()` +would change. In this example, it would just return `test_page`. + +These lists of dependent pages could just be concatenated for every `match_...()` function in a pagespec - you can ignore +the boolean formula aspects of the pagespec for this. If a content dependency were added on these pages, then I think +the correct rebuilds would occur. + +In all, this is a surprisingly difficult problem to solve perfectly. Consider the following case: + +PageA.mdwn: + +> [ShavesSelf] + +PageB.mdwn + +> Doesn't shave self. + +ShavedByBob.mdwn: + +> [!include pages="!link(ShavesSelf)"] + +Does ShavedByBob.mdwn include itself? + +(Yeah - in IkiWiki currently links are included by include, but the idea holds. I had a good example a while back, but I can't think of it right now.) + +sigh. + +-- [[Will]] + ---- ### Link dependencies -- cgit v1.2.3 From 66e894c8771c5a5dfbd4cb92f826d4d397b2256f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Oct 2009 13:35:48 -0400 Subject: thoughts --- doc/todo/dependency_types.mdwn | 40 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 38 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 0503b47af..9d649e1e0 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -170,6 +170,11 @@ I added an "add_depends_spec()" function that adds a dependency on the pagespec changes, then the dependent page is rebuilt. At the moment the implementation uses the same hack used by map and inline - just add all the pages that currently exist as traditional content dependencies. +> As I note below, a problem with this approach is that it has to try +> matching the pagespec against every page, redundantly with the work done +> by the plugin. (But there are ways to avoid that redundant matching.) +> --[[Joey]] + Getting back to commenting on your proposal: Just talking about the definition of a "presence dependency" for the moment, and ignoring implementation. Is a @@ -180,6 +185,11 @@ after `test_page`. `new_page` will not match the spec. Now we'll delete and th `new_page` will match the spec, and yet `new_page` itself hasn't changed. Nor has its 'presence' - it was present before and it is present now. Should this cause a re-build of any page that has a 'presence' dependency on the spec? +> Yes, a presence dep will trigger when a page is added, or removed. + +> Your example is valid.. but it's also not handled right by normal, +> (content) dependencies, for the same reasons. --[[Joey]] + I think that is another version of the problem you encountered with meta-data. In the longer term I was thinking we'd have to introduce a concept of 'internal pagespec dependencies'. Note that I'm @@ -217,6 +227,19 @@ sigh. -- [[Will]] +> I have also been thinking about some sort of analysis pass over pagespecs +> to determine what metadata, pages, etc they depend on. It is indeed +> tricky to do. Even if it's just limited to returning a list of pages +> as you suggest. +> +> Consider: For a `*` glob, it has to return a list of all pages +> in the wiki. Which is expensive. And what if the pagespec is +> something like `* and backlink(index)`? Without analyising the +> boolean relationship between terms, the returned list +> will have many more items in it than it should. Or do we not make +> globs return their matches? (If so we have to deal with those +> with one of the other methods disucssed.) --[[Joey]] + ---- ### Link dependencies @@ -259,9 +282,22 @@ we grew the complication of `depends_simple`. One way to fix this is to include with each dependency, a list of pages that currently match it. If the list changes, the dependency is triggered. -Should be doable, but seems to involve a more work than +Should be doable, but may involve more work than currently. Consider that a dependency on "bugs/*" currently is triggered by just checking until *one* page is found to match it. But to store the list, *every* page would have to be tried against it. Unless the list can somehow be intelligently updated, looking at only the -changed pages. +changed pages. + +---- + +What if there were a function that added a dependency, and at the same time +returned a list of pages matching the pagespec? Plugins that use this would +be exactly the ones, like inline and map, for which this is a problem, and +which already do a match pass over all pages. + +Adding explicit dependencies during this pass would thus be nearly free. +Not 100% free since it would add explicit deps for things that are not +shown on an inline that limits its display to the first sorted N items. +I suppose we could reach 100% free by making the function also handle +sorting and limiting, though that could be overkill. -- cgit v1.2.3 From a09c79ccf1b9523c4b82db8846435c81f7404d44 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Oct 2009 14:25:45 -0400 Subject: problem with explicit, presence dependencies --- doc/todo/dependency_types.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 9d649e1e0..7714f2891 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -301,3 +301,22 @@ Not 100% free since it would add explicit deps for things that are not shown on an inline that limits its display to the first sorted N items. I suppose we could reach 100% free by making the function also handle sorting and limiting, though that could be overkill. + +---- + +Found a further complication in presence dependencies. Map now uses +presence dependencies when adding its explicit dependencies on pages. But +this defeats the purpose of the explicit dependencies! Because, now, +when B is changed to not match a pagespec, the A's presence dep does +not fire. + +I didn't think things through when switching it to use presense +dependencies there. But, if I change it to use full dependencies, then all +the work that was done to allow map to use presence dependencies for its +main pagespec is for naught. The map will once again have to update +whenever *any* content of the page changes. + +This points toward the conclusion that explicit dependencies, however they +are added, are not the right solution at all. Some other approach, such as +maintaining the list of pages that match a dependency, and noticing when it +changes, is needed. -- cgit v1.2.3 From 4e7e4e43065f7335c1aee1d36f2dd740543d1332 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Oct 2009 18:04:13 -0400 Subject: a theory of pagespec influence lists, for Will's perusal --- doc/todo/dependency_types.mdwn | 141 +++++++++++++++++++++++++++++++++-------- 1 file changed, 116 insertions(+), 25 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 7714f2891..dca873f34 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -188,7 +188,8 @@ before and it is present now. Should this cause a re-build of any page that has > Yes, a presence dep will trigger when a page is added, or removed. > Your example is valid.. but it's also not handled right by normal, -> (content) dependencies, for the same reasons. --[[Joey]] +> (content) dependencies, for the same reasons. Still, I think I've +> addressed it with the pagespec influence stuff below. --[[Joey]] I think that is another version of the problem you encountered with meta-data. @@ -229,16 +230,7 @@ sigh. > I have also been thinking about some sort of analysis pass over pagespecs > to determine what metadata, pages, etc they depend on. It is indeed -> tricky to do. Even if it's just limited to returning a list of pages -> as you suggest. -> -> Consider: For a `*` glob, it has to return a list of all pages -> in the wiki. Which is expensive. And what if the pagespec is -> something like `* and backlink(index)`? Without analyising the -> boolean relationship between terms, the returned list -> will have many more items in it than it should. Or do we not make -> globs return their matches? (If so we have to deal with those -> with one of the other methods disucssed.) --[[Joey]] +> tricky to do. More thoughts on influence lists a bit below. --[[Joey]] ---- @@ -291,26 +283,13 @@ changed pages. ---- -What if there were a function that added a dependency, and at the same time -returned a list of pages matching the pagespec? Plugins that use this would -be exactly the ones, like inline and map, for which this is a problem, and -which already do a match pass over all pages. - -Adding explicit dependencies during this pass would thus be nearly free. -Not 100% free since it would add explicit deps for things that are not -shown on an inline that limits its display to the first sorted N items. -I suppose we could reach 100% free by making the function also handle -sorting and limiting, though that could be overkill. - ----- - Found a further complication in presence dependencies. Map now uses presence dependencies when adding its explicit dependencies on pages. But this defeats the purpose of the explicit dependencies! Because, now, when B is changed to not match a pagespec, the A's presence dep does not fire. -I didn't think things through when switching it to use presense +I didn't think things through when switching it to use presence dependencies there. But, if I change it to use full dependencies, then all the work that was done to allow map to use presence dependencies for its main pagespec is for naught. The map will once again have to update @@ -320,3 +299,115 @@ This points toward the conclusion that explicit dependencies, however they are added, are not the right solution at all. Some other approach, such as maintaining the list of pages that match a dependency, and noticing when it changes, is needed. + +---- + +### pagespec influence lists + +I'm using this term for the concept of a list of pages whose modification +can indirectly influence what pages a pagespec matches. + +#### Examples + +* The pagespec "created_before(foo)" has an influence list that contains foo. + The removal or (re)creation of foo changes what pages match it. + +* The pagespec "foo" has an empty influence list. This is because a + modification/creation/removal of foo directly changes what the pagespec + matches. + +* The pagespec "*" has an empty influence list, for the same reason. + Avoiding including every page in the wiki into its influence list is + very important! + +* The pagespec "title(foo)" has an influence list that contains every page + that currently matches it. A change to any matching page can change its + title. Why is that considered an indirect influence? Well, the pagespec + might be used in a presence dependency, and so its title changing + would not directly affect the dependency. + +* The pagespec "backlink(index)" has an influence list + that contains index (because a change to index changes the backlinks). + +* The pagespec "link(done)" has an influence list that + contains every page that it matches. A change to any matching page can + remove a link and make it not match any more, and so the list is needed + due to the removal problem. + +#### Low-level Calculation + +One way to calculate a pagespec's influence would be to +expand the SuccessReason and FailReason objects used and returned +by `pagespec_match`. Make the objects be created with an +influence list included, and when the objects are ANDed or ORed +together, combine the influence lists. + +That would have the benefit of allowing just using the existing `match_*` +functions, with minor changes to a few of them to gather influence info. + +But does it work? Let's try some examples: + +Consider "bugs/* and link(done) and backlink(index)". + +Its influence list contains index, and it contains all pages that the whole +pagespec matches. It should, ideally, not contain all pages that link +to done. There are a lot of such pages, and only a subset influence this +pagespec. + +When matching this pagespec against a page, the `link` will put the page +on the list. The `backlink` will put index on the list, and they will be +anded together and combined. If we combine the influences from each +successful match, we get the right result. + +Now consider "bugs/* and link(done) and !backlink(index)". + +It influence list is the same as the previous one, even though a term has +been negated. Because a change to index still influences it, though in a +different way. + +If negation of a SuccessReason preserves the influence list, the right +influence list will be calculated. + +Consider "bugs/* and (link(done) or backlink(index))" +and "bugs/* and (backlink(index) or link(done))' + +Its clear that the influence lists for these are identical. And they +contain index, plus all matching pages. + +When matching the first against page P, the `link` will put P on the list. +The OR needs to be a non-short-circuiting type. (In perl, `or`, not `||` -- +so, `pagespec_translate` will need to be changed to not use `||`.) +Given that, the `backlink` will always be evalulated, and will put index +onto the influence list. If we combine the influences from each +successful match, we get the right result. + +#### High-level Calculation and Storage + +Calculating the full influence list for a pagespec requires trying to match +it against every page in the wiki. + +I'd like to avoid doing such expensive matching redundantly. So add a +`pagespec_match_all`, which returns a list of all pages in the whole +wiki that match the pagespec, and also adds the pagespec as a dependency, +and while it's at it, calculates and stores the influence list. + +It could have an optional sort parameter, and limit parameter, to control +how many items to return and the sort order. So when inline wants to +display the 10 newest, only the influence lists for those ten are added. + +If `pagespec_match_depends` can be used by all plugins, then great, +influences are automatically calculated, no extra work needs to be done. + +If not, and some plugins still need to use `pagespec_match_list` or +`pagespec_match`, and `add_depends`, then I guess that `add_depends` can do +a slightly more expensive influence calculation. + +Bonus: If `add_depends` is doing an influence calculation, then I can remove +the nasty hack it currently uses to decide if a given pagespec is safe to use +with an existence or links dependency. + +Where to store the influence list? Well, it appears that we can just add +(content) dependencies for each item on the list, to the page's +regular list of simple dependencies. So, the data stored ends up looking +just like what is stored today by the explicit dependency hacks. Except, +it's calculated more smartly, and is added automatically. -- cgit v1.2.3 From 43a8b40032c3774e0f5105ca5cbeb7a40fdc6893 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Oct 2009 20:36:25 -0400 Subject: influences calculation implemented --- doc/todo/dependency_types.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index dca873f34..a6260821e 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -381,6 +381,8 @@ Given that, the `backlink` will always be evalulated, and will put index onto the influence list. If we combine the influences from each successful match, we get the right result. +> This is implemented, seems to work ok. --[[Joey]] + #### High-level Calculation and Storage Calculating the full influence list for a pagespec requires trying to match -- cgit v1.2.3 From f7601954a862afd4c5a5b9ba83480af0472e1cf9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 7 Oct 2009 21:26:50 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index a6260821e..3bb1b5452 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -238,10 +238,7 @@ sigh. * `add_depends($page, $spec, links => 1, presence => 1)` adds a links + presence dependency. -* `refresh` only rebuilds a page with a links dependency if - pages matched by the pagespec gain or lose links. (What the link - actually points to may change independent of this, due to changes - elsewhere, without it firing.) +* Use backlinks change code to detect changes to link dependencies too. * So, brokenlinks can fire whenever any links in any of the pages it's tracking change, or when pages are added or removed. @@ -413,3 +410,14 @@ Where to store the influence list? Well, it appears that we can just add regular list of simple dependencies. So, the data stored ends up looking just like what is stored today by the explicit dependency hacks. Except, it's calculated more smartly, and is added automatically. + +> I've implemented influence calculation in `add_depends`. As expected, +> it means rather a lot more work, and makes some things much slower. +> Optimisation via `pagespec_match_depends` next.. --[[Joey]] + +#### Influence types + +Note that influences can also have types, same as dependency types. +For example, "backlink(foo)" has an influence of foo, of type links. +"created_before(foo)" also is influenced by foo, but it's a presence +type. Etc. -- cgit v1.2.3 From 61105cca4f219323a0b490e6251ac60abc549c2a Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Thu, 8 Oct 2009 01:33:23 -0400 Subject: Questions... --- doc/todo/dependency_types.mdwn | 29 ++++++++++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 3bb1b5452..01205f178 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -222,7 +222,7 @@ ShavedByBob.mdwn: Does ShavedByBob.mdwn include itself? -(Yeah - in IkiWiki currently links are included by include, but the idea holds. I had a good example a while back, but I can't think of it right now.) +(Yeah - in IkiWiki currently links are *not* included by include, but the idea holds. I had a good example a while back, but I can't think of it right now.) sigh. @@ -232,6 +232,10 @@ sigh. > to determine what metadata, pages, etc they depend on. It is indeed > tricky to do. More thoughts on influence lists a bit below. --[[Joey]] +>> The big part of what makes this tricky is that there may be cycles in the +>> dependency graph. This can lead to situations where the result is just not +>> well defined. This is what I was trying to get at above. -- [[Will]] + ---- ### Link dependencies @@ -304,6 +308,20 @@ changes, is needed. I'm using this term for the concept of a list of pages whose modification can indirectly influence what pages a pagespec matches. +> Trying to make a formal definition of this: (Note, I'm using the term sets rather than lists, but they're roughly equivalent) +> +> * Let the *matching set* for a pagespec be the set of pages that the pagespec matches. +> * Let a *complete influence set* for a pagespec be the set of all pages whose alteration might change the matching set of that pagespec. +> * Let the *direct influence set* be the intersection of the matching set and the complete influence set. +> * Let the *indirect influence set* be the compliment of the direct influence set with respect to the complete influence set. +> +> Is that a fair definition? I don't think it quite matches your examples below unfortunately. +> I was unsure if I should insert the word 'existing' in there in a few places. As it stands, these definitions could include sets of pages that don't exist, e.g. "*". +> The one I'm least sure of is the definition of the direct influence set. It feels like you want something +> like "the traditional set of things we thought about that could cause a pagespec to change", but that definition +> is not very formal and I suspect will lead to problems. Something like "The set of pages matched by the globs in the pagespec" might be closer? +> --[[Will]] + #### Examples * The pagespec "created_before(foo)" has an influence list that contains foo. @@ -331,6 +349,10 @@ can indirectly influence what pages a pagespec matches. remove a link and make it not match any more, and so the list is needed due to the removal problem. +>> Why doesn't this include every page? If I change a page that doesn't have a link to +>> 'done' to include a link to 'done', then it will now match... or is that considered a +>> 'direct match'? -- [[Will]] + #### Low-level Calculation One way to calculate a pagespec's influence would be to @@ -421,3 +443,8 @@ Note that influences can also have types, same as dependency types. For example, "backlink(foo)" has an influence of foo, of type links. "created_before(foo)" also is influenced by foo, but it's a presence type. Etc. + +> This is an interesting concept that I hadn't considered. It might +> allow significant computational savings, but I suspect will be tricky +> to implement. -- [[Will]] + -- cgit v1.2.3 From b91ccb4963fe7074b64cb538a2439d4cb9dad45e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 8 Oct 2009 04:06:53 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 57 ++++++++++++++++++++++++++++++++++-------- 1 file changed, 46 insertions(+), 11 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 01205f178..d3ffdf7b2 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -236,6 +236,9 @@ sigh. >> dependency graph. This can lead to situations where the result is just not >> well defined. This is what I was trying to get at above. -- [[Will]] +>>> Hmm, I'm not seeing cycles be a problem, at least with the current +>>> pagespec terms. --[[Joey]] + ---- ### Link dependencies @@ -322,6 +325,17 @@ can indirectly influence what pages a pagespec matches. > is not very formal and I suspect will lead to problems. Something like "The set of pages matched by the globs in the pagespec" might be closer? > --[[Will]] +>> I appreciate the formalism! +>> +>> Only existing pages need to be in these sets, because if a page is added +>> in the future, the existing dependency code will always test to see +>> if it matches. So it will be in the maching set (or not) at that point. +>> +>> The problem with your definition of direct influence set seems to be +>> that it doesn't allow `link()` and `title()` to have as an indirect +>> influence, the page that matches. But I'm quite sure we need those. +>> --[[Joey]] + #### Examples * The pagespec "created_before(foo)" has an influence list that contains foo. @@ -337,9 +351,8 @@ can indirectly influence what pages a pagespec matches. * The pagespec "title(foo)" has an influence list that contains every page that currently matches it. A change to any matching page can change its - title. Why is that considered an indirect influence? Well, the pagespec - might be used in a presence dependency, and so its title changing - would not directly affect the dependency. + title, making it not match any more, and so the list is needed due to the + removal problem. * The pagespec "backlink(index)" has an influence list that contains index (because a change to index changes the backlinks). @@ -353,6 +366,10 @@ can indirectly influence what pages a pagespec matches. >> 'done' to include a link to 'done', then it will now match... or is that considered a >> 'direct match'? -- [[Will]] +>>> The regular dependency calculation code will check if every changed +>>> page matches every dependency. So it will notice the link was added. +>>> --[[Joey]] + #### Low-level Calculation One way to calculate a pagespec's influence would be to @@ -404,13 +421,29 @@ successful match, we get the right result. #### High-level Calculation and Storage -Calculating the full influence list for a pagespec requires trying to match -it against every page in the wiki. - -I'd like to avoid doing such expensive matching redundantly. So add a -`pagespec_match_all`, which returns a list of all pages in the whole -wiki that match the pagespec, and also adds the pagespec as a dependency, -and while it's at it, calculates and stores the influence list. +Naively calculating the full influence list for a pagespec requires trying +to match it against every page in the wiki. I'd like to avoid doing such +expensive matching redundantly. + +It may be possible, for some types of pagespecs, to just try matching a +single, arbitrary page against it, and know the full influence list has +been obtained. It seems to be that case that if a pagespec has any +influences, matching any page will return at least one. So if none are +returned, we can skip trying other pages. + +If the influence list does not include the page that was tried, we know +that the pagespec does not things like `link()` and `title()`, that are +influenced by the page's own content. So it *might* be safe to not try +matching any more pages in this case too. I think it would work for all +current pagespec terms. There might be a hypothetical term where this +optimisation doesn't work. We could add a special case to ensure it can +work: If a term declares it is unfluenced by "", then it means it is +always influenced by the matching page. + +Anyway, this seems worth doing: Add a `pagespec_match_all`, which returns a +list of all pages in the whole wiki that match the pagespec, and also adds +the pagespec as a dependency, and while it's at it, calculates and stores +the influence list. It could have an optional sort parameter, and limit parameter, to control how many items to return and the sort order. So when inline wants to @@ -435,7 +468,7 @@ it's calculated more smartly, and is added automatically. > I've implemented influence calculation in `add_depends`. As expected, > it means rather a lot more work, and makes some things much slower. -> Optimisation via `pagespec_match_depends` next.. --[[Joey]] +> Optimisations next.. --[[Joey]] #### Influence types @@ -448,3 +481,5 @@ type. Etc. > allow significant computational savings, but I suspect will be tricky > to implement. -- [[Will]] +>> It was actually really easy to implement it, assuming I picked the right +>> dependency types of course. --[[Joey]] -- cgit v1.2.3 From 808c699961eae0de7125812d4f1c51ecd5fc6c18 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Thu, 8 Oct 2009 06:38:40 -0400 Subject: --- doc/todo/dependency_types.mdwn | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index d3ffdf7b2..97cff97c5 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -279,7 +279,7 @@ One way to fix this is to include with each dependency, a list of pages that currently match it. If the list changes, the dependency is triggered. Should be doable, but may involve more work than -currently. Consider that a dependency on "bugs/*" currently +currently. Consider that a dependency on `bugs/*` currently is triggered by just checking until *one* page is found to match it. But to store the list, *every* page would have to be tried against it. Unless the list can somehow be intelligently updated, looking at only the @@ -417,7 +417,10 @@ Given that, the `backlink` will always be evalulated, and will put index onto the influence list. If we combine the influences from each successful match, we get the right result. -> This is implemented, seems to work ok. --[[Joey]] +> This is implemented, seems to work ok. --[[Joey]] + +> `or` short-circuits too, but the implementation correctly uses `|`, +> which I assume is what you meant. --[[smcv]] #### High-level Calculation and Storage -- cgit v1.2.3 From 57d694046f6cd76543720615ba6913ed6dc96423 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Thu, 8 Oct 2009 07:26:01 -0400 Subject: Tweaks --- doc/todo/dependency_types.mdwn | 46 +++++++++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 9 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 97cff97c5..d31797f3d 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -239,6 +239,21 @@ sigh. >>> Hmm, I'm not seeing cycles be a problem, at least with the current >>> pagespec terms. --[[Joey]] +>>>> Oh, they're not with current pagespec terms. But this is really close to extending to handle +>>>> functional pagespecs, etc. And I think I'd like to think about that now. +>>>> +>>>> Having said that, I don't want to hold you up - you seem to be making progress. The best is +>>>> the enemy of the good, etc. etc. +>>>> +>>>> For my part, I'm imagining we have two more constructs in IkiWiki: +>>>> +>>>> * A map directive that actually wikilinks to the pages it links to, and +>>>> * A `match_sharedLink(pageX)` matching function that matches pageY if both pageX and pageY each have links to any same third page, pageZ. +>>>> +>>>> With those two constructs, one page changing might change the set of pages included in a map somewhere, which might then change the set of pages matched by some other pagespec, which might then... +>>>> +>>>> --[[Will]] + ---- ### Link dependencies @@ -313,16 +328,13 @@ can indirectly influence what pages a pagespec matches. > Trying to make a formal definition of this: (Note, I'm using the term sets rather than lists, but they're roughly equivalent) > -> * Let the *matching set* for a pagespec be the set of pages that the pagespec matches. -> * Let a *complete influence set* for a pagespec be the set of all pages whose alteration might change the matching set of that pagespec. -> * Let the *direct influence set* be the intersection of the matching set and the complete influence set. -> * Let the *indirect influence set* be the compliment of the direct influence set with respect to the complete influence set. +> * Let the *matching set* for a pagespec be the set of existing pages that the pagespec matches. +> * Let a *influence set* for a pagespec be the set of all pages, *p*, whose alteration might: +> * cause the pagespec to include or exclude a page other than *p*, or +> * cause the pagespec to exclude *p*. +> +>> \[Will snipped some stuff and edited the formal definition] > -> Is that a fair definition? I don't think it quite matches your examples below unfortunately. -> I was unsure if I should insert the word 'existing' in there in a few places. As it stands, these definitions could include sets of pages that don't exist, e.g. "*". -> The one I'm least sure of is the definition of the direct influence set. It feels like you want something -> like "the traditional set of things we thought about that could cause a pagespec to change", but that definition -> is not very formal and I suspect will lead to problems. Something like "The set of pages matched by the globs in the pagespec" might be closer? > --[[Will]] >> I appreciate the formalism! @@ -331,11 +343,24 @@ can indirectly influence what pages a pagespec matches. >> in the future, the existing dependency code will always test to see >> if it matches. So it will be in the maching set (or not) at that point. >> +>>> Hrm, I agree with you in general, but I think I can come up with nasty counter-examples. What about a pagespec +>>> of "!backlink(bogus)" where the page bogus doesn't exist? In this case, the page 'bogus' needs to be in the influence +>>> set even though it doesn't exist. +>>> +>>> Also, I would really like the formalism to include the whole dependency system, not just any additions to it. That will make +>>> the whole thing much easier to reason about. +>> >> The problem with your definition of direct influence set seems to be >> that it doesn't allow `link()` and `title()` to have as an indirect >> influence, the page that matches. But I'm quite sure we need those. >> --[[Joey]] +>>> I see what you mean. Does the revised definition capture this effectively? +>>> The problem with this revised definition is that it still doesn't match your examples below. +>>> My revised definition will include pretty much all currently matching pages to be in the influence list +>>> because deletion of any of them would cause a change in which pages are matched - the removal problem. +>>> -- [[Will]] + #### Examples * The pagespec "created_before(foo)" has an influence list that contains foo. @@ -349,6 +374,9 @@ can indirectly influence what pages a pagespec matches. Avoiding including every page in the wiki into its influence list is very important! +>>> So, why don't the above influence lists contain the currently matched pages? +>>> Don't you need this to handle the removal problem? -- [[Will]] + * The pagespec "title(foo)" has an influence list that contains every page that currently matches it. A change to any matching page can change its title, making it not match any more, and so the list is needed due to the -- cgit v1.2.3 From 3baf6980aa5725b647bf72452be2c05db1ad0bff Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 8 Oct 2009 13:54:51 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 55 ++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 53 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index d31797f3d..cce5997e8 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -254,6 +254,14 @@ sigh. >>>> >>>> --[[Will]] +>>>>> I think that should be supported by [[bugs/transitive_dependencies]]. +>>>>> At least in the current implementation, which considers each page +>>>>> that is rendered to be changed, and rebuilds pages that are dependent +>>>>> on it, in a loop. An alternate implementation, which could be faster, +>>>>> is to construct a directed graph and traverse it just once. Sounds +>>>>> like that would probably not support what you want to do. +>>>>> --[[Joey]] + ---- ### Link dependencies @@ -347,6 +355,13 @@ can indirectly influence what pages a pagespec matches. >>> of "!backlink(bogus)" where the page bogus doesn't exist? In this case, the page 'bogus' needs to be in the influence >>> set even though it doesn't exist. >>> +>>>> I think you're right, this is a case that the current code is not +>>>> handling. Actually, I made all the pagespecs return influences +>>>> even if the influence was not present or did not match. But, it +>>>> currently only records influences as dependencies when a pagespec +>>>> successfully matches. Now I'm sure that is wrong, and I've removed +>>>> that false optimisation. I've updated some of the below. --[[Joey]] +>>> >>> Also, I would really like the formalism to include the whole dependency system, not just any additions to it. That will make >>> the whole thing much easier to reason about. >> @@ -364,7 +379,8 @@ can indirectly influence what pages a pagespec matches. #### Examples * The pagespec "created_before(foo)" has an influence list that contains foo. - The removal or (re)creation of foo changes what pages match it. + The removal or (re)creation of foo changes what pages match it. Note that + this is true even if the pagespec currently fails to match. * The pagespec "foo" has an empty influence list. This is because a modification/creation/removal of foo directly changes what the pagespec @@ -377,13 +393,27 @@ can indirectly influence what pages a pagespec matches. >>> So, why don't the above influence lists contain the currently matched pages? >>> Don't you need this to handle the removal problem? -- [[Will]] +>>>> The removal problem is slightly confusingly named, since it does not +>>>> affect pages that were matched by a glob and have been removed. Such +>>>> pages can be handled without being influences, because ikiwiki knows +>>>> they have been removed, and so can still match them against the +>>>> pagespec, and see they used to match; and thus knows that the +>>>> dependency has triggered. +>>>> +>>>> Maybe the thing to do is consider this an optimisation, where such +>>>> pages are influences, but ikiwiki is able to implicitly find them, +>>>> so they do not need to be explicitly stored. --[[Joey]] + * The pagespec "title(foo)" has an influence list that contains every page that currently matches it. A change to any matching page can change its title, making it not match any more, and so the list is needed due to the - removal problem. + removal problem. A page that does not have a matching title is not an + influence, because modifying the page to change its title directly + changes what the pagespec matches. * The pagespec "backlink(index)" has an influence list that contains index (because a change to index changes the backlinks). + Note that this is true even if the backlink currently fails. * The pagespec "link(done)" has an influence list that contains every page that it matches. A change to any matching page can @@ -450,6 +480,27 @@ successful match, we get the right result. > `or` short-circuits too, but the implementation correctly uses `|`, > which I assume is what you meant. --[[smcv]] +>> Er, yeah. --[[Joey]] + +---- + +What about: "!link(done)" + +Specifically, I want to make sure it works now that I've changed +`match_link` to only return a page as an influence if it *does* +link to done. + +So, when matching against page P, that does not link to done, +there are no influences, and the pagespec matches. If P is later +changed to add a link to done, then the dependency resolver will directly +notice that. + +When matching against page P, that does link to done, P +is an influence, and the pagespec does not match. If P is later changed +to not link to done, the influence will do its job. + +Looks good! + #### High-level Calculation and Storage Naively calculating the full influence list for a pagespec requires trying -- cgit v1.2.3 From 3948b422381a0f05225aaf8b973d0cd54f089348 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 8 Oct 2009 15:33:47 -0400 Subject: found a way to get false positive influences --- doc/todo/dependency_types.mdwn | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index cce5997e8..56153239f 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -501,6 +501,34 @@ to not link to done, the influence will do its job. Looks good! +---- + +Here is a case where this approach has some false positives. + +"bugs/* and link(patch)" + +This finds as influences all pages that link to patch, even +if they are not under bugs/, and so can never match. + +To fix this, the influence calculation would need to consider boolean +operators. Currently, this turns into roughly: + +`FailReason() & SuccessReason(patch)` + +Let's say that the glob instead returns a HardFailReason, which when +ANDed with another object, drops their influences. (But when ORed, combines +them.) Fixes the above, but does it always work? + +"(bugs/* or link(patch)) and backlink(index)" => +`( HardFailReason() | SuccessReason(patch) ) & SuccessReason(index)`` => +`SuccessReason(patch) & SuccessReason(index)` => +SuccessReason(patch, index) => right + +"(bugs/* and link(patch)) or backlink(index)" => +`( HardFailReason() & SuccessReason(patch) ) | SuccessReason(index)`` => +`HardFailReason() | SuccessReason(index)` => +`SuccessReason(index)` => right + #### High-level Calculation and Storage Naively calculating the full influence list for a pagespec requires trying -- cgit v1.2.3 From 4b8ca7cfc147b2016b17cc88a21052a7ee6d46fb Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 8 Oct 2009 18:00:10 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 56153239f..f06603874 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -520,15 +520,19 @@ ANDed with another object, drops their influences. (But when ORed, combines them.) Fixes the above, but does it always work? "(bugs/* or link(patch)) and backlink(index)" => -`( HardFailReason() | SuccessReason(patch) ) & SuccessReason(index)`` => -`SuccessReason(patch) & SuccessReason(index)` => -SuccessReason(patch, index) => right +`( HardFailReason() | SuccessReason(page) ) & SuccessReason(index)`` => +`SuccessReason(page & SuccessReason(index)` => +SuccessReason(page, index) => right "(bugs/* and link(patch)) or backlink(index)" => -`( HardFailReason() & SuccessReason(patch) ) | SuccessReason(index)`` => +`( HardFailReason() & SuccessReason(page) ) | SuccessReason(index)`` => `HardFailReason() | SuccessReason(index)` => `SuccessReason(index)` => right +"!bugs/* and link(patch)" => +`HardFailReason() | SuccessReason(bugs/foo)` => +`HardFailReason()` => right + #### High-level Calculation and Storage Naively calculating the full influence list for a pagespec requires trying -- cgit v1.2.3 From a198c89e8f968549416d3871bddafa831240e6b8 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Thu, 8 Oct 2009 21:09:08 -0400 Subject: Minor comment --- doc/todo/dependency_types.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index f06603874..d2b121d81 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -262,6 +262,8 @@ sigh. >>>>> like that would probably not support what you want to do. >>>>> --[[Joey]] +>>>>>> Yes - that's what I'm talking about - I'll add some comments there. -- [[Will]] + ---- ### Link dependencies -- cgit v1.2.3 From 4299f22ae8b20f3cbc23876c8fac0a0856a164c2 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Thu, 8 Oct 2009 22:36:29 -0400 Subject: Another tweak to the formal definition. --- doc/todo/dependency_types.mdwn | 27 +++++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index d2b121d81..465796135 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -339,11 +339,25 @@ can indirectly influence what pages a pagespec matches. > Trying to make a formal definition of this: (Note, I'm using the term sets rather than lists, but they're roughly equivalent) > > * Let the *matching set* for a pagespec be the set of existing pages that the pagespec matches. -> * Let a *influence set* for a pagespec be the set of all pages, *p*, whose alteration might: +> * Let the *assignment dependent glob matching set* for a particular assignment of True/False to the `match_()` functions of a pagespec, be the set of pages that would match if the `match_()` functions returned those true/false values. +> * Let the *glob matching set* be the intersection of all assignment dependent glob matching sets. i.e. the set of pages that can match this pagespec just based on glob information, regardless of what the `match_()` functions return. +> * Let the *indirect influence set* for a pagespec be the set of all pages, *p*, whose alteration might: > * cause the pagespec to include or exclude a page other than *p*, or -> * cause the pagespec to exclude *p*. +> * cause the pagespec to exclude *p* unless *p* is in the glob matching set. > ->> \[Will snipped some stuff and edited the formal definition] +> Justification: The 'base dependency mechanism' is to compare changed pages against each pagespec. If the page matches, then rebuild the spec. For this comparison, creation and removal +> of pages are both considered changes. This base mechanism will catch: +> +> * The addition of any page to the matching set through its own modification/creation +> * The removal of any page *that would still match if it existed* from the matching set through its own removal. (Note: The base mechanism cannot remove a page cannot from the matching set because of that page's own modification. If the page should be removed, then cannot match the spec after the change.) This 'match after the change' criterion is what I tried to capture in the glob matching set above. I think my glob matching set is slightly more restrictive than the set of pages that 'still match after the change', but more restrictive is safer than less restrictive for that set. +> +> The base mechanism may therefore not catch: +> +> * The addition or removal of any page from the matching set through the modification/addition/removal of any other page. +> * The removal of any page from the matching set through its own modification/removal if it does not still match after the change. +> +> The indirect influence set then should handle anything that the base mechanism will not catch. +>> At the moment the indirect influence set is a little conservative, in that the glob matching set doesn't exactly equal the set of pages that still match after the change. It is quite hard to get this right - thoughts on tuning the glob matching set definition are welcome. I've tried to err on the side of a longer indirect influence set, as that will make sure we do enough updates. > > --[[Will]] @@ -380,10 +394,13 @@ can indirectly influence what pages a pagespec matches. #### Examples -* The pagespec "created_before(foo)" has an influence list that contains foo. +* The pagespec "created_before(foo)" has an indirect influence list that contains foo. The removal or (re)creation of foo changes what pages match it. Note that this is true even if the pagespec currently fails to match. +>>> This is an annoying example. I think the indirect influence list must contain 'foo' and all currently matching pages. `created_before(foo)` will not match +>>> a deleted page, and so the base mechanism would not cause a rebuild. The removal problem strikes. Note that the glob matching set is empty in this case. -- [[Will]] + * The pagespec "foo" has an empty influence list. This is because a modification/creation/removal of foo directly changes what the pagespec matches. @@ -402,6 +419,8 @@ can indirectly influence what pages a pagespec matches. >>>> pagespec, and see they used to match; and thus knows that the >>>> dependency has triggered. >>>> +>>>>> IkiWiki can only see that they used to match if they're in the glob matching set. -- [[Will]] +>>>> >>>> Maybe the thing to do is consider this an optimisation, where such >>>> pages are influences, but ikiwiki is able to implicitly find them, >>>> so they do not need to be explicitly stored. --[[Joey]] -- cgit v1.2.3 From 6533bec35af422d2db3b5b7347e883035fea6e99 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Thu, 8 Oct 2009 22:59:34 -0400 Subject: Yet another tweak to the formal definition. Much better this time. --- doc/todo/dependency_types.mdwn | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 465796135..9a031aac9 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -339,17 +339,17 @@ can indirectly influence what pages a pagespec matches. > Trying to make a formal definition of this: (Note, I'm using the term sets rather than lists, but they're roughly equivalent) > > * Let the *matching set* for a pagespec be the set of existing pages that the pagespec matches. -> * Let the *assignment dependent glob matching set* for a particular assignment of True/False to the `match_()` functions of a pagespec, be the set of pages that would match if the `match_()` functions returned those true/false values. -> * Let the *glob matching set* be the intersection of all assignment dependent glob matching sets. i.e. the set of pages that can match this pagespec just based on glob information, regardless of what the `match_()` functions return. +> * Let the *missing document matching set* be the set of pages that would match the spec if they didn't exist. These pages may or may not currently exist. Note that membership of this set depends upon how the `match_()` functions react to non-existant pages. > * Let the *indirect influence set* for a pagespec be the set of all pages, *p*, whose alteration might: > * cause the pagespec to include or exclude a page other than *p*, or -> * cause the pagespec to exclude *p* unless *p* is in the glob matching set. +> * cause the pagespec to exclude *p*, unless the alteration is the removal of *p* and *p* is in the missing document matching set. > > Justification: The 'base dependency mechanism' is to compare changed pages against each pagespec. If the page matches, then rebuild the spec. For this comparison, creation and removal > of pages are both considered changes. This base mechanism will catch: > > * The addition of any page to the matching set through its own modification/creation -> * The removal of any page *that would still match if it existed* from the matching set through its own removal. (Note: The base mechanism cannot remove a page cannot from the matching set because of that page's own modification. If the page should be removed, then cannot match the spec after the change.) This 'match after the change' criterion is what I tried to capture in the glob matching set above. I think my glob matching set is slightly more restrictive than the set of pages that 'still match after the change', but more restrictive is safer than less restrictive for that set. +> * The removal of any page *that would still match while non-existant* from the matching set through its own removal. (Note: The base mechanism cannot remove a page cannot from the matching set because of that page's own modification (not deletion). If the page should be removed matching set, then it obviously cannot match the spec after the change.) +> * The modification (not deletion) of any page that still matches after the modification. > > The base mechanism may therefore not catch: > @@ -357,7 +357,6 @@ can indirectly influence what pages a pagespec matches. > * The removal of any page from the matching set through its own modification/removal if it does not still match after the change. > > The indirect influence set then should handle anything that the base mechanism will not catch. ->> At the moment the indirect influence set is a little conservative, in that the glob matching set doesn't exactly equal the set of pages that still match after the change. It is quite hard to get this right - thoughts on tuning the glob matching set definition are welcome. I've tried to err on the side of a longer indirect influence set, as that will make sure we do enough updates. > > --[[Will]] @@ -398,8 +397,8 @@ can indirectly influence what pages a pagespec matches. The removal or (re)creation of foo changes what pages match it. Note that this is true even if the pagespec currently fails to match. ->>> This is an annoying example. I think the indirect influence list must contain 'foo' and all currently matching pages. `created_before(foo)` will not match ->>> a deleted page, and so the base mechanism would not cause a rebuild. The removal problem strikes. Note that the glob matching set is empty in this case. -- [[Will]] +>>> This is an annoying example (hence well worth having :) ). I think the indirect influence list must contain 'foo' and all currently matching pages. `created_before(foo)` will not match +>>> a deleted page, and so the base mechanism would not cause a rebuild. The removal problem strikes. -- [[Will]] * The pagespec "foo" has an empty influence list. This is because a modification/creation/removal of foo directly changes what the pagespec @@ -436,6 +435,9 @@ can indirectly influence what pages a pagespec matches. that contains index (because a change to index changes the backlinks). Note that this is true even if the backlink currently fails. +>>> This is another interesting example. The missing document matching set contains all links on the page index, and so +>>> the influence list only needs to contain 'index' itself. -- [[Will]] + * The pagespec "link(done)" has an influence list that contains every page that it matches. A change to any matching page can remove a link and make it not match any more, and so the list is needed -- cgit v1.2.3 From f977eaf39493984924b6ae9409be3e1d504fc0ae Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 9 Oct 2009 14:52:03 -0400 Subject: response --- doc/todo/dependency_types.mdwn | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 9a031aac9..6ca06fdab 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -348,7 +348,7 @@ can indirectly influence what pages a pagespec matches. > of pages are both considered changes. This base mechanism will catch: > > * The addition of any page to the matching set through its own modification/creation -> * The removal of any page *that would still match while non-existant* from the matching set through its own removal. (Note: The base mechanism cannot remove a page cannot from the matching set because of that page's own modification (not deletion). If the page should be removed matching set, then it obviously cannot match the spec after the change.) +> * The removal of any page *that would still match while non-existant* from the matching set through its own removal. (Note: The base mechanism cannot remove a page from the matching set because of that page's own modification (not deletion). If the page should be removed matching set, then it obviously cannot match the spec after the change.) > * The modification (not deletion) of any page that still matches after the modification. > > The base mechanism may therefore not catch: @@ -397,8 +397,16 @@ can indirectly influence what pages a pagespec matches. The removal or (re)creation of foo changes what pages match it. Note that this is true even if the pagespec currently fails to match. ->>> This is an annoying example (hence well worth having :) ). I think the indirect influence list must contain 'foo' and all currently matching pages. `created_before(foo)` will not match ->>> a deleted page, and so the base mechanism would not cause a rebuild. The removal problem strikes. -- [[Will]] +>>> This is an annoying example (hence well worth having :) ). I think the +>>> indirect influence list must contain 'foo' and all currently matching +>>> pages. `created_before(foo)` will not match +>>> a deleted page, and so the base mechanism would not cause a rebuild. The +>>> removal problem strikes. -- [[Will]] + +>>>> But `created_before` can in fact match a deleted page. Because the mtime +>>>> of a deleted page is temporarily set to 0 while the base mechanism runs to +>>>> find changes in deleted pages. (I verified this works by experiment, +>>>> also that `created_after` is triggered by a deleted page.) --[[Joey]] * The pagespec "foo" has an empty influence list. This is because a modification/creation/removal of foo directly changes what the pagespec -- cgit v1.2.3 From 2ba8bd386142e7f3c0fb03c86eb90eb3885aabd2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 9 Oct 2009 17:19:07 -0400 Subject: remove highlevel influence calculation stuff I have it implemented in both add_depends and pagespec_match_list. The add_depends implementation is optimised to only try one page if the pagespec's influences are all static, and do not vary by page matched. --- doc/todo/dependency_types.mdwn | 51 ------------------------------------------ 1 file changed, 51 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 6ca06fdab..e95965c33 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -564,57 +564,6 @@ SuccessReason(page, index) => right `HardFailReason() | SuccessReason(bugs/foo)` => `HardFailReason()` => right -#### High-level Calculation and Storage - -Naively calculating the full influence list for a pagespec requires trying -to match it against every page in the wiki. I'd like to avoid doing such -expensive matching redundantly. - -It may be possible, for some types of pagespecs, to just try matching a -single, arbitrary page against it, and know the full influence list has -been obtained. It seems to be that case that if a pagespec has any -influences, matching any page will return at least one. So if none are -returned, we can skip trying other pages. - -If the influence list does not include the page that was tried, we know -that the pagespec does not things like `link()` and `title()`, that are -influenced by the page's own content. So it *might* be safe to not try -matching any more pages in this case too. I think it would work for all -current pagespec terms. There might be a hypothetical term where this -optimisation doesn't work. We could add a special case to ensure it can -work: If a term declares it is unfluenced by "", then it means it is -always influenced by the matching page. - -Anyway, this seems worth doing: Add a `pagespec_match_all`, which returns a -list of all pages in the whole wiki that match the pagespec, and also adds -the pagespec as a dependency, and while it's at it, calculates and stores -the influence list. - -It could have an optional sort parameter, and limit parameter, to control -how many items to return and the sort order. So when inline wants to -display the 10 newest, only the influence lists for those ten are added. - -If `pagespec_match_depends` can be used by all plugins, then great, -influences are automatically calculated, no extra work needs to be done. - -If not, and some plugins still need to use `pagespec_match_list` or -`pagespec_match`, and `add_depends`, then I guess that `add_depends` can do -a slightly more expensive influence calculation. - -Bonus: If `add_depends` is doing an influence calculation, then I can remove -the nasty hack it currently uses to decide if a given pagespec is safe to use -with an existence or links dependency. - -Where to store the influence list? Well, it appears that we can just add -(content) dependencies for each item on the list, to the page's -regular list of simple dependencies. So, the data stored ends up looking -just like what is stored today by the explicit dependency hacks. Except, -it's calculated more smartly, and is added automatically. - -> I've implemented influence calculation in `add_depends`. As expected, -> it means rather a lot more work, and makes some things much slower. -> Optimisations next.. --[[Joey]] - #### Influence types Note that influences can also have types, same as dependency types. -- cgit v1.2.3 From a75591eaa772c1b875cca2d96b5015935a8617f3 Mon Sep 17 00:00:00 2001 From: "http://www.cse.unsw.edu.au/~willu/" Date: Fri, 9 Oct 2009 18:08:21 -0400 Subject: response --- doc/todo/dependency_types.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index e95965c33..1c2f579b3 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -408,6 +408,11 @@ can indirectly influence what pages a pagespec matches. >>>> find changes in deleted pages. (I verified this works by experiment, >>>> also that `created_after` is triggered by a deleted page.) --[[Joey]] +>>>>> Oh, okie. I looked at the source, saw the `if (exists $IkiWiki::pagectime{$testpage})` and assumed it would fail. +>>>>> Of course, having it succeed doesn't cure all the issues -- just moves them. With `created_before()` succeeding +>>>>> for deleted files, this pagespec will be match any removal in the entire wiki with the base mechanism. Whether this is +>>>>> better or worse than the longer indirect influence list is an empirical question. -- [[Will]] + * The pagespec "foo" has an empty influence list. This is because a modification/creation/removal of foo directly changes what the pagespec matches. -- cgit v1.2.3 From a169e7b6a81485a918992328f053d899e3614547 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 9 Oct 2009 20:30:22 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index bf6a76d87..da9b5e6cf 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -566,9 +566,16 @@ SuccessReason(page, index) => right `HardFailReason() | SuccessReason(index)` => `SuccessReason(index)` => right +Ok so far, but: + "!bugs/* and link(patch)" => -`HardFailReason() | SuccessReason(bugs/foo)` => -`HardFailReason()` => right +`!SuccessReason() | SuccessReason(bugs/foo)` => +'FailReason() | SuccessReason(bugs/foo) +`FailReason(bugs/foo)` => wrong! + +This could be fixed by adding a HardSuccessReason that glob also returns. +Maybe just a field of the object that is set if it is "hard" is a better +approach though. #### Influence types -- cgit v1.2.3 From 7e326ebfce89b7e81b361afacefa361fd8919586 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 13 Oct 2009 13:57:39 -0400 Subject: update --- doc/todo/dependency_types.mdwn | 26 ++++++++++---------------- 1 file changed, 10 insertions(+), 16 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/dependency_types.mdwn b/doc/todo/dependency_types.mdwn index 1c2f579b3..2bdf1d6a3 100644 --- a/doc/todo/dependency_types.mdwn +++ b/doc/todo/dependency_types.mdwn @@ -552,22 +552,16 @@ operators. Currently, this turns into roughly: `FailReason() & SuccessReason(patch)` Let's say that the glob instead returns a HardFailReason, which when -ANDed with another object, drops their influences. (But when ORed, combines -them.) Fixes the above, but does it always work? - -"(bugs/* or link(patch)) and backlink(index)" => -`( HardFailReason() | SuccessReason(page) ) & SuccessReason(index)`` => -`SuccessReason(page & SuccessReason(index)` => -SuccessReason(page, index) => right - -"(bugs/* and link(patch)) or backlink(index)" => -`( HardFailReason() & SuccessReason(page) ) | SuccessReason(index)`` => -`HardFailReason() | SuccessReason(index)` => -`SuccessReason(index)` => right - -"!bugs/* and link(patch)" => -`HardFailReason() | SuccessReason(bugs/foo)` => -`HardFailReason()` => right +ANDed with another object, blocks their influences. (But when ORed, +combines them.) + +Question: Are all pagespec terms that return reason objects w/o any +influence info, suitable to block influence in this way? + +To be suitable to block, a term should never change from failing to match a +page to successfully matching it, unless that page is directly changed in a +way that influences are not needed for ikiwiki to notice. But, if a term +did not meet these criteria, it would have an influence. QED. #### Influence types -- cgit v1.2.3 From c82ca7aa56d0902bfc44687d54df53f4fab402ad Mon Sep 17 00:00:00 2001 From: "http://schmonz.livejournal.com/" Date: Tue, 13 Oct 2009 20:56:29 -0400 Subject: point to "rsync" .htaccess trick --- doc/todo/enable-htaccess-files.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index e302a49ed..412cb5eba 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -59,3 +59,5 @@ It should be off by default of course. --Max --- +1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]] + +> I've described a workaround for one use case at the [[plugins/rsync]] [[plugins/rsync/discussion]] page. --[[schmonz]] -- cgit v1.2.3 From 07b28cfcf98c40d1c45276b18d09aab3fa491103 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 16 Oct 2009 11:24:21 +0200 Subject: TODO: How to preview changes before git://... commit. --- doc/todo/preview_changes_before_git_commit.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/todo/preview_changes_before_git_commit.mdwn (limited to 'doc/todo') diff --git a/doc/todo/preview_changes_before_git_commit.mdwn b/doc/todo/preview_changes_before_git_commit.mdwn new file mode 100644 index 000000000..e0e6ba866 --- /dev/null +++ b/doc/todo/preview_changes_before_git_commit.mdwn @@ -0,0 +1,7 @@ +ikiwiki allows to commit changes to the doc wiki over the `git://...` protocol. +It would be nice if there'd be a uniform way to view these changes before `git +push`ing. For the GNU Hurd's web pages, we include a *render_locally* script, +, with instructions on +, section +*Preview Changes*. With ikiwiki, one can use `make docwiki`, but that excludes +a set of pages, as per `docwiki.setup`. --[[tschwinge]] -- cgit v1.2.3 From d42f5ec009bff055ebf36feb972cde8e540673f8 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 16 Oct 2009 12:38:26 -0400 Subject: response --- doc/todo/preview_changes_before_git_commit.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/preview_changes_before_git_commit.mdwn b/doc/todo/preview_changes_before_git_commit.mdwn index e0e6ba866..187497cf4 100644 --- a/doc/todo/preview_changes_before_git_commit.mdwn +++ b/doc/todo/preview_changes_before_git_commit.mdwn @@ -5,3 +5,13 @@ push`ing. For the GNU Hurd's web pages, we include a *render_locally* script, , section *Preview Changes*. With ikiwiki, one can use `make docwiki`, but that excludes a set of pages, as per `docwiki.setup`. --[[tschwinge]] + +> `ikiwiki -setup some.setup --render file.mdwn` will build the page and +> dump it to stdout. So, for example: + + ikiwiki -setup docwiki.setup --render doc/todo/preview_changes_before_git_commit.mdwn | w3m -T text/html + +> You have to have a setup file, though it suffices to make up your own +> if you don't have the real one. Using ikiwiki.info's real setup file +> won't actually work since it uses a search plugin that gets unhappy +> if this is not in `/srv/web/ikiwiki.info`. --[[Joey]] -- cgit v1.2.3 From 13c93b1ab9a7ae3efb845b7fb73e34c94b912e3d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 16 Oct 2009 15:34:33 -0400 Subject: note that chrome fixes this nicely --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 4c9c2352a..0c45f0c90 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -10,7 +10,7 @@ On longer pages its not very comfortable to edit pages with such a small box. Th > } > > Perhaps you have replaced it with a modified style sheet that does not -> include that? --[[Joey]] [[!tag done]] +> include that? --[[Joey]] >> The screen shot was made with http://ikiwiki.info/ where i didn't change anything. The width is optimally used. The problem is the height. @@ -32,3 +32,9 @@ On longer pages its not very comfortable to edit pages with such a small box. Th >>> --[[Joey]] >>>>>> the javascript approach would need to work something like this: you need to know about the "bottom-most" item on the edit page, and get a handle for that object in the DOM. You can then obtain the absolute position height-wise of this element and the absolute position of the bottom of the window to determine the pixel-difference. Then, you set the height of the textarea to (current height in px) + determined-value. This needs to be re-triggered on various resize events, at least for the window and probably for other elements too. I may have a stab at this at some point. -- [[Jon]] + +Google chrome has a completly elegant fix for this problem: All textareas +have a small resize handle in a corner, that can be dragged around. No +nasty javascript needed. IMHO, this is the right solution, and I hope other +browsers emulate it. [[done]] +--[[Joey]] -- cgit v1.2.3 From ba7442b845d7857d69c77bcd512aa4e41dca4a22 Mon Sep 17 00:00:00 2001 From: "http://jmtd.livejournal.com/" Date: Fri, 23 Oct 2009 19:15:23 -0400 Subject: had a crack at this tonight --- doc/todo/allow_site-wide_meta_definitions.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 70ccc2b68..57bc7a6fd 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -72,3 +72,13 @@ my github ikiwiki fork): > by the fact that some (but not all!) meta headers are idempotent. > > --[[smcv]] + +>> Thanks for your comment. Tonight I had a go at implementing the syntax +>> you propose here. I decided the simplest thing to do might be for the scan +>> subroutine to convert any hashes found in the meta_defaults list into calls +>> to the preprocess routine. I've got a bit stuck trying to convert a hash to +>> a named parameter list (or just a subroutine parameter list that is). I may +>> try to look again in the morning (brain a bit sleepy) +>> +>> ...and on writing this comment I see your second suggestion was essentially +>> to do exactly that :) -- [[Jon]] -- cgit v1.2.3 From 9e4fa42676ddc6c8e73469bca52a66245845723c Mon Sep 17 00:00:00 2001 From: "http://jmtd.livejournal.com/" Date: Fri, 23 Oct 2009 19:48:04 -0400 Subject: progress --- doc/todo/allow_site-wide_meta_definitions.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 57bc7a6fd..f935a9acb 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -82,3 +82,14 @@ my github ikiwiki fork): >> >> ...and on writing this comment I see your second suggestion was essentially >> to do exactly that :) -- [[Jon]] + +>>> ok, it's easier than I thought, I just pass the hash and it's handled +>>> correctly. Right now can't figure out why my hashes get converted into +>>> strings prior to me seeing them in scan(): + + $VAR64 = [ + 'HASH(0xc2daf8)', + 'HASH(0xc2db40)' + ]; + +>>> ...but it *really* is bedtime :) -- [[Jon]] -- cgit v1.2.3 From de59a76e157936e6d95ed6474e188c0fdc353ee4 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 24 Oct 2009 16:49:37 +0100 Subject: update allow_site-wide_meta_definitions with last night's hacking --- doc/todo/allow_site-wide_meta_definitions.mdwn | 117 ++++++++++++++----------- 1 file changed, 66 insertions(+), 51 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index f935a9acb..3c6c3b5aa 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -5,11 +5,39 @@ I'd like to define [[plugins/meta]] values to apply across all pages site-wide unless the pages define their own: default values for meta definitions essentially. -Here's a patch to achieve this (also in the "defaultmeta" branch of -my github ikiwiki fork): + + +-- [[Jon]] + +> This doesn't support multiple-argument meta directives like +> `link=x rel=y`, or meta directives with special side-effects like +> `updated`. +> +> The first could be solved (if you care) by a syntax like this: +> +> meta_defaults => [ +> { copyright => "© me" }, +> { link => "about:blank", rel => "silly", }, +> ] +> +> The second could perhaps be solved by invoking `meta::preprocess` from within +> `scan` (which might be a simplification anyway), although this is complicated +> by the fact that some (but not all!) meta headers are idempotent. +> +> --[[smcv]] + +>> Thanks for your comment. I've revised the patch to use the config syntax +>> you suggest. I need to perform some more testing to make sure I've +>> addressed the issues you highlight. +>> +>> I had to patch part of IkiWiki core, the merge routine in Setup, because +>> the use of `possibly_foolish_untaint` was causing the hashrefs at the deep +>> end of the data structure to be converted into strings. The specific change +>> I've made may not be acceptable, though -- I'd appreciate someone providing +>> some feedback on that hunk! diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm - index b229592..3132257 100644 + index 6fe9cda..c4079fd 100644 --- a/IkiWiki/Plugin/meta.pm +++ b/IkiWiki/Plugin/meta.pm @@ -13,6 +13,7 @@ sub import { @@ -20,76 +48,63 @@ my github ikiwiki fork): } sub getsetup () { - @@ -302,6 +303,15 @@ sub match { + @@ -305,6 +306,17 @@ sub match { } } +sub scan() { + my %params = @_; + my $page = $params{page}; - + foreach my $type (map { s/^meta_//; $_ } grep /^meta_/, keys %config) { - + $pagestate{$page}{meta}{$type} = $config{"meta_$type"} - + unless defined $pagestate{$page}{meta}{$type}; + + if($config{"meta_defaults"}) { + + foreach my $default (@{$config{"meta_defaults"}}) { + + preprocess(%$default, page => $page, + + destpage => $page, preview => 0); + + } + } +} + package IkiWiki::PageSpec; sub match_title ($$;@) { + diff --git a/IkiWiki/Setup.pm b/IkiWiki/Setup.pm + index 8a25ecc..e4d50c9 100644 + --- a/IkiWiki/Setup.pm + +++ b/IkiWiki/Setup.pm + @@ -51,7 +51,13 @@ sub merge ($) { + $config{$c}=$setup{$c}; + } + else { + - $config{$c}=[map { IkiWiki::possibly_foolish_untaint($_) } @{$setup{$c}}] + + $config{$c}=[map { + + if(ref $_ eq 'HASH') { + + $_ + + } else { + + IkiWiki::possibly_foolish_untaint($_) + + } + + } @{$setup{$c}}]; + } + } + elsif (ref $setup{$c} eq 'HASH') { diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn - index 000f461..200c4b2 100644 + index 000f461..8d34ee4 100644 --- a/doc/ikiwiki/directive/meta.mdwn +++ b/doc/ikiwiki/directive/meta.mdwn - @@ -12,6 +12,12 @@ also specifies some additional sub-parameters. + @@ -12,6 +12,16 @@ also specifies some additional sub-parameters. The field values are treated as HTML entity-escaped text, so you can include a quote in the text by writing `"` and so on. +You can also define site-wide defaults for meta values by including them - +in your setup file, e.g. + +in your setup file. The key used is `meta_defaults` and the value is a list + +of hashes, one per meta directive. e.g.: + - + meta_copyright => "Copyright 2007 by Joey Hess", - + meta_license => "GPL v2+", + + meta_defaults = [ + + { copyright => "Copyright 2007 by Joey Hess" }, + + { license => "GPL v2+" }, + + { link => "somepage", rel => "site entrypoint", }, + + ], + Supported fields: * title --- [[Jon]] - -> This doesn't support multiple-argument meta directives like -> `link=x rel=y`, or meta directives with special side-effects like -> `updated`. -> -> The first could be solved (if you care) by a syntax like this: -> -> meta_defaults => [ -> { copyright => "© me" }, -> { link => "about:blank", rel => "silly", }, -> ] -> -> The second could perhaps be solved by invoking `meta::preprocess` from within -> `scan` (which might be a simplification anyway), although this is complicated -> by the fact that some (but not all!) meta headers are idempotent. -> -> --[[smcv]] - ->> Thanks for your comment. Tonight I had a go at implementing the syntax ->> you propose here. I decided the simplest thing to do might be for the scan ->> subroutine to convert any hashes found in the meta_defaults list into calls ->> to the preprocess routine. I've got a bit stuck trying to convert a hash to ->> a named parameter list (or just a subroutine parameter list that is). I may ->> try to look again in the morning (brain a bit sleepy) ->> ->> ...and on writing this comment I see your second suggestion was essentially ->> to do exactly that :) -- [[Jon]] - ->>> ok, it's easier than I thought, I just pass the hash and it's handled ->>> correctly. Right now can't figure out why my hashes get converted into ->>> strings prior to me seeing them in scan(): - - $VAR64 = [ - 'HASH(0xc2daf8)', - 'HASH(0xc2db40)' - ]; - ->>> ...but it *really* is bedtime :) -- [[Jon]] +>> -- [[Jon]] -- cgit v1.2.3 From 0c28536117d55fbc3a97ea59f1b37e5ef8807a34 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 24 Oct 2009 16:59:41 +0100 Subject: split the patch out of the page (and minor update it) --- doc/todo/allow_site-wide_meta_definitions.mdwn | 75 ++-------------------- .../current-patch.mdwn | 70 ++++++++++++++++++++ 2 files changed, 74 insertions(+), 71 deletions(-) create mode 100644 doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 3c6c3b5aa..3d506965f 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -36,75 +36,8 @@ definitions essentially. >> I've made may not be acceptable, though -- I'd appreciate someone providing >> some feedback on that hunk! - diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm - index 6fe9cda..c4079fd 100644 - --- a/IkiWiki/Plugin/meta.pm - +++ b/IkiWiki/Plugin/meta.pm - @@ -13,6 +13,7 @@ sub import { - hook(type => "needsbuild", id => "meta", call => \&needsbuild); - hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); - hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); - + hook(type => "scan", id => "meta", call => \&scan); - } - - sub getsetup () { - @@ -305,6 +306,17 @@ sub match { - } - } - - +sub scan() { - + my %params = @_; - + my $page = $params{page}; - + if($config{"meta_defaults"}) { - + foreach my $default (@{$config{"meta_defaults"}}) { - + preprocess(%$default, page => $page, - + destpage => $page, preview => 0); - + } - + } - +} - + - package IkiWiki::PageSpec; - - sub match_title ($$;@) { - diff --git a/IkiWiki/Setup.pm b/IkiWiki/Setup.pm - index 8a25ecc..e4d50c9 100644 - --- a/IkiWiki/Setup.pm - +++ b/IkiWiki/Setup.pm - @@ -51,7 +51,13 @@ sub merge ($) { - $config{$c}=$setup{$c}; - } - else { - - $config{$c}=[map { IkiWiki::possibly_foolish_untaint($_) } @{$setup{$c}}] - + $config{$c}=[map { - + if(ref $_ eq 'HASH') { - + $_ - + } else { - + IkiWiki::possibly_foolish_untaint($_) - + } - + } @{$setup{$c}}]; - } - } - elsif (ref $setup{$c} eq 'HASH') { - diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn - index 000f461..8d34ee4 100644 - --- a/doc/ikiwiki/directive/meta.mdwn - +++ b/doc/ikiwiki/directive/meta.mdwn - @@ -12,6 +12,16 @@ also specifies some additional sub-parameters. - The field values are treated as HTML entity-escaped text, so you can include - a quote in the text by writing `"` and so on. - - +You can also define site-wide defaults for meta values by including them - +in your setup file. The key used is `meta_defaults` and the value is a list - +of hashes, one per meta directive. e.g.: - + - + meta_defaults = [ - + { copyright => "Copyright 2007 by Joey Hess" }, - + { license => "GPL v2+" }, - + { link => "somepage", rel => "site entrypoint", }, - + ], - + - Supported fields: - - * title + +[[!inline pages="current-patch" raw=yes quick=yes]] + ->> -- [[Jon]] + -- [[Jon]] diff --git a/doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn b/doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn new file mode 100644 index 000000000..c5e37e76e --- /dev/null +++ b/doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn @@ -0,0 +1,70 @@ +diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm +index 6fe9cda..c4079fd 100644 +--- a/IkiWiki/Plugin/meta.pm ++++ b/IkiWiki/Plugin/meta.pm +@@ -13,6 +13,7 @@ sub import { + hook(type => "needsbuild", id => "meta", call => \&needsbuild); + hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); + hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); ++ hook(type => "scan", id => "meta", call => \&scan); + } + + sub getsetup () { +@@ -305,6 +306,17 @@ sub match { + } + } + ++sub scan() { ++ my %params = @_; ++ my $page = $params{page}; ++ if($config{"meta_defaults"}) { ++ foreach my $default (@{$config{"meta_defaults"}}) { ++ preprocess(%$default, page => $page, ++ destpage => $page, preview => 0); ++ } ++ } ++} ++ + package IkiWiki::PageSpec; + + sub match_title ($$;@) { +diff --git a/IkiWiki/Setup.pm b/IkiWiki/Setup.pm +index 8a25ecc..e4d50c9 100644 +--- a/IkiWiki/Setup.pm ++++ b/IkiWiki/Setup.pm +@@ -51,7 +51,13 @@ sub merge ($) { + $config{$c}=$setup{$c}; + } + else { +- $config{$c}=[map { IkiWiki::possibly_foolish_untaint($_) } @{$setup{$c}}] ++ $config{$c}=[map { ++ if(ref $_ eq 'HASH') { ++ $_ ++ } else { ++ IkiWiki::possibly_foolish_untaint($_) ++ } ++ } @{$setup{$c}}]; + } + } + elsif (ref $setup{$c} eq 'HASH') { +diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn +index 000f461..8d34ee4 100644 +--- a/doc/ikiwiki/directive/meta.mdwn ++++ b/doc/ikiwiki/directive/meta.mdwn +@@ -12,6 +12,16 @@ also specifies some additional sub-parameters. + The field values are treated as HTML entity-escaped text, so you can include + a quote in the text by writing `"` and so on. + ++You can also define site-wide defaults for meta values by including them ++in your setup file. The key used is `meta_defaults` and the value is a list ++of hashes, one per meta directive. e.g.: ++ ++ meta_defaults = [ ++ { copyright => "Copyright 2007 by Joey Hess" }, ++ { license => "GPL v2+" }, ++ { link => "somepage", rel => "site entrypoint", }, ++ ], ++ + Supported fields: + + * title -- cgit v1.2.3 From 6f84c0b5608ccf8faae52040d5ebbeb6b59fb063 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 24 Oct 2009 17:01:20 +0100 Subject: try to fix my inline --- doc/todo/allow_site-wide_meta_definitions.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 3d506965f..f56bf5c3c 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -37,7 +37,7 @@ definitions essentially. >> some feedback on that hunk! -[[!inline pages="current-patch" raw=yes quick=yes]] +[[!inline pages="allow site-wide meta definitions/current-patch" raw=yes quick=yes]] -- [[Jon]] -- cgit v1.2.3 From b474e61eee26c5f0f7c9537562a9d6c2be0ad68f Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 24 Oct 2009 17:22:01 +0100 Subject: try to fix my inline, second attempt --- doc/todo/allow_site-wide_meta_definitions.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index f56bf5c3c..2e8296640 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -37,7 +37,7 @@ definitions essentially. >> some feedback on that hunk! -[[!inline pages="allow site-wide meta definitions/current-patch" raw=yes quick=yes]] +[[!inline pages="allow_site-wide_meta_definitions/current-patch" raw=yes quick=yes]] -- [[Jon]] -- cgit v1.2.3 From 118058f0f530f0171fb625815aa0aae992e3f4b6 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 24 Oct 2009 17:23:52 +0100 Subject: give up and just inline the patch again --- doc/todo/allow_site-wide_meta_definitions.mdwn | 74 +++++++++++++++++++++- .../current-patch.mdwn | 70 -------------------- 2 files changed, 71 insertions(+), 73 deletions(-) delete mode 100644 doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 2e8296640..d95f8bf13 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -36,8 +36,76 @@ definitions essentially. >> I've made may not be acceptable, though -- I'd appreciate someone providing >> some feedback on that hunk! - -[[!inline pages="allow_site-wide_meta_definitions/current-patch" raw=yes quick=yes]] - + + diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm + index 6fe9cda..c4079fd 100644 + --- a/IkiWiki/Plugin/meta.pm + +++ b/IkiWiki/Plugin/meta.pm + @@ -13,6 +13,7 @@ sub import { + hook(type => "needsbuild", id => "meta", call => \&needsbuild); + hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); + hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); + + hook(type => "scan", id => "meta", call => \&scan); + } + + sub getsetup () { + @@ -305,6 +306,17 @@ sub match { + } + } + + +sub scan() { + + my %params = @_; + + my $page = $params{page}; + + if($config{"meta_defaults"}) { + + foreach my $default (@{$config{"meta_defaults"}}) { + + preprocess(%$default, page => $page, + + destpage => $page, preview => 0); + + } + + } + +} + + + package IkiWiki::PageSpec; + + sub match_title ($$;@) { + diff --git a/IkiWiki/Setup.pm b/IkiWiki/Setup.pm + index 8a25ecc..e4d50c9 100644 + --- a/IkiWiki/Setup.pm + +++ b/IkiWiki/Setup.pm + @@ -51,7 +51,13 @@ sub merge ($) { + $config{$c}=$setup{$c}; + } + else { + - $config{$c}=[map { IkiWiki::possibly_foolish_untaint($_) } @{$setup{$c}}] + + $config{$c}=[map { + + if(ref $_ eq 'HASH') { + + $_ + + } else { + + IkiWiki::possibly_foolish_untaint($_) + + } + + } @{$setup{$c}}]; + } + } + elsif (ref $setup{$c} eq 'HASH') { + diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn + index 000f461..8d34ee4 100644 + --- a/doc/ikiwiki/directive/meta.mdwn + +++ b/doc/ikiwiki/directive/meta.mdwn + @@ -12,6 +12,16 @@ also specifies some additional sub-parameters. + The field values are treated as HTML entity-escaped text, so you can include + a quote in the text by writing `"` and so on. + + +You can also define site-wide defaults for meta values by including them + +in your setup file. The key used is `meta_defaults` and the value is a list + +of hashes, one per meta directive. e.g.: + + + + meta_defaults = [ + + { copyright => "Copyright 2007 by Joey Hess" }, + + { license => "GPL v2+" }, + + { link => "somepage", rel => "site entrypoint", }, + + ], + + + Supported fields: + + * title -- [[Jon]] diff --git a/doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn b/doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn deleted file mode 100644 index c5e37e76e..000000000 --- a/doc/todo/allow_site-wide_meta_definitions/current-patch.mdwn +++ /dev/null @@ -1,70 +0,0 @@ -diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm -index 6fe9cda..c4079fd 100644 ---- a/IkiWiki/Plugin/meta.pm -+++ b/IkiWiki/Plugin/meta.pm -@@ -13,6 +13,7 @@ sub import { - hook(type => "needsbuild", id => "meta", call => \&needsbuild); - hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); - hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); -+ hook(type => "scan", id => "meta", call => \&scan); - } - - sub getsetup () { -@@ -305,6 +306,17 @@ sub match { - } - } - -+sub scan() { -+ my %params = @_; -+ my $page = $params{page}; -+ if($config{"meta_defaults"}) { -+ foreach my $default (@{$config{"meta_defaults"}}) { -+ preprocess(%$default, page => $page, -+ destpage => $page, preview => 0); -+ } -+ } -+} -+ - package IkiWiki::PageSpec; - - sub match_title ($$;@) { -diff --git a/IkiWiki/Setup.pm b/IkiWiki/Setup.pm -index 8a25ecc..e4d50c9 100644 ---- a/IkiWiki/Setup.pm -+++ b/IkiWiki/Setup.pm -@@ -51,7 +51,13 @@ sub merge ($) { - $config{$c}=$setup{$c}; - } - else { -- $config{$c}=[map { IkiWiki::possibly_foolish_untaint($_) } @{$setup{$c}}] -+ $config{$c}=[map { -+ if(ref $_ eq 'HASH') { -+ $_ -+ } else { -+ IkiWiki::possibly_foolish_untaint($_) -+ } -+ } @{$setup{$c}}]; - } - } - elsif (ref $setup{$c} eq 'HASH') { -diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn -index 000f461..8d34ee4 100644 ---- a/doc/ikiwiki/directive/meta.mdwn -+++ b/doc/ikiwiki/directive/meta.mdwn -@@ -12,6 +12,16 @@ also specifies some additional sub-parameters. - The field values are treated as HTML entity-escaped text, so you can include - a quote in the text by writing `"` and so on. - -+You can also define site-wide defaults for meta values by including them -+in your setup file. The key used is `meta_defaults` and the value is a list -+of hashes, one per meta directive. e.g.: -+ -+ meta_defaults = [ -+ { copyright => "Copyright 2007 by Joey Hess" }, -+ { license => "GPL v2+" }, -+ { link => "somepage", rel => "site entrypoint", }, -+ ], -+ - Supported fields: - - * title -- cgit v1.2.3 From 128e31d658b67411168775dcf8d9b9c9675e28cc Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Sat, 24 Oct 2009 17:27:48 +0100 Subject: inline the correct patch, and then go shopping --- doc/todo/allow_site-wide_meta_definitions.mdwn | 20 +++++++++----------- 1 file changed, 9 insertions(+), 11 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index d95f8bf13..20c8c02ac 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -36,31 +36,29 @@ definitions essentially. >> I've made may not be acceptable, though -- I'd appreciate someone providing >> some feedback on that hunk! - diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm - index 6fe9cda..c4079fd 100644 + index 6fe9cda..2f8c098 100644 --- a/IkiWiki/Plugin/meta.pm +++ b/IkiWiki/Plugin/meta.pm - @@ -13,6 +13,7 @@ sub import { + @@ -13,6 +13,8 @@ sub import { hook(type => "needsbuild", id => "meta", call => \&needsbuild); hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); - + hook(type => "scan", id => "meta", call => \&scan); + + hook(type => "scan", id => "meta", call => \&scan) + + if $config{"meta_defaults"}; } sub getsetup () { - @@ -305,6 +306,17 @@ sub match { + @@ -305,6 +307,15 @@ sub match { } } +sub scan() { + my %params = @_; + my $page = $params{page}; - + if($config{"meta_defaults"}) { - + foreach my $default (@{$config{"meta_defaults"}}) { - + preprocess(%$default, page => $page, - + destpage => $page, preview => 0); - + } + + foreach my $default (@{$config{"meta_defaults"}}) { + + preprocess(%$default, page => $page, + + destpage => $page, preview => 0); + } +} + @@ -108,4 +106,4 @@ definitions essentially. * title - -- [[Jon]] +-- [[Jon]] -- cgit v1.2.3 From a4693301c22e10fd8d521677bed276bbacfb0628 Mon Sep 17 00:00:00 2001 From: Smith Date: Tue, 27 Oct 2009 01:53:23 -0400 Subject: --- doc/todo/Gallery.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Gallery.mdwn b/doc/todo/Gallery.mdwn index f41980333..39316b86f 100644 --- a/doc/todo/Gallery.mdwn +++ b/doc/todo/Gallery.mdwn @@ -80,4 +80,4 @@ Additional details are available [here](http://myweb.unomaha.edu/~ajain/ikiwikig See also [[/users/smcv/gallery]] for another implementation of the same sort of thing. Unfortunately, none of the implementation ideas -I have there seem quite right either... --[[smcv]] +I have there seem quite right either... --[[smcv]] [http://www.pipiskmd.com/ khan] -- cgit v1.2.3 From 7034e3cafe267999104e2ab12ce0dea13473d2e0 Mon Sep 17 00:00:00 2001 From: Smith Date: Tue, 27 Oct 2009 01:58:10 -0400 Subject: --- doc/todo/Gallery.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Gallery.mdwn b/doc/todo/Gallery.mdwn index 39316b86f..5018d85c4 100644 --- a/doc/todo/Gallery.mdwn +++ b/doc/todo/Gallery.mdwn @@ -80,4 +80,4 @@ Additional details are available [here](http://myweb.unomaha.edu/~ajain/ikiwikig See also [[/users/smcv/gallery]] for another implementation of the same sort of thing. Unfortunately, none of the implementation ideas -I have there seem quite right either... --[[smcv]] [http://www.pipiskmd.com/ khan] +I have there seem quite right either... --[[smcv]] [Lightbox](http://www.asererogether.com) -- cgit v1.2.3 From b0bca45892415a09e5294539c3b8c2acc90a8d2b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 27 Oct 2009 02:06:23 -0400 Subject: Revert spam --- doc/soc/ideas.mdwn | 1 - doc/todo/Gallery.mdwn | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/soc/ideas.mdwn b/doc/soc/ideas.mdwn index 07c7e669e..88f06b0f1 100644 --- a/doc/soc/ideas.mdwn +++ b/doc/soc/ideas.mdwn @@ -6,4 +6,3 @@ but please don't add the `soc` tag yourself. [[!inline pages="(todo/* or bugs/*) and link(soc) and !todo/done and !link(todo/done) and !bugs/done and !link(bugs/done) and !*/Discussion" actions=yes show=0]] -[http://www.yaheodj.com/ khn] diff --git a/doc/todo/Gallery.mdwn b/doc/todo/Gallery.mdwn index 5018d85c4..f41980333 100644 --- a/doc/todo/Gallery.mdwn +++ b/doc/todo/Gallery.mdwn @@ -80,4 +80,4 @@ Additional details are available [here](http://myweb.unomaha.edu/~ajain/ikiwikig See also [[/users/smcv/gallery]] for another implementation of the same sort of thing. Unfortunately, none of the implementation ideas -I have there seem quite right either... --[[smcv]] [Lightbox](http://www.asererogether.com) +I have there seem quite right either... --[[smcv]] -- cgit v1.2.3 From f1558020131a3fc6d0d611441a12a5598e4b917f Mon Sep 17 00:00:00 2001 From: simonraven Date: Tue, 27 Oct 2009 04:17:01 -0400 Subject: --- doc/todo/Support_XML-RPC-based_blogging.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Support_XML-RPC-based_blogging.mdwn b/doc/todo/Support_XML-RPC-based_blogging.mdwn index f9685be73..6a0593b17 100644 --- a/doc/todo/Support_XML-RPC-based_blogging.mdwn +++ b/doc/todo/Support_XML-RPC-based_blogging.mdwn @@ -9,6 +9,9 @@ blog names would work. --[[JoshTriplett]] >> I'd love to see support for this and would be happy to contribute towards a bounty (say US$100) :-). [PmWiki](http://www.pmwiki.org/) has a plugin which [implements this](http://www.pmwiki.org/wiki/Cookbook/XMLRPC) in a way which seems fairly sensible as an end user. --[[AdamShand]] +>>> Bump. This would be a nice feature, and with the talent on this project I'm sure it could be done safely, too. + + [[!tag soc]] [[!tag wishlist]] -- cgit v1.2.3 From ae7591fd18e4d96666971b8f5707dafd62b8d1e2 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 29 Oct 2009 10:15:49 -0400 Subject: thoughts --- doc/todo/OpenSearch.mdwn | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/OpenSearch.mdwn b/doc/todo/OpenSearch.mdwn index e63ded688..c35da54e1 100644 --- a/doc/todo/OpenSearch.mdwn +++ b/doc/todo/OpenSearch.mdwn @@ -15,4 +15,24 @@ contain the wiki title from `ikiwiki.setup`. --[[JoshTriplett]] +> I support adding this. I think all that is needed, beyond the simple task +> of adding the link header, is to make the search plugin write out +> the xml file, probably based on a template. +> +> One problem is that the +> [specification](http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_document) +> for the XML file contains a number of silly limits to field lenghs. +> For example, it wants a "ShortName" that identifies the search engine, +> to be 16 characters or less. The Description is limited to 1024, +> the LongName to 48. This limits what existing config settings can be +> reused for those. +> +> Another semi-problem is that the specification saz: +> +>> OpenSearch description documents should include at least one Query element of role="example" that is expected to return search results. Search clients may use this example query to validate that the search engine is working properly. +> +> How should ikiwiki know what example query will return actual results? +> (How would a client know if a HTML page contains results or not, anyway?) +> Sillyness. Ignore this? --[[Joey]] + [[wishlist]] -- cgit v1.2.3 From 35319202724cbca495b13143b85578b892de0d05 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 9 Nov 2009 21:04:05 +0000 Subject: comment about patch version --- doc/todo/allow_site-wide_meta_definitions.mdwn | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 20c8c02ac..18508255e 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -107,3 +107,25 @@ definitions essentially. * title -- [[Jon]] + +>> Ok, I've had a bit of a think about this. There are currently 15 supported +>> meta fields. Of these: title, licence, copyright, author, authorurl, +>> and robots might make sense to define globally and override on a per-page +>> basis. +>> +>> Less so, description (due to its impact on map); openid (why would +>> someone want more than one URI to act as an openid endpoint, delegating +>> to the same place?); updated. +>> +>> Not useful are permalink, date, stylesheet (you already have a global +>> stylesheet), link, redir, guid, updated. +>> +>> In other words, the limitations of my first patch that [[smcv]] outlined +>> are only relevant to defined fields that you wouldn't want to specify a +>> global default for anyway. +>> +>> Due to this, and the added complexity of the second patch (having to adjust +>> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus +>> reverted to it here. +>> +>> --[[Jon]] -- cgit v1.2.3 From 6fead140d810c5e5e90b1be6fb9d1ada97a96ab8 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 9 Nov 2009 21:05:32 +0000 Subject: adjustments to my comment --- doc/todo/allow_site-wide_meta_definitions.mdwn | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 18508255e..9da0dddf8 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -114,11 +114,12 @@ definitions essentially. >> basis. >> >> Less so, description (due to its impact on map); openid (why would ->> someone want more than one URI to act as an openid endpoint, delegating ->> to the same place?); updated. +>> someone want more than one URI to act as an openid endpoint to the same +>> place?); updated. I can almost see why someone might want to set a global +>> updated value. Almost. >> >> Not useful are permalink, date, stylesheet (you already have a global ->> stylesheet), link, redir, guid, updated. +>> stylesheet), link, redir, and guid. >> >> In other words, the limitations of my first patch that [[smcv]] outlined >> are only relevant to defined fields that you wouldn't want to specify a -- cgit v1.2.3 From 31244492a5350dfce50d15d98841b358da41ffa8 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 9 Nov 2009 21:08:00 +0000 Subject: restore my original patch --- doc/todo/allow_site-wide_meta_definitions.mdwn | 50 ++++++++++++++++++++++++-- 1 file changed, 48 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 9da0dddf8..8b9c3dca9 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -128,5 +128,51 @@ definitions essentially. >> Due to this, and the added complexity of the second patch (having to adjust >> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus >> reverted to it here. ->> ->> --[[Jon]] + + diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm + index b229592..3132257 100644 + --- a/IkiWiki/Plugin/meta.pm + +++ b/IkiWiki/Plugin/meta.pm + @@ -13,6 +13,7 @@ sub import { + hook(type => "needsbuild", id => "meta", call => \&needsbuild); + hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); + hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); + + hook(type => "scan", id => "meta", call => \&scan); + } + + sub getsetup () { + @@ -302,6 +303,15 @@ sub match { + } + } + + +sub scan() { + + my %params = @_; + + my $page = $params{page}; + + foreach my $type (map { s/^meta_//; $_ } grep /^meta_/, keys %config) { + + $pagestate{$page}{meta}{$type} = $config{"meta_$type"} + + unless defined $pagestate{$page}{meta}{$type}; + + } + +} + + + package IkiWiki::PageSpec; + + sub match_title ($$;@) { + diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn + index 000f461..200c4b2 100644 + --- a/doc/ikiwiki/directive/meta.mdwn + +++ b/doc/ikiwiki/directive/meta.mdwn + @@ -12,6 +12,12 @@ also specifies some additional sub-parameters. + The field values are treated as HTML entity-escaped text, so you can include + a quote in the text by writing `"` and so on. + + +You can also define site-wide defaults for meta values by including them + +in your setup file, e.g. + + + + meta_copyright => "Copyright 2007 by Joey Hess", + + meta_license => "GPL v2+", + + + Supported fields: + + * title + +-- [[Jon]] -- cgit v1.2.3 From beb8c7444e97320a1757ccbfa21602beb34fc243 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Wed, 11 Nov 2009 19:06:00 +0000 Subject: is this merge-worthy? --- doc/todo/allow_site-wide_meta_definitions.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 8b9c3dca9..62317ba1a 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -128,6 +128,8 @@ definitions essentially. >> Due to this, and the added complexity of the second patch (having to adjust >> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus >> reverted to it here. +>> +>> Is this merge-worthy? diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm index b229592..3132257 100644 -- cgit v1.2.3 From 074d2c27f89693579c6e1b019a2a7b276e56be0e Mon Sep 17 00:00:00 2001 From: "http://jmtd.livejournal.com/" Date: Thu, 12 Nov 2009 09:40:33 -0500 Subject: optionally customize the commit message for rename/remove --- doc/todo/adjust_commit_message_for_rename__44___remove.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/adjust_commit_message_for_rename__44___remove.mdwn (limited to 'doc/todo') diff --git a/doc/todo/adjust_commit_message_for_rename__44___remove.mdwn b/doc/todo/adjust_commit_message_for_rename__44___remove.mdwn new file mode 100644 index 000000000..3d0d1aff4 --- /dev/null +++ b/doc/todo/adjust_commit_message_for_rename__44___remove.mdwn @@ -0,0 +1,5 @@ +When you rename or remove pages using the relevant plugins, a commit message is generated automatically by the plugin. + +It would be nice to provide a text field in the remove/rename form, pre-populated with the automatic message, so that a user may customize or append to the message (modulo VCS support) + +-- [[Jon]] -- cgit v1.2.3 From 2bd6ebb42ce3e7a91866f6731563926b09e7806f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 13 Nov 2009 15:31:34 -0500 Subject: move to todo item, some thoughtS --- doc/ikiwiki/pagespec/attachment/discussion.mdwn | 3 --- ...avoid_attachement_ui_if_upload_not_allowed.mdwn | 25 ++++++++++++++++++++++ 2 files changed, 25 insertions(+), 3 deletions(-) create mode 100644 doc/todo/avoid_attachement_ui_if_upload_not_allowed.mdwn (limited to 'doc/todo') diff --git a/doc/ikiwiki/pagespec/attachment/discussion.mdwn b/doc/ikiwiki/pagespec/attachment/discussion.mdwn index 34f21f84a..373242b3f 100644 --- a/doc/ikiwiki/pagespec/attachment/discussion.mdwn +++ b/doc/ikiwiki/pagespec/attachment/discussion.mdwn @@ -13,6 +13,3 @@ I am interested for [[todo/mbox]] --[[DavidBremner]] >> them. --[[DavidBremner]] >>> Done, [[plugins/filecheck]] --[[Joey]] - - -Any way to make it so an edit page doesn't offer the attachment capability unless it matches a specific user, is an admin, and/or is an allowed page? (For now, I have it on all pages, and then it prohibits after I submit based on the allowed_attachments.) diff --git a/doc/todo/avoid_attachement_ui_if_upload_not_allowed.mdwn b/doc/todo/avoid_attachement_ui_if_upload_not_allowed.mdwn new file mode 100644 index 000000000..487915850 --- /dev/null +++ b/doc/todo/avoid_attachement_ui_if_upload_not_allowed.mdwn @@ -0,0 +1,25 @@ +Any way to make it so an edit page doesn't offer the attachment capability +unless it matches a specific user, is an admin, and/or is an allowed page? +(For now, I have it on all pages, and then it prohibits after I submit +based on the allowed_attachments.) + +> To do that, ikiwiki would have to try to match the `allowed_attachments` +> pagespec against a sort of dummy upload to the current page. Then if it +> failed, assume all real uploads would fail. Now consider a pagespec like +> "user(joey) and mimetype(audio/mpeg)" -- it'd be hard to make a dummy +> upload to test this pagespec against. +> +> So, there would need to be some sort of test mode, where terms like +> `mimetype()` always succeed. But then consider a pagespec like +> "user(joey) and !mimetype(video/mpeg)" -- if mimetype succeeds, this +> fails. +> +> So, maybe we can instead just filter out all the pagespec terms aside +> from `user()`, `ip()`, and `admin()`. Transforming that into just +> "user(joey)", which would succeed in the test. +> +> That'd work, I guess. Pulling a pagespec apart, filtering out terms, and +> putting it back together is nontrivial, but doable. +> +> Other approach would be to have a separate pagespec that explicitly +> controlls what pages to show the attachment UI on. --[[Joey]] -- cgit v1.2.3 From dbc18a7223da6d2cdd5ae72ef5cb6afeb64352a5 Mon Sep 17 00:00:00 2001 From: NicolasLimare Date: Sun, 15 Nov 2009 20:19:34 -0500 Subject: + micro whishlist item --- doc/todo/description_meta_param_passed_to_templates.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/description_meta_param_passed_to_templates.mdwn (limited to 'doc/todo') diff --git a/doc/todo/description_meta_param_passed_to_templates.mdwn b/doc/todo/description_meta_param_passed_to_templates.mdwn new file mode 100644 index 000000000..cbd35f17d --- /dev/null +++ b/doc/todo/description_meta_param_passed_to_templates.mdwn @@ -0,0 +1,8 @@ +[[!tag whishlist]] + +I'd like to use the description parameter from [[meta|/ikiwiki/directive/meta]] directives in custom [[inline|/ikiwiki/directive/inline]] templates. I guess this could be useful to others too. + +The only change required is on [line 266](http://github.com/joeyh/ikiwiki/blob/master/IkiWiki/Plugin/meta.pm#L266) of `meta.pm` + + - foreach my $field (qw{author authorurl permalink}) { + + foreach my $field (qw{author authorurl description permalink}) { -- cgit v1.2.3 From fa7fd79ff0396b1d7b9eca6d3ae493c7092e9950 Mon Sep 17 00:00:00 2001 From: NicolasLimare Date: Sun, 15 Nov 2009 20:21:04 -0500 Subject: - typo --- doc/todo/description_meta_param_passed_to_templates.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/description_meta_param_passed_to_templates.mdwn b/doc/todo/description_meta_param_passed_to_templates.mdwn index cbd35f17d..5598698d7 100644 --- a/doc/todo/description_meta_param_passed_to_templates.mdwn +++ b/doc/todo/description_meta_param_passed_to_templates.mdwn @@ -1,4 +1,4 @@ -[[!tag whishlist]] +[[!tag wishlist]] I'd like to use the description parameter from [[meta|/ikiwiki/directive/meta]] directives in custom [[inline|/ikiwiki/directive/inline]] templates. I guess this could be useful to others too. -- cgit v1.2.3 From 6d73c132804b2c725cea257f5b55e5d438ec5640 Mon Sep 17 00:00:00 2001 From: NicolasLimare Date: Sun, 15 Nov 2009 20:22:21 -0500 Subject: + patch tag --- doc/todo/description_meta_param_passed_to_templates.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/description_meta_param_passed_to_templates.mdwn b/doc/todo/description_meta_param_passed_to_templates.mdwn index 5598698d7..80a6a8e8a 100644 --- a/doc/todo/description_meta_param_passed_to_templates.mdwn +++ b/doc/todo/description_meta_param_passed_to_templates.mdwn @@ -1,4 +1,4 @@ -[[!tag wishlist]] +[[!tag wishlist patch]] I'd like to use the description parameter from [[meta|/ikiwiki/directive/meta]] directives in custom [[inline|/ikiwiki/directive/inline]] templates. I guess this could be useful to others too. -- cgit v1.2.3 From 34f046ed4a7873e6dadbd6eb9f096b94f688d1e9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 16 Nov 2009 15:55:01 -0500 Subject: close --- doc/todo/description_meta_param_passed_to_templates.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/description_meta_param_passed_to_templates.mdwn b/doc/todo/description_meta_param_passed_to_templates.mdwn index 80a6a8e8a..712471258 100644 --- a/doc/todo/description_meta_param_passed_to_templates.mdwn +++ b/doc/todo/description_meta_param_passed_to_templates.mdwn @@ -6,3 +6,5 @@ The only change required is on [line 266](http://github.com/joeyh/ikiwiki/blob/m - foreach my $field (qw{author authorurl permalink}) { + foreach my $field (qw{author authorurl description permalink}) { + +> Good idea, [[done]]. --[[Joey]] -- cgit v1.2.3 From a56b51aef546dd87d11f7c6bd4944d13442e5df3 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Thu, 19 Nov 2009 01:55:30 -0500 Subject: response of potential user --- doc/todo/Mailing_list.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Mailing_list.mdwn b/doc/todo/Mailing_list.mdwn index b6a207420..4b2406786 100644 --- a/doc/todo/Mailing_list.mdwn +++ b/doc/todo/Mailing_list.mdwn @@ -18,3 +18,12 @@ Does this sound okay? > todo/bugs/forum feeds, or to some other feed they create on their user page. > And there's work on making the discussion pages more structured, on > accepting comments sent via mail, etc. --[[Joey]] + +>>I was going to make the very same request, so I'm glad to know I'm not the only one who felt the need for it. + +>>I can see your reasoning, though I don't think ikiwiki has reached the level (yet) of facilitating discussion as well as a mailing list does. +>>You've already pointed out the need for (a) more structured discussion pages, (b) comments sent via mail, but I'm not sure whether that will be enough. This is because the nature of a wiki means that discussions are scattered all over the site, as people discuss in discussion pages about the given topic - and so they should. The consequence of this, however, is that one has a choice (in regard to RSS feeds) of having too much or too little. Too little, if one only feeds on news/todo/bugs/forum, since one misses out on discussions elsewhere. Too much, because the only other option appears to be subscribing to recentchanges, which will give one *everything*, whether it is relevant or not. +>>Unfortunately, I'm not really sure what the best solution is for this problem. + +>> For those who might be interested, I've added two RSS feeds to : ikiwiki_news and ikiwiki_recent. +>>--[[KathrynAndersen]] -- cgit v1.2.3 From 866a915395c78f4b49a3a4f84f52816fe4f0da4f Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Thu, 19 Nov 2009 14:10:14 -0500 Subject: added more dreamwidth feeds --- doc/todo/Mailing_list.mdwn | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Mailing_list.mdwn b/doc/todo/Mailing_list.mdwn index 4b2406786..67cbbb00b 100644 --- a/doc/todo/Mailing_list.mdwn +++ b/doc/todo/Mailing_list.mdwn @@ -25,5 +25,12 @@ Does this sound okay? >>You've already pointed out the need for (a) more structured discussion pages, (b) comments sent via mail, but I'm not sure whether that will be enough. This is because the nature of a wiki means that discussions are scattered all over the site, as people discuss in discussion pages about the given topic - and so they should. The consequence of this, however, is that one has a choice (in regard to RSS feeds) of having too much or too little. Too little, if one only feeds on news/todo/bugs/forum, since one misses out on discussions elsewhere. Too much, because the only other option appears to be subscribing to recentchanges, which will give one *everything*, whether it is relevant or not. >>Unfortunately, I'm not really sure what the best solution is for this problem. ->> For those who might be interested, I've added two RSS feeds to : ikiwiki_news and ikiwiki_recent. +>> For those who might be interested, I've added the following RSS feeds to : +*ikiwiki_bugs_feed, +ikiwiki_forum_feed, +ikiwiki_news_feed, +ikiwiki_recent_feed, +ikiwiki_todo_feed, +ikiwiki_wishlist_feed* + >>--[[KathrynAndersen]] -- cgit v1.2.3 From 22a12717010546882860f770c1eb7bd083255914 Mon Sep 17 00:00:00 2001 From: "http://liw.fi/" Date: Tue, 24 Nov 2009 04:07:27 -0500 Subject: --- doc/todo/support_link__40__.__41___in_pagespec.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/support_link__40__.__41___in_pagespec.mdwn (limited to 'doc/todo') diff --git a/doc/todo/support_link__40__.__41___in_pagespec.mdwn b/doc/todo/support_link__40__.__41___in_pagespec.mdwn new file mode 100644 index 000000000..da55bce67 --- /dev/null +++ b/doc/todo/support_link__40__.__41___in_pagespec.mdwn @@ -0,0 +1,10 @@ +[[!tag wishlist]] + +It would be nice to have pagespecs support "link(.)" as syntax. +This would match pages that link to the page that invokes the pagespec. +The use case is a blog with tags, and having a page for each tag +which uses !inline to list all posts with the tag. + +Joey said on IRC that "probably changing the derel() function in +IkiWiki.pm is the best way to do it". + -- cgit v1.2.3 From e0d4b55bc885550a0e5a4fd49e2389eaeb5ec384 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Sat, 28 Nov 2009 21:36:01 -0500 Subject: this would be a nifty feature --- doc/todo/enable_arbitrary_markup_for_directives.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/todo/enable_arbitrary_markup_for_directives.mdwn (limited to 'doc/todo') diff --git a/doc/todo/enable_arbitrary_markup_for_directives.mdwn b/doc/todo/enable_arbitrary_markup_for_directives.mdwn new file mode 100644 index 000000000..7aa0b6d06 --- /dev/null +++ b/doc/todo/enable_arbitrary_markup_for_directives.mdwn @@ -0,0 +1,17 @@ +One of the good things about [PmWiki](http://www.pmwiki.org) is the ability to treat arbitrary markup as directives. +In ikiwiki, all directives have the same format: + +\[[!name arguments]] + +But with PmWiki, directives can be added to the engine (with the "Markup" hook) with the usual name and function passing, but also with a regexp which has capturing parentheses, and the results of the match are passed to the given function. +Would it be possible to alter the "preprocess" hook to have an optional regex argument which acted in a similar fashion? + +For example, one could then write a plugin which would treat + +Category: Foo, Bar + +as a tag, by using a regex such as /^Category:\s*([\w\s,]+)$/; the result "Foo, Bar" could then be further processed by the hook function. + +This could also make it easier to support more styles of markup, rather than having to do all the processing in "htmlize" and/or "filter". + +-- [[KathrynAndersen]] -- cgit v1.2.3 From bac8bc027d4a1bb262300be2323ae4093c193e5b Mon Sep 17 00:00:00 2001 From: "http://bruno.boulgour.com/" Date: Sat, 28 Nov 2009 23:35:31 -0500 Subject: new version of the patch available on my git repo --- doc/todo/cas_authentication.mdwn | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/cas_authentication.mdwn b/doc/todo/cas_authentication.mdwn index 8bf7042df..ed8010518 100644 --- a/doc/todo/cas_authentication.mdwn +++ b/doc/todo/cas_authentication.mdwn @@ -21,6 +21,19 @@ follows) ? > license statement at the top. I have a few questions that I'll insert > inline with the patch below. --[[Joey]] +>> I have made some corrections to this patch (my cas plugin) in order to use +>> IkiWiki 3.00 interface and take your comments into account. It should work +>> fine now. +>> +>> You can pull it from my git repo at +>> http://git.boulgour.com/bbb/ikiwiki.git/ and maybe add it to your main +>> repo. +>> +>> I will add GNU GPL copyright license statement as soon as I get some free +>> time. +>> +>> --[[/users/bbb]] + ------------------------------------------------------------------------------ diff --git a/IkiWiki/Plugin/cas.pm b/IkiWiki/Plugin/cas.pm new file mode 100644 -- cgit v1.2.3 From c6ea46807423f68e903f897c464b0ed35f0c586a Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Mon, 30 Nov 2009 20:45:31 -0500 Subject: tagged this wishlist; was I supposed to do that? --- doc/todo/enable_arbitrary_markup_for_directives.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable_arbitrary_markup_for_directives.mdwn b/doc/todo/enable_arbitrary_markup_for_directives.mdwn index 7aa0b6d06..94713838e 100644 --- a/doc/todo/enable_arbitrary_markup_for_directives.mdwn +++ b/doc/todo/enable_arbitrary_markup_for_directives.mdwn @@ -15,3 +15,5 @@ as a tag, by using a regex such as /^Category:\s*([\w\s,]+)$/; the result "Foo, This could also make it easier to support more styles of markup, rather than having to do all the processing in "htmlize" and/or "filter". -- [[KathrynAndersen]] + +[[!taglink wishlist]] -- cgit v1.2.3 From 99ffde64a8fb9059a32e49ae8653d18d80a1e190 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 1 Dec 2009 15:51:47 -0500 Subject: is this really better? --- doc/todo/enable_arbitrary_markup_for_directives.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable_arbitrary_markup_for_directives.mdwn b/doc/todo/enable_arbitrary_markup_for_directives.mdwn index 94713838e..aa7b6fa49 100644 --- a/doc/todo/enable_arbitrary_markup_for_directives.mdwn +++ b/doc/todo/enable_arbitrary_markup_for_directives.mdwn @@ -17,3 +17,19 @@ This could also make it easier to support more styles of markup, rather than hav -- [[KathrynAndersen]] [[!taglink wishlist]] + +> Arbitrary text transformations can already be done via the filter and +> sanitize hooks. That's how the smiley and typography plugins do their +> thing. +> +> AFAICS, the only benefit to having a regexp-based-hook interface is less +> overhead in passing page content into the hooks. But that overhead is a +> small amount of the total render time. +> +> Also, I notice that smiley does such complicated things in its sanitize +> hook (ie, it looks at html context around the smilies) that a simple +> matching regexp would not be sufficient. Furthermore, typography needs to +> pass the page content into the library it uses, which does not expose +> regexps to match on. So ikiwiki's more general filtering interface seems +> to allow both of these to do things that could not be done with the +> PmWiki interface. --[[Joey]] -- cgit v1.2.3 From 64765b365e46e0bd557d994829a0592497a5702c Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Tue, 1 Dec 2009 18:41:04 -0500 Subject: second thoughts --- doc/todo/enable_arbitrary_markup_for_directives.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable_arbitrary_markup_for_directives.mdwn b/doc/todo/enable_arbitrary_markup_for_directives.mdwn index aa7b6fa49..f521204e4 100644 --- a/doc/todo/enable_arbitrary_markup_for_directives.mdwn +++ b/doc/todo/enable_arbitrary_markup_for_directives.mdwn @@ -33,3 +33,6 @@ This could also make it easier to support more styles of markup, rather than hav > regexps to match on. So ikiwiki's more general filtering interface seems > to allow both of these to do things that could not be done with the > PmWiki interface. --[[Joey]] + +>>You have some good points. I was aware of using filter, but it didn't occur to me that one could use sanitize to do processing also, probably because "sanitize" brought to mind removing harmful content rather than doing other alterations. +>>It has also occurred to me, on further thought, that if one wants one's chosen markup to actually be processed during the "preprocess" stage, that one could do so by converting the chosen markup to directive-style markup during the "filter" stage and then processing the directive during the "preprocess" stage as per usual. Is there a tag for "no longer on the wishlist?". --[[KathrynAndersen]] -- cgit v1.2.3 From 092877335cf0994fc1066e74309f698b2a101f76 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 1 Dec 2009 20:07:21 -0500 Subject: close --- doc/todo/enable_arbitrary_markup_for_directives.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable_arbitrary_markup_for_directives.mdwn b/doc/todo/enable_arbitrary_markup_for_directives.mdwn index f521204e4..c1f0f86ed 100644 --- a/doc/todo/enable_arbitrary_markup_for_directives.mdwn +++ b/doc/todo/enable_arbitrary_markup_for_directives.mdwn @@ -36,3 +36,12 @@ This could also make it easier to support more styles of markup, rather than hav >>You have some good points. I was aware of using filter, but it didn't occur to me that one could use sanitize to do processing also, probably because "sanitize" brought to mind removing harmful content rather than doing other alterations. >>It has also occurred to me, on further thought, that if one wants one's chosen markup to actually be processed during the "preprocess" stage, that one could do so by converting the chosen markup to directive-style markup during the "filter" stage and then processing the directive during the "preprocess" stage as per usual. Is there a tag for "no longer on the wishlist?". --[[KathrynAndersen]] + +>>> Yeah, sanitize is a misleading name for the relatively few things that +>>> use it this way. +>>> +>>> While you could do a filter to preprocess step, it is a bit +>>> of a long way round, since filter always runs just before +>>> preprocess. +>>> +>>> Anyway, guess this is [[done]] --[[Joey]] -- cgit v1.2.3 From 2ce7ae08b3559c151a76109a46c97b460922a4c4 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Fri, 4 Dec 2009 22:09:57 -0500 Subject: link to further discussion --- doc/todo/structured_page_data.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn index 72bfd8dea..da9da9663 100644 --- a/doc/todo/structured_page_data.mdwn +++ b/doc/todo/structured_page_data.mdwn @@ -1,5 +1,7 @@ This is an idea from [[JoshTriplett]]. --[[Joey]] +* See further discussion at [[forum/an_alternative_approach_to_structured_data]]. + Some uses of ikiwiki, such as for a bug-tracking system (BTS), move a bit away from the wiki end of the spectrum, and toward storing structured data about a page or instead of a page. -- cgit v1.2.3 From 1370a26030599dc2f7cbeb3df714e7935860e436 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Mon, 7 Dec 2009 01:03:37 -0500 Subject: show you the code! --- ...er_ceiling___40__opposite_of_levels__61____41__.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn index 547c7a80a..318375660 100644 --- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn +++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn @@ -1,3 +1,20 @@ It would be nice if the [[plugins/toc]] plugin let you specify a header level "ceiling" above which (or above and including which) the headers would not be incorporated into the toc. Currently, the levels=X parameter lets you tweak how deep it will go for small headers, but I'd like to chop off the h1's (as I use them for my page title) -- [[Jon]] + +> This change to toc.pm should do it. --[[KathrynAndersen]] + + 56,57c56,57 + < my $startlevel=($params{startlevel} ? $params{startlevel} : 0); + < my $curlevel=$startlevel-1; + --- + > my $curlevel; + > my $startlevel=0; + 70d69 + < # unless we're given startlevel as a parameter + 75,79d73 + < elsif (defined $params{startlevel} + < and $level < $params{startlevel}) + < { + < return; + < } -- cgit v1.2.3 From 4fe1eb7ab542255eaa3d0266bc0437b49bacef4d Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Mon, 7 Dec 2009 01:05:35 -0500 Subject: my bad; wrong way around --- ...iling___40__opposite_of_levels__61____41__.mdwn | 25 +++++++++++----------- 1 file changed, 13 insertions(+), 12 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn index 318375660..2d90772db 100644 --- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn +++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn @@ -5,16 +5,17 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h > This change to toc.pm should do it. --[[KathrynAndersen]] 56,57c56,57 - < my $startlevel=($params{startlevel} ? $params{startlevel} : 0); - < my $curlevel=$startlevel-1; + < my $curlevel; + < my $startlevel=0; --- - > my $curlevel; - > my $startlevel=0; - 70d69 - < # unless we're given startlevel as a parameter - 75,79d73 - < elsif (defined $params{startlevel} - < and $level < $params{startlevel}) - < { - < return; - < } + > my $startlevel=($params{startlevel} ? $params{startlevel} : 0); + > my $curlevel=$startlevel-1; + 69a70 + > # unless we're given startlevel as a parameter + 73a75,79 + > elsif (defined $params{startlevel} + > and $level < $params{startlevel}) + > { + > return; + > } + -- cgit v1.2.3 From a132ca7c62df5ceb6c3be425613cd36c1938e335 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Thu, 10 Dec 2009 07:40:42 -0500 Subject: --- ..._set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn index 2d90772db..ce51d90a3 100644 --- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn +++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn @@ -4,6 +4,12 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h > This change to toc.pm should do it. --[[KathrynAndersen]] +> > The patch looks vaguely OK to me but it's hard to tell without +> > context. It'd be much easier to review if you used unified diff +> > (`diff -u`), which is what `git diff` defaults to - almost all +> > projects prefer to receive changes as unified diffs (or as +> > branches in their chosen VCS, which is [[git]] here). --[[smcv]] + 56,57c56,57 < my $curlevel; < my $startlevel=0; @@ -19,3 +25,4 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h > return; > } +[[!tag patch]] -- cgit v1.2.3 From eec0c6c3282625586952c0f1d74ce5a1a026ca8a Mon Sep 17 00:00:00 2001 From: kierun Date: Mon, 21 Dec 2009 16:29:59 +0000 Subject: --- doc/todo/ACL.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn index e9fb2717f..4c3062427 100644 --- a/doc/todo/ACL.mdwn +++ b/doc/todo/ACL.mdwn @@ -69,3 +69,5 @@ Here is how I see it:
     \[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]]
     
+ +Any idea when this is going to be finished? If you want, I am happy to beta test. -- cgit v1.2.3 From 98c00730f6455cce03c2dc7486cdc75c150baa69 Mon Sep 17 00:00:00 2001 From: "http://weakish.pigro.net/" Date: Thu, 24 Dec 2009 07:46:42 +0000 Subject: use `SomePage <>` for wikilink? --- .../Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index ca7b282fa..6219f1d14 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -322,3 +322,12 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera >> However, I think that if the cache does not work for a big load, it should >> not work at all; small loads are small so they don't matter. --ulrik +----- + +Another possiblity is use empty url for wiki pages (gitit uses this approach), for example: + + `SomePage <>`_ + +Since it uses *empty* url, I would like to call it *proposal 0* :-) --[weakish] + +[weakish]: http://weakish.pigro.net -- cgit v1.2.3 From 7e0d5aa1fd912cc933c613eab9d3d58d7d71f6d3 Mon Sep 17 00:00:00 2001 From: "http://weakish.pigro.net/" Date: Thu, 24 Dec 2009 07:47:50 +0000 Subject: typo --- doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn index 6219f1d14..6e0f32fd5 100644 --- a/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn +++ b/doc/todo/Resolve_native_reStructuredText_links_to_ikiwiki_pages.mdwn @@ -324,7 +324,7 @@ The page is rST-parsed once in 'scan' and once in 'htmlize' (the first to genera ----- -Another possiblity is use empty url for wiki pages (gitit uses this approach), for example: +Another possiblity is using empty url for wikilinks (gitit uses this approach), for example: `SomePage <>`_ -- cgit v1.2.3 From 6e632de82550e5d028391e74beb302b80bd9f7a6 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Fri, 25 Dec 2009 19:40:59 +0000 Subject: patch in diff -u format --- ...iling___40__opposite_of_levels__61____41__.mdwn | 47 +++++++++++++++------- 1 file changed, 33 insertions(+), 14 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn index ce51d90a3..53cb0dd7c 100644 --- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn +++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn @@ -10,19 +10,38 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h > > projects prefer to receive changes as unified diffs (or as > > branches in their chosen VCS, which is [[git]] here). --[[smcv]] - 56,57c56,57 - < my $curlevel; - < my $startlevel=0; - --- - > my $startlevel=($params{startlevel} ? $params{startlevel} : 0); - > my $curlevel=$startlevel-1; - 69a70 - > # unless we're given startlevel as a parameter - 73a75,79 - > elsif (defined $params{startlevel} - > and $level < $params{startlevel}) - > { - > return; - > } +> > > Done. -- [[KathrynAndersen]] + + + --- /files/git/other/ikiwiki/IkiWiki/Plugin/toc.pm 2009-11-16 12:44:00.352050178 +1100 + +++ toc.pm 2009-12-26 06:36:06.686512552 +1100 + @@ -53,8 +53,8 @@ + my $page=""; + my $index=""; + my %anchors; + - my $curlevel; + - my $startlevel=0; + + my $startlevel=($params{startlevel} ? $params{startlevel} : 0); + + my $curlevel=$startlevel-1; + my $liststarted=0; + my $indent=sub { "\t" x $curlevel }; + $p->handler(start => sub { + @@ -67,10 +67,16 @@ + + # Take the first header level seen as the topmost level, + # even if there are higher levels seen later on. + + # unless we're given startlevel as a parameter + if (! $startlevel) { + $startlevel=$level; + $curlevel=$startlevel-1; + } + + elsif (defined $params{startlevel} + + and $level < $params{startlevel}) + + { + + return; + + } + elsif ($level < $startlevel) { + $level=$startlevel; + } [[!tag patch]] -- cgit v1.2.3 From 8e0f45ae670985a0ffde8180776dd8ce5821c7d8 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 25 Dec 2009 15:12:05 -0500 Subject: add example --- doc/todo/ACL.mdwn | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn index 4c3062427..d40701d60 100644 --- a/doc/todo/ACL.mdwn +++ b/doc/todo/ACL.mdwn @@ -70,4 +70,9 @@ Here is how I see it: \[[!acl user=* page=/subsite/* acl=/subsite/acl.mdwn]] -Any idea when this is going to be finished? If you want, I am happy to beta test. +Any idea when this is going to be finished? If you want, I am happy to beta test. + +> It's already done, though that is sorta hidden in the above. :-) +> Example of use to only allow two users to edit the tipjar page: +> locked_pages => 'tipjar and !(user(joey) or user(bob))', +> --[[Joey]] -- cgit v1.2.3 From 8a51384297c66dd1216088ceb5def61d09af021e Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Sun, 27 Dec 2009 12:40:11 +0000 Subject: note as merged --- ...lugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'doc/todo') diff --git a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn index 53cb0dd7c..07d2d383c 100644 --- a/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn +++ b/doc/todo/toc_plugin:_set_a_header_ceiling___40__opposite_of_levels__61____41__.mdwn @@ -12,6 +12,7 @@ Currently, the levels=X parameter lets you tweak how deep it will go for small h > > > Done. -- [[KathrynAndersen]] +> > > > Looks like Joey has now [[merged|done]] this. Thanks! --[[smcv]] --- /files/git/other/ikiwiki/IkiWiki/Plugin/toc.pm 2009-11-16 12:44:00.352050178 +1100 +++ toc.pm 2009-12-26 06:36:06.686512552 +1100 -- cgit v1.2.3 From 87c84515e96ac991a67571b26d90a4f2ed58c757 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 28 Dec 2009 13:03:39 -0500 Subject: idea --- doc/todo/conflict_free_comment_merges.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/todo/conflict_free_comment_merges.mdwn (limited to 'doc/todo') diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn new file mode 100644 index 000000000..e0e8acb34 --- /dev/null +++ b/doc/todo/conflict_free_comment_merges.mdwn @@ -0,0 +1,14 @@ +Currently, new comments are named with an incrementing ID (comment_N). So +if a wiki has multiple disconnected servers, and comments are made to the +same page on both, merging is guaranteed to result in conflicts. + +I propose avoiding such merge problems by naming a comment with a sha1sum +of its (full) content. Keep the incrementing ID too, so there is an +-ordering. And so duplicate comments are allowed..) +So, "comment_N_SHA1". + +Note: The comment body will need to use meta title in the case where no +title is specified, to retain the current behavior of the default title +being "comment N". + +What do you think [[smcv]]? --[[Joey]] -- cgit v1.2.3 From 2143cfcc3d0dc03fe3a67a5cab612fac041c2c9f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 28 Dec 2009 13:14:54 -0500 Subject: thoughts --- doc/todo/tagging_with_a_publication_date.mdwn | 31 +++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/tagging_with_a_publication_date.mdwn b/doc/todo/tagging_with_a_publication_date.mdwn index 80240ec5a..39fc4e220 100644 --- a/doc/todo/tagging_with_a_publication_date.mdwn +++ b/doc/todo/tagging_with_a_publication_date.mdwn @@ -38,3 +38,34 @@ on vacation". > > > > I no longer have the original wiki for which I wanted this feature, but I can > > see using it on future ones. -- [[DonMarti]] + +>>> FWIW, for the case where one wants to update a site offline, +>>> using an ikiwiki instance on a laptop, and include some deffered +>>> posts in the push, the ad-hoc cron job type approach will be annoying. +>>> +>>> In modern ikiwiki, I guess the way to accomplish this would be to +>>> add a pagespec that matches only pages posted in the present or past. +>>> Then a page can have its post date set to the future, using meta date, +>>> and only show up when its post date rolls around. +>>> +>>> Ikiwiki will need to somehow notice that a pagespec began matching +>>> a page it did not match previously, despite said page not actually +>>> changing. I'm not sure what the best way is. +>>> +>>> * One way could be to +>>> use a needsbuild hook and some stored data about which pagespecs +>>> exclude pages in the future. (But I'm not sure how evaluating the +>>> pagespec could lead to that metadata and hook being set up.) +>>> * Another way would be to use an explicit directive to delay a +>>> page being posted. Then the directive stores the metadata and +>>> sets up the needsbuild hook. +>>> * Another way would be for ikiwiki to remember the last +>>> time it ran. It could then easily find pages that have a post +>>> date after that time, and treat them the same as it treats actually +>>> modified files. Or a plugin could do this via a needsbuild hook, +>>> probably. (Only downside to this is it would probably need to do +>>> a O(n) walk of the list of pages -- but only running an integer +>>> compare per page.) +>>> +>>> You'd still need a cron job to run ikiwiki -refresh every hour, or +>>> whatever, so it can update. --[[Joey]] -- cgit v1.2.3 From 6af6c89df314cf2f9c9e053c04aa2bd492072ab1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 30 Dec 2009 15:41:17 -0500 Subject: comments: Add a checksum to the name of comment pages, to avoid merge conflicts when comments are posted to two branches of a site. --- IkiWiki/Plugin/comments.pm | 32 ++++++++++++++++++++++-------- debian/changelog | 3 +++ doc/todo/conflict_free_comment_merges.mdwn | 9 +++++++++ 3 files changed, 36 insertions(+), 8 deletions(-) (limited to 'doc/todo') diff --git a/IkiWiki/Plugin/comments.pm b/IkiWiki/Plugin/comments.pm index 517e16f9f..6340fc2cb 100644 --- a/IkiWiki/Plugin/comments.pm +++ b/IkiWiki/Plugin/comments.pm @@ -377,8 +377,6 @@ sub editcomment ($$) { IkiWiki::check_canedit($page, $cgi, $session); $postcomment=0; - my $location=unique_comment_location($page, $config{srcdir}); - my $content = "[[!comment format=$type\n"; # FIXME: handling of double quotes probably wrong? @@ -410,8 +408,11 @@ sub editcomment ($$) { my $subject = $form->field('subject'); if (defined $subject && length $subject) { $subject =~ s/"/"/g; - $content .= " subject=\"$subject\"\n"; } + else { + $subject = "comment ".(num_comments($page, $config{srcdir}) + 1); + } + $content .= " subject=\"$subject\"\n"; $content .= " date=\"" . decode_utf8(strftime('%Y-%m-%dT%H:%M:%SZ', gmtime)) . "\"\n"; @@ -421,6 +422,8 @@ sub editcomment ($$) { $editcontent =~ s/"/\\"/g; $content .= " content=\"\"\"\n$editcontent\n\"\"\"]]\n"; + my $location=unique_comment_location($page, $content, $config{srcdir}); + # This is essentially a simplified version of editpage: # - the user does not control the page that's created, only the parent # - it's always a create operation, never an edit @@ -458,7 +461,7 @@ sub editcomment ($$) { if (! $ok) { my $penddir=$config{wikistatedir}."/comments_pending"; - $location=unique_comment_location($page, $penddir); + $location=unique_comment_location($page, $content, $penddir); writefile("$location._comment", $penddir, $content); IkiWiki::printheader($session); print IkiWiki::misctemplate(gettext(gettext("comment stored for moderation")), @@ -554,7 +557,7 @@ sub commentmoderation ($$) { if ($action eq 'Accept') { my $content=eval { readfile($file) }; next if $@; # file vanished since form was displayed - my $dest=unique_comment_location($page, $config{srcdir})."._comment"; + my $dest=unique_comment_location($page, $content, $config{srcdir})."._comment"; writefile($dest, $config{srcdir}, $content); if ($config{rcs} and $config{comments_commit}) { IkiWiki::rcs_add($dest); @@ -813,15 +816,28 @@ sub pagetemplate (@) { } } -sub unique_comment_location ($) { +sub num_comments ($$) { my $page=shift; my $dir=shift; + my @comments=glob("$dir/$page/$config{comments_pagename}*._comment"); + return @comments; +} + +sub unique_comment_location ($$$) { + my $page=shift; + + eval q{use Digest::MD5 'md5_hex'}; + error($@) if $@; + my $content_md5=md5_hex(shift); + + my $dir=shift; + my $location; - my $i = 0; + my $i = num_comments($page, $dir); do { $i++; - $location = "$page/$config{comments_pagename}$i"; + $location = "$page/$config{comments_pagename}${i}_${content_md5}"; } while (-e "$dir/$location._comment"); return $location; diff --git a/debian/changelog b/debian/changelog index ee6f9adfb..984351415 100644 --- a/debian/changelog +++ b/debian/changelog @@ -8,6 +8,9 @@ ikiwiki (3.20091219) UNRELEASED; urgency=low can be generated at any time using ikiwiki --dumpsetup so I do not see a reason to ship it. Closes: #562183 * Use env hack in python scripts. + * comments: Add a checksum to the name of comment pages, to + avoid merge conflicts when comments are posted to two branches of a + site. -- Joey Hess Fri, 25 Dec 2009 14:31:22 -0500 diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn index e0e8acb34..2cef0ee8c 100644 --- a/doc/todo/conflict_free_comment_merges.mdwn +++ b/doc/todo/conflict_free_comment_merges.mdwn @@ -12,3 +12,12 @@ title is specified, to retain the current behavior of the default title being "comment N". What do you think [[smcv]]? --[[Joey]] + +> I had to use md5sums, as sha1sum perl module may not be available and I +> didn't want to drag it in. But I think that's ok; this doesn't need to be +> cryptographically secure and even the chances of being able to +> purposefully cause a md5 collision and thus an undesired merge conflict +> are quite low since it modifies the input text and adds a date stamp to +> it. +> +> Anyway, I think it's good, [[[done]] --[[Joey]] -- cgit v1.2.3 From 387e1cc141e474513dcc4429381ffdb147c59e38 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 2 Jan 2010 16:49:42 -0500 Subject: html5 note --- doc/todo/Add_label_to_search_form_input_field.mdwn | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn index e4e83428c..51b34927d 100644 --- a/doc/todo/Add_label_to_search_form_input_field.mdwn +++ b/doc/todo/Add_label_to_search_form_input_field.mdwn @@ -47,4 +47,8 @@ The patch below adds a label for the field to improve usability: > to get it to appear higher up is to put it first, or to use Evil absolute > positioning. (CSS sucks.) --[[Joey]] -[[!tag done wishlist]] +> Update: html5 allows just adding `placeholder="Search"` to the input +> element. already works in eg, chromium. However, ikiwiki does not use +> html5 yet. --[[Joey]] + +[[!tag wishlist html5]] -- cgit v1.2.3 From 436e29731026194e961ed0f11e85517308a400d9 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Thu, 7 Jan 2010 09:40:10 +0000 Subject: seasons greatings, polite nudge --- doc/todo/allow_site-wide_meta_definitions.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 62317ba1a..99a9cf1e2 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -178,3 +178,8 @@ definitions essentially. * title -- [[Jon]] + +>>> Merry Christmas/festive season/happy new year folks. I've been away from +>>> ikiwiki for the break, and now I've returned to watching recentchanges. +>>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have +>>> you had a chance to look at this yet? -- [[Jon]] -- cgit v1.2.3 From 6257a714077712e818127ed0c68d9a9611d7628f Mon Sep 17 00:00:00 2001 From: intrigeri Date: Thu, 7 Jan 2010 23:22:48 +0100 Subject: selflink detection is suboptimal when using the po plugin --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 doc/todo/Fix_selflink_in_po_plugin.mdwn (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn new file mode 100644 index 000000000..ae59e14c2 --- /dev/null +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -0,0 +1,4 @@ +Using the po plugin, a link to /bla is present in the sidebar. +When viewing /bla in the default language, this link is detected as +a selflink. When viewing a translation of /bla, it +isn't. --[[intrigeri]] -- cgit v1.2.3 From cf7d03ec80e168ad18d65a90842773da353ee060 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sat, 9 Jan 2010 22:57:11 +0100 Subject: fixed bug in my po branch, please pull --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index ae59e14c2..55968e3d7 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -2,3 +2,5 @@ Using the po plugin, a link to /bla is present in the sidebar. When viewing /bla in the default language, this link is detected as a selflink. When viewing a translation of /bla, it isn't. --[[intrigeri]] + +Fixed in my po branch => [[!tag patch]]. --[[intrigeri]] -- cgit v1.2.3 From 62a67e161bccba431b8b8a501967ba7acf6e197a Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sat, 9 Jan 2010 22:59:46 +0100 Subject: wiki syntax fix --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index 55968e3d7..87fa38911 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -3,4 +3,6 @@ When viewing /bla in the default language, this link is detected as a selflink. When viewing a translation of /bla, it isn't. --[[intrigeri]] -Fixed in my po branch => [[!tag patch]]. --[[intrigeri]] +Fixed in my po branch. --[[intrigeri]] + +[[!tag patch]] -- cgit v1.2.3 From 1ddef7da7b170bb4bd7c816cba03e3e6338a50b2 Mon Sep 17 00:00:00 2001 From: "http://edrex.myopenid.com/" Date: Sun, 17 Jan 2010 07:22:03 +0000 Subject: --- doc/todo/svg.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'doc/todo') diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn index 0a15af4cd..f264f4107 100644 --- a/doc/todo/svg.mdwn +++ b/doc/todo/svg.mdwn @@ -3,6 +3,7 @@ We should support SVG. In particular: * We could support rendering SVGs to PNGs when compiling the wiki. Not all browsers support SVG yet. * We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup. + * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated --[EricDrechsel]] --[[JoshTriplett]] -- cgit v1.2.3 From 5588abc2befbde83e43cf79f9717e323aa69da11 Mon Sep 17 00:00:00 2001 From: "http://edrex.myopenid.com/" Date: Sun, 17 Jan 2010 07:22:54 +0000 Subject: --- doc/todo/svg.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn index f264f4107..89b183db6 100644 --- a/doc/todo/svg.mdwn +++ b/doc/todo/svg.mdwn @@ -3,7 +3,7 @@ We should support SVG. In particular: * We could support rendering SVGs to PNGs when compiling the wiki. Not all browsers support SVG yet. * We could support editing SVGs via the web interface. SVG can contain unsafe content such as scripting, so we would need to whitelist safe markup. - * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated --[EricDrechsel]] + * I am interested in seeing [svg-edit](http://code.google.com/p/svg-edit/) integrated -- [[EricDrechsel]] --[[JoshTriplett]] -- cgit v1.2.3 From deb0bc8bd57bc74709ecb12de36a9cb96c684a93 Mon Sep 17 00:00:00 2001 From: Josh Triplett Date: Tue, 2 Feb 2010 02:56:06 -0800 Subject: New todo item for wrapperuser configuration option --- doc/todo/wrapperuser.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/todo/wrapperuser.mdwn (limited to 'doc/todo') diff --git a/doc/todo/wrapperuser.mdwn b/doc/todo/wrapperuser.mdwn new file mode 100644 index 000000000..4c42b046f --- /dev/null +++ b/doc/todo/wrapperuser.mdwn @@ -0,0 +1,7 @@ +ikiwiki's .setup file can specify wrappergroup, and ikiwiki will set the group +of the wrappers accordingly. Having had people encounter difficulty before +when trying to do the same thing with users (for instance, making all wrappers +6755 ikiwiki:ikiwiki), I think it would help to have "wrapperuser". This could +only actually take effect if building the wrappers as root (not really the best +plan), but ikiwiki could at least warn if wrapperuser does not match the user +the wrapper will end up with. -- cgit v1.2.3 From 05b99e3cfa8c9044d18d5b07aec24fff555f2889 Mon Sep 17 00:00:00 2001 From: David Riebenbauer Date: Tue, 2 Feb 2010 13:54:51 +0100 Subject: Document git branch for automatically creating tag pages. --- ...o-create_tag_pages_according_to_a_template.mdwn | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index f1d33114f..95710ced0 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -123,3 +123,40 @@ On the second extra pass, it doesn't notice that it has to update the "?"-link. } is not satisfied for the newly created tag page. I shall put debug msgs into Render.pm to find out better how it works. --Ivan Z. + +--- + +I've made another attempt at fixiing this + +The current progress can be found at my [git repository][gitweb] on branch +`autotag`: + + git://git.liegesta.at/git/ikiwiki + +[gitweb]: http://git.liegesta.at/?p=ikiwiki.git;a=shortlog;h=refs/heads/autotag (gitweb for branch autotag) + +It's not entirely finished yet, but already quite usable. Testing and comments +on code quality, implementation details, as well as other patches would be +appreciated. + +Here's what it does right now: + +* enabled by setting `tag_autocreate=1` in the configuration. +* Tag pages will be created in `tagbase` from the template `autotag.tmpl`. +* Will correctly render all links, and dependencies. Well, AFAIK. +* When a tag page is deleted it will automatically recreated from template. (I +consider this a feature, not a bug) +* Requires a rebuild on first use. +* Adds a function `add_autofile()` to the plugin API, to do all this. + +Todo/Bugs: + +* Will still create a page even if there's a page other than `$tag` under +`tagbase` satisfying the tag link. +* Call from `IkiWiki.pm` to `Render.pm`, which adds a module dependency in the +wrong direction. +* Add files to RCS. +* Unit tests. +* Proper documentation. + +--[[David_Riebenbauer]] -- cgit v1.2.3 From 1febfda911d29a52b4c4aa1bb286f4c9e1862c5c Mon Sep 17 00:00:00 2001 From: David Riebenbauer Date: Tue, 2 Feb 2010 14:50:01 +0100 Subject: also tag 'patch/core', considering that over half of the changes are there --- doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 95710ced0..8c586d706 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -4,7 +4,7 @@ Tags are mainly specific to the object to which they’re stuck. However, I ofte Also see: and -[[!tag wishlist plugins/tag patch]] +[[!tag wishlist plugins/tag patch patch/core]] I would love to see this as well. -- dato -- cgit v1.2.3 From 6b98269aa310abc121875753ded37042f3a95988 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 2 Feb 2010 13:31:07 -0500 Subject: partial review --- ...o-create_tag_pages_according_to_a_template.mdwn | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index 8c586d706..a0e76fd48 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -160,3 +160,35 @@ wrong direction. * Proper documentation. --[[David_Riebenbauer]] + +> Starting review of this. Some of your commits are to very delicate, +> optimised, and security-sensitive ground, so I have to look at them very +> carefully. --[[Joey]] +> +> * In the refactoring in f3abeac919c4736429bd3362af6edf51ede8e7fe, +> you introduced at least 2 bugs, one a possible security hole. +> Now one part of the code tests `if ($file)` and the other +> caller tests `if ($f)`. These two tests both tested `if (! defined $f)` +> before. Notice that the variable needs to be the untainted variable +> for both. Also notice that `if ($f)` fails if `$f` contains `0`, +> which is a very common perl gotcha. +> * Your refactored code changes `-l $_ || -d _` to `-l $file || -d $file`. +> The latter makes one more stat system call; note the use of a +> bare `_` in the first to make perl reuse the stat buffer. +> * (As a matter of style, could you put a space after the commas in your +> perl?) +> +> I'd like to cherry-pick the above commit, once it's in shape, before +> looking at the rest in detail. So just a few other things that stood out. +> +> * Commit 4af4d26582f0c2b915d7102fb4a604b176385748 seems unnecessary. +> `srcfile($file, 1)` already is documented to return undef if the +> file does not exist. (But without the second parameter, it throws +> an error.) +> +> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 adds a line +> that is intented by a space, not a tab. +> +> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 says that auto-added +> files will be recreated if the user deletes them. That seems bad. +> `autoindex` goes to some trouble to not recreate deleted files. -- cgit v1.2.3 From fb6e73b3698089f47ae63d1569225938699d84e1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 8 Feb 2010 13:46:49 -0500 Subject: move to correct location --- doc/todo/http_bl_support.mdwn | 61 +++++++++++++++++++++++++++++++++++++++ doc/wishlist/http_bl_support.mdwn | 61 --------------------------------------- 2 files changed, 61 insertions(+), 61 deletions(-) create mode 100644 doc/todo/http_bl_support.mdwn delete mode 100644 doc/wishlist/http_bl_support.mdwn (limited to 'doc/todo') diff --git a/doc/todo/http_bl_support.mdwn b/doc/todo/http_bl_support.mdwn new file mode 100644 index 000000000..024c770d8 --- /dev/null +++ b/doc/todo/http_bl_support.mdwn @@ -0,0 +1,61 @@ +[Project Honeypot](http://projecthoneypot.org/) has an HTTP:BL API available to subscribed (it's free, accept donations) people/orgs. There's a basic perl package someone wrote, I'm including a copy here. + +[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112) + +
+package Honeypot;
+
+use Socket qw/inet_ntoa/;
+
+my $dns = 'dnsbl.httpbl.org';
+my %types = (
+0	=> 'Search Engine',
+1	=> 'Suspicious',
+2	=> 'Harvester',
+4	=> 'Comment Spammer'
+);
+sub query {
+my $key = shift || die 'You need a key for this, you get one at http://www.projecthoneypot.org';
+my $ip = shift || do {
+warn 'no IP for request in Honeypot::query().';
+return;
+};
+
+my @parts = reverse split /\./, $ip;
+my $lookup_name = join'.', $key, @parts, $dns;
+
+my $answer = gethostbyname ($lookup_name);
+return unless $answer;
+$answer = inet_ntoa($answer);
+my(undef, $days, $threat, $type) = split /\./, $answer;
+my @types;
+while(my($bit, $typename) = each %types) {
+push @types, $typename if $bit & $type;
+}
+return {
+days => $days,
+threat => $threat,
+type => join ',', @types
+};
+
+}
+1;
+
+ +From the page: + +> The usage is simple: + +> use Honeypot; +> my $key = 'XXXXXXX'; # your key +> my $ip = '....'; the IP you want to check +> my $q = Honeypot::query($key, $ip); + +> use Data::Dumper; +> print Dumper $q; + +Any chance of having this as a plugin? + +I could give it a go, too. Would be fun to try my hand at Perl. --[[simonraven]] + +[[!tag wishlist]] diff --git a/doc/wishlist/http_bl_support.mdwn b/doc/wishlist/http_bl_support.mdwn deleted file mode 100644 index 024c770d8..000000000 --- a/doc/wishlist/http_bl_support.mdwn +++ /dev/null @@ -1,61 +0,0 @@ -[Project Honeypot](http://projecthoneypot.org/) has an HTTP:BL API available to subscribed (it's free, accept donations) people/orgs. There's a basic perl package someone wrote, I'm including a copy here. - -[from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112) - -
-package Honeypot;
-
-use Socket qw/inet_ntoa/;
-
-my $dns = 'dnsbl.httpbl.org';
-my %types = (
-0	=> 'Search Engine',
-1	=> 'Suspicious',
-2	=> 'Harvester',
-4	=> 'Comment Spammer'
-);
-sub query {
-my $key = shift || die 'You need a key for this, you get one at http://www.projecthoneypot.org';
-my $ip = shift || do {
-warn 'no IP for request in Honeypot::query().';
-return;
-};
-
-my @parts = reverse split /\./, $ip;
-my $lookup_name = join'.', $key, @parts, $dns;
-
-my $answer = gethostbyname ($lookup_name);
-return unless $answer;
-$answer = inet_ntoa($answer);
-my(undef, $days, $threat, $type) = split /\./, $answer;
-my @types;
-while(my($bit, $typename) = each %types) {
-push @types, $typename if $bit & $type;
-}
-return {
-days => $days,
-threat => $threat,
-type => join ',', @types
-};
-
-}
-1;
-
- -From the page: - -> The usage is simple: - -> use Honeypot; -> my $key = 'XXXXXXX'; # your key -> my $ip = '....'; the IP you want to check -> my $q = Honeypot::query($key, $ip); - -> use Data::Dumper; -> print Dumper $q; - -Any chance of having this as a plugin? - -I could give it a go, too. Would be fun to try my hand at Perl. --[[simonraven]] - -[[!tag wishlist]] -- cgit v1.2.3 From 4ce14aa621be4c6b8551555395b80b68fbcc1ffe Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 8 Feb 2010 13:49:34 -0500 Subject: nte blogspam --- doc/todo/http_bl_support.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/http_bl_support.mdwn b/doc/todo/http_bl_support.mdwn index 024c770d8..f7a46ee6c 100644 --- a/doc/todo/http_bl_support.mdwn +++ b/doc/todo/http_bl_support.mdwn @@ -2,6 +2,12 @@ [from here](http://projecthoneypot.org/board/read.php?f=10&i=112&t=112) +> The [[plugins/blogspam]] service already checks urls against +> the surbl, and has its own IP blacklist. The best way to +> support the HTTP:BL may be to add a plugin +> [there](http://blogspam.repository.steve.org.uk/file/cc858e497cae/server/plugins/). +> --[[Joey]] +
 package Honeypot;
 
-- 
cgit v1.2.3


From 172dfa9f64b5a248042af7c4b741fdd4c71813ec Mon Sep 17 00:00:00 2001
From: "http://seeitcoming.myopenid.com/"
 
Date: Sat, 13 Feb 2010 15:16:09 +0000
Subject: Added information about python implementation for reference

---
 doc/todo/abbreviation.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/abbreviation.mdwn b/doc/todo/abbreviation.mdwn
index d24166710..f2880091c 100644
--- a/doc/todo/abbreviation.mdwn
+++ b/doc/todo/abbreviation.mdwn
@@ -2,4 +2,6 @@ We might want some kind of abbreviation and acronym plugin. --[[JoshTriplett]]
 
  * Not sure if this is what you mean, but I'd love a way to make works which match existing page names automatically like (eg. if there is a page called "MySQL" then any time the word MySQL is mentioned it should become a link to that page).  -- [[AdamShand]]
 
+ * The python-markdown-extras package has support for [abbreviations](http://www.freewisdom.org/projects/python-markdown/Abbreviations), with the syntax that you just use the abbreviation in text (e.g. HTML) and then define the abbreviations at the end (like "footnote-style" links). For consistency, it might be good to use the same syntax, which apparently derives from [PHP-markdown-extra](http://michelf.com/projects/php-markdown/extra/#abbr).
+
 [[wishlist]]
-- 
cgit v1.2.3


From a38418a8a3652bad60c83a0dd7502f7afb991512 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Feb 2010 14:07:56 -0500
Subject: close

---
 doc/todo/openid_user_filtering.mdwn | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/openid_user_filtering.mdwn b/doc/todo/openid_user_filtering.mdwn
index 8b2d0082e..7f8b2a55e 100644
--- a/doc/todo/openid_user_filtering.mdwn
+++ b/doc/todo/openid_user_filtering.mdwn
@@ -7,3 +7,7 @@ So I suggest an ikiwiki configuration like:
      users => ["*.webvm.net"],
 
 Would only allow edits from openIDs of that form.
+
+> This kind of thing can be [[done]] now: --[[Joey]] 
+> 
+>	locked_pages => "user(http://*.webvm.net/)"
-- 
cgit v1.2.3


From 6fc25c8df79c4ce9afde256be5d377ee82562c31 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 13 Feb 2010 14:13:30 -0500
Subject: clarify

---
 doc/todo/openid_user_filtering.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/openid_user_filtering.mdwn b/doc/todo/openid_user_filtering.mdwn
index 7f8b2a55e..6a318c4c0 100644
--- a/doc/todo/openid_user_filtering.mdwn
+++ b/doc/todo/openid_user_filtering.mdwn
@@ -10,4 +10,4 @@ Would only allow edits from openIDs of that form.
 
 > This kind of thing can be [[done]] now: --[[Joey]] 
 > 
->	locked_pages => "user(http://*.webvm.net/)"
+>	locked_pages => "* and !user(http://*.webvm.net/)"
-- 
cgit v1.2.3


From ce8bb219586332032110da8835fde8dd5f0ed91f Mon Sep 17 00:00:00 2001
From: nil 
Date: Tue, 16 Feb 2010 18:42:11 +0000
Subject: whishlist

---
 doc/todo/cdate_and_mdate_available_for_templates.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 doc/todo/cdate_and_mdate_available_for_templates.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/cdate_and_mdate_available_for_templates.mdwn b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
new file mode 100644
index 000000000..29c36b9f7
--- /dev/null
+++ b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
@@ -0,0 +1,15 @@
+[[!tag whishlist]]
+
+`CDATE_3339`, `CDATE_822`, `MDATE_3339` and `MDATE_822` template variables would be useful for evey page, at least for my templates with Dublin Core metadata.
+
+I tried to pick the relevant lines of the [[inline|plugins/inline]] plugin and hack it into a custom plugin, but it failed miserably because of my obvious lack of perl litteracy...
+
+Anyway, I'm sure this is almost nothing...
+
+* `sub date_822 ($) {}`
+* `sub date_3339 ($) {}`
+* and something like `$template->param('cdate_822' => date_822($IkiWiki::pagectime{$page}));`
+
+Anyone can fill the missing lines?
+
+-- [[nil]]
-- 
cgit v1.2.3


From d4bc6e25e43f0cb2f12d7e9d954cbfc227c1686d Mon Sep 17 00:00:00 2001
From: nil 
Date: Tue, 16 Feb 2010 18:43:10 +0000
Subject: typo

---
 doc/todo/cdate_and_mdate_available_for_templates.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/cdate_and_mdate_available_for_templates.mdwn b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
index 29c36b9f7..70d8fc8c9 100644
--- a/doc/todo/cdate_and_mdate_available_for_templates.mdwn
+++ b/doc/todo/cdate_and_mdate_available_for_templates.mdwn
@@ -1,4 +1,4 @@
-[[!tag whishlist]]
+[[!tag wishlist]]
 
 `CDATE_3339`, `CDATE_822`, `MDATE_3339` and `MDATE_822` template variables would be useful for evey page, at least for my templates with Dublin Core metadata.
 
-- 
cgit v1.2.3


From 34d6403a4b12c9578e7b0ea3fb765e1c5e72520f Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/" 
Date: Wed, 17 Feb 2010 11:54:26 +0000
Subject: new feature request: identifying trivial edits

---
 ...trivial__44___identify__47__filter_on_trivial_changes.mdwn | 11 +++++++++++
 1 file changed, 11 insertions(+)
 create mode 100644 doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn b/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
new file mode 100644
index 000000000..2b2b0242e
--- /dev/null
+++ b/doc/todo/mark_edit_as_trivial__44___identify__47__filter_on_trivial_changes.mdwn
@@ -0,0 +1,11 @@
+One feature of mediawiki which I quite like is the ability to mark a change as 'minor', or 'trivial'. This can then be used to filter the 'recentchanges' page, to only show substantial edits.
+
+The utility of this depends entirely on whether the editors use it properly.
+
+I currently use an inline on the front page of my personal homepage to show the most recent pages (by creation date) within a subsection of my site (a blog). Blog posts are rarely modified much after they are 'created' (or published - I bodge the creation time via meta when I publish a post. It might sit in draft form indefinitely), so this effectively shows only non-trivial changes.
+
+I would like to have a short list of the most recent modifications to the site on the front page. I therefore want to sort by modified time rather than creation time, but exclude edits that I self-identify as minor. I also only want to take a short number of items, the top 5, and display only their titles (which may be derived from filename, or set via meta again).
+
+I'm still thinking through how this might be achieved in an ikiwiki-suitable fashion, but I think I need a scheme to identify certain edits as trivial. This would have to work via web edits (easier: could add a check box to the edit form) and plain changes in the VCS (harder: scan for keywords in a commit message? in a VCS-agnostic fashion?)
+
+[[!tag wishlist]]
-- 
cgit v1.2.3


From d1137697a80ca5e90bfc9d1c1f00b455871b99c5 Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/" 
Date: Fri, 19 Feb 2010 14:00:52 +0000
Subject: fix 'done' link

---
 doc/todo/conflict_free_comment_merges.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/conflict_free_comment_merges.mdwn b/doc/todo/conflict_free_comment_merges.mdwn
index 2cef0ee8c..e84400c17 100644
--- a/doc/todo/conflict_free_comment_merges.mdwn
+++ b/doc/todo/conflict_free_comment_merges.mdwn
@@ -20,4 +20,4 @@ What do you think [[smcv]]? --[[Joey]]
 > are quite low since it modifies the input text and adds a date stamp to
 > it.
 >
-> Anyway, I think it's good, [[[done]] --[[Joey]] 
+> Anyway, I think it's good, [[done]] --[[Joey]] 
-- 
cgit v1.2.3


From 59017c6ae19f661761d0ae3f143fbda643ca1e8d Mon Sep 17 00:00:00 2001
From: "http://jmtd.livejournal.com/" 
Date: Fri, 19 Feb 2010 14:02:29 +0000
Subject: prevent keyboard mashing

---
 doc/todo/double-click_protection_for_form_buttons.mdwn | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 doc/todo/double-click_protection_for_form_buttons.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/double-click_protection_for_form_buttons.mdwn b/doc/todo/double-click_protection_for_form_buttons.mdwn
new file mode 100644
index 000000000..4c0d95bd6
--- /dev/null
+++ b/doc/todo/double-click_protection_for_form_buttons.mdwn
@@ -0,0 +1 @@
+A small piece of JS to prevent double-submitting forms would be quite nice. I seem to have developed a habit of doing this and having to resolve a merge conflict for two initial commits. -- [[Jon]]
-- 
cgit v1.2.3


From ef537ed3553c590abbc302a97299ae5082471fea Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 19 Feb 2010 13:38:37 -0500
Subject: response

---
 doc/todo/double-click_protection_for_form_buttons.mdwn | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/double-click_protection_for_form_buttons.mdwn b/doc/todo/double-click_protection_for_form_buttons.mdwn
index 4c0d95bd6..501be4498 100644
--- a/doc/todo/double-click_protection_for_form_buttons.mdwn
+++ b/doc/todo/double-click_protection_for_form_buttons.mdwn
@@ -1 +1,5 @@
 A small piece of JS to prevent double-submitting forms would be quite nice. I seem to have developed a habit of doing this and having to resolve a merge conflict for two initial commits. -- [[Jon]]
+
+> By the time you see that merge conflict, the first commit has
+> already successfully happened, so you can just hit cancel
+> and throw away the second submit. --[[Joey]] 
-- 
cgit v1.2.3


From f0b0bb5894e056eeb67c50cf096f950f1fbc718a Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 19 Feb 2010 14:27:42 -0500
Subject: ctime idea

---
 doc/todo/auto_getctime_on_fresh_build.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)
 create mode 100644 doc/todo/auto_getctime_on_fresh_build.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/auto_getctime_on_fresh_build.mdwn b/doc/todo/auto_getctime_on_fresh_build.mdwn
new file mode 100644
index 000000000..ea95fb8c9
--- /dev/null
+++ b/doc/todo/auto_getctime_on_fresh_build.mdwn
@@ -0,0 +1,9 @@
+[[!tag wishlist]]
+
+It might be a good idea to enable --getctime when `.ikiwiki` does not
+exist. This way a new checkout of a `srcdir` would automatically get
+ctimes right. (Running --getctime whenever a rebuild is done would be too
+slow.) --[[Joey]] 
+
+Could this be too annoying in some cases, eg, checking out a large wiki
+that needs to get set up right away? --[[Joey]] 
-- 
cgit v1.2.3


From 100636afa253c9808654b5db45feabc4ca1c6f8c Mon Sep 17 00:00:00 2001
From: "http://privat.myopenid.com/" 
Date: Sat, 27 Feb 2010 15:12:39 +0000
Subject: patch for multiple sidebars

---
 ..._up_sidebar_to_allow_for_multiple_sidebars.mdwn | 52 ++++++++++++++++++++++
 1 file changed, 52 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index fb942a495..02b83244e 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -13,5 +13,57 @@ those contents instead.
 
 > In mine I just copied sidebar out and made some extra "sidebars", but they go elsewhere. Ugly hack, but it works. --[[simonraven]]
 
+>> Here a simple [[patch]] for multiple sidebars. Not too fancy but better than having multiple copies of the sidebar plugin. --[[jeanprivat]]
+
+
+--- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
++++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
+@@ -19,12 +19,20 @@
+ 			safe => 1,
+ 			rebuild => 1,
+ 		},
++		active_sidebars => {
++			type => "string",
++			example => qw(sidebar banner footer),
++			description => "Which sidebars must be activated and processed.",
++			safe => 1,
++			rebuild => 1
++		},
+ }
+ 
+-sub sidebar_content ($) {
++sub sidebar_content ($$) {
+ 	my $page=shift;
++	my $sidebar=shift;
+ 	
+-	my $sidebar_page=bestlink($page, "sidebar") || return;
++	my $sidebar_page=bestlink($page, $sidebar) || return;
+ 	my $sidebar_file=$pagesources{$sidebar_page} || return;
+ 	my $sidebar_type=pagetype($sidebar_file);
+ 	
+@@ -49,11 +57,17 @@
+ 
+ 	my $page=$params{page};
+ 	my $template=$params{template};
+-	
+-	if ($template->query(name => "sidebar")) {
+-		my $content=sidebar_content($page);
+-		if (defined $content && length $content) {
+-		        $template->param(sidebar => $content);
++
++	my @sidebars;
++	if (defined $config{active_sidebars} && length $config{active_sidebars}) { @sidebars = @{$config{active_sidebars}}; }
++	else { @sidebars = qw(sidebar); }
++
++	foreach my $sidebar (@sidebars) {
++		if ($template->query(name => $sidebar)) {
++			my $content=sidebar_content($page, $sidebar);
++			if (defined $content && length $content) {
++				$template->param($sidebar => $content);
++			}
+ 		}
+ 	}
+ }
+
[[!tag wishlist]] -- cgit v1.2.3 From b849c63ce337f988fcbb08b39d197583e6fa6012 Mon Sep 17 00:00:00 2001 From: "http://dmarti.myopenid.com/" Date: Thu, 4 Mar 2010 00:15:00 +0000 Subject: --- doc/todo/salmon_protocol_for_comment_sharing.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/todo/salmon_protocol_for_comment_sharing.mdwn (limited to 'doc/todo') diff --git a/doc/todo/salmon_protocol_for_comment_sharing.mdwn b/doc/todo/salmon_protocol_for_comment_sharing.mdwn new file mode 100644 index 000000000..f4fa0c535 --- /dev/null +++ b/doc/todo/salmon_protocol_for_comment_sharing.mdwn @@ -0,0 +1,3 @@ +The Salmon protocol provides for aggregating comments across sites. If a site that syndicates a feed receives a comment on an item in that feed, it can re-post the comment to the original source. + +[[!tag wishlist]] -- cgit v1.2.3 From d72603534e677a4fbc0547ca3e5c9273d0d502ca Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 3 Mar 2010 19:48:23 -0500 Subject: comments --- doc/todo/salmon_protocol_for_comment_sharing.mdwn | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/salmon_protocol_for_comment_sharing.mdwn b/doc/todo/salmon_protocol_for_comment_sharing.mdwn index f4fa0c535..1e56b0a8b 100644 --- a/doc/todo/salmon_protocol_for_comment_sharing.mdwn +++ b/doc/todo/salmon_protocol_for_comment_sharing.mdwn @@ -1,3 +1,21 @@ -The Salmon protocol provides for aggregating comments across sites. If a site that syndicates a feed receives a comment on an item in that feed, it can re-post the comment to the original source. +The Salmon protocol +provides for aggregating comments across sites. If a site that syndicates +a feed receives a comment on an item in that feed, it can re-post the +comment to the original source. + +> Ikiwiki does not allow comments to be posted on items it aggregates. +> So salmon protocol support would only need to handle the comment +> receiving side of the protocol. +> +> The current draft protocol document confuses me when it starts talking +> about using OAuth in the abuse prevention section, since their example +> does not show use of OAuth, and it's not at all clear to me where the +> OAuth relationship between aggregator and original source is supposed +> to come from. +> +> Their security model, which goes on to include Webfinger, +> thirdparty validation services, XRD, and Magic Signatures, looks sorta +> like they kept throwing technology, at it, hoping something will stick. :-P +> --[[Joey]] [[!tag wishlist]] -- cgit v1.2.3 From 58a6847cfb445dbb87716e4064f8151cc44a233a Mon Sep 17 00:00:00 2001 From: "http://oneingray.myopenid.com/" Date: Fri, 12 Mar 2010 17:51:17 +0000 Subject: Note that, actually, SVG could be embedded into an Ikiwiki page, albeit in a somewhat crude manner. --- doc/todo/svg.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn index 89b183db6..2099751e3 100644 --- a/doc/todo/svg.mdwn +++ b/doc/todo/svg.mdwn @@ -57,3 +57,11 @@ in the trunk if other people think it's useful. [htmlscrubber.pm]:http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blob;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hb=fe333c8e5b4a5f374a059596ee698dacd755182d [diff]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073 + +* * * + +Actually, there's a way to embed SVG into MarkDown sources using the [data: URI scheme][rfc2397], [like this](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8c3ZnIHdpZHRoPSIxOTIiIGhlaWdodD0iMTkyIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KIDwhLS0gQ3JlYXRlZCB3aXRoIFNWRy1lZGl0IC0gaHR0cDovL3N2Zy1lZGl0Lmdvb2dsZWNvZGUuY29tLyAtLT4KIDx0aXRsZT5IZWxsbywgd29ybGQhPC90aXRsZT4KIDxnPgogIDx0aXRsZT5MYXllciAxPC90aXRsZT4KICA8ZyB0cmFuc2Zvcm09InJvdGF0ZSgtNDUsIDk3LjY3MTksIDk3LjY2OCkiIGlkPSJzdmdfNyI+CiAgIDxyZWN0IHN0cm9rZS13aWR0aD0iNSIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjRkYwMDAwIiBpZD0ic3ZnXzUiIGhlaWdodD0iNTYuMDAwMDAzIiB3aWR0aD0iMTc1IiB5PSI2OS42Njc5NjkiIHg9IjEwLjE3MTg3NSIvPgogICA8dGV4dCB4bWw6c3BhY2U9InByZXNlcnZlIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LWZhbWlseT0ic2VyaWYiIGZvbnQtc2l6ZT0iMjQiIHN0cm9rZS13aWR0aD0iMCIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjZmZmZjAwIiBpZD0ic3ZnXzYiIHk9IjEwNS42NjgiIHg9Ijk5LjY3MTkiPkhlbGxvLCB3b3JsZCE8L3RleHQ+CiAgPC9nPgogPC9nPgo8L3N2Zz4=). +Of course, this way to display an image one needs to click a link, but it may be considered a feature. +— [[Ivan_Shmakov]], 2010-03-12Z. + +[rfc2397]: http://tools.ietf.org/html/rfc2397 -- cgit v1.2.3 From 844bb8134b5ff6e3d73dc3c8b91ed516fa618c41 Mon Sep 17 00:00:00 2001 From: "http://oneingray.myopenid.com/" Date: Fri, 12 Mar 2010 18:33:10 +0000 Subject: Added an wishlist item. --- ...er_control_over___60__object___47____62__s.mdwn | 41 ++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 doc/todo/finer_control_over___60__object___47____62__s.mdwn (limited to 'doc/todo') diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn new file mode 100644 index 000000000..714f5ae50 --- /dev/null +++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn @@ -0,0 +1,41 @@ +IIUC, the current version of [HTML::Scrubber][] allows for the `object` tags to be either enabled or disabled entirely. However, while `object` can be used to add *code* (which is indeed a potential security hole) to a document, reading [Objects, Images, and Applets in HTML documents][objects-html] reveals that the “dangerous” are not all the `object`s, but rather those having the following attributes: + + classid %URI; #IMPLIED -- identifies an implementation -- + codebase %URI; #IMPLIED -- base URI for classid, data, archive-- + codetype %ContentType; #IMPLIED -- content type for code -- + archive CDATA #IMPLIED -- space-separated list of URIs -- + +It seems that the following attributes are, OTOH, safe: + + declare (declare) #IMPLIED -- declare but don't instantiate flag -- + data %URI; #IMPLIED -- reference to object's data -- + type %ContentType; #IMPLIED -- content type for data -- + standby %Text; #IMPLIED -- message to show while loading -- + height %Length; #IMPLIED -- override height -- + width %Length; #IMPLIED -- override width -- + usemap %URI; #IMPLIED -- use client-side image map -- + name CDATA #IMPLIED -- submit as part of form -- + tabindex NUMBER #IMPLIED -- position in tabbing order -- + +Should the former attributes be *scrubbed* while the latter left intact, the use of the `object` tag would seemingly become safe. + +Note also that allowing `object` (either restricted in such a way or not) automatically solves the [[/todo/svg]] issue. + +For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by the `data` and `usemap` attributes) to, say, relative and `data:` (as per [RFC 2397][]) ones as well, though it requires some more consideration. + +— [[Ivan_Shmakov]], 2010-03-12Z. + +[[wishlist]] + +## See also + +* [Objects, Images, and Applets in HTML documents][objects-html] +* [[plugins/htmlscrubber|/plugins/htmlscrubber]] +* [[todo/svg|/todo/svg]] +* [RFC 2397: The “data” URL scheme. L. Masinter. August 1998.][RFC 2397] +* [Uniform Resource Identifier — the free encyclopedia][URI] + +[HTML::Scrubber]: http://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm +[objects-html]: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html +[RFC 2397]: http://tools.ietf.org/html/rfc2397 +[URI]: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier -- cgit v1.2.3 From 556181d417e3461de56c43445ec9b2b0aefc7141 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 12 Mar 2010 14:29:54 -0500 Subject: data:image/svg is a security hole as javascript can presumably be inserted --- doc/todo/svg.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/svg.mdwn b/doc/todo/svg.mdwn index 2099751e3..274ebf3e3 100644 --- a/doc/todo/svg.mdwn +++ b/doc/todo/svg.mdwn @@ -58,6 +58,8 @@ in the trunk if other people think it's useful. [htmlscrubber.pm]:http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blob;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hb=fe333c8e5b4a5f374a059596ee698dacd755182d [diff]: http://xbeta.org/gitweb/?p=xbeta/ikiwiki.git;a=blobdiff;f=IkiWiki/Plugin/htmlscrubber.pm;h=3c0ddc8f25bd8cb863634a9d54b40e299e60f7df;hp=3bdaccea119ec0e1b289a0da2f6d90e2219b8d66;hb=fe333c8e5b4a5f374a059596ee698dacd755182d;hpb=be0b4f603f918444b906e42825908ddac78b7073 +> Unfortuantly these links are broken. --[[Joey]] + * * * Actually, there's a way to embed SVG into MarkDown sources using the [data: URI scheme][rfc2397], [like this](data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBzdGFuZGFsb25lPSJubyI/Pgo8c3ZnIHdpZHRoPSIxOTIiIGhlaWdodD0iMTkyIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGluayIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KIDwhLS0gQ3JlYXRlZCB3aXRoIFNWRy1lZGl0IC0gaHR0cDovL3N2Zy1lZGl0Lmdvb2dsZWNvZGUuY29tLyAtLT4KIDx0aXRsZT5IZWxsbywgd29ybGQhPC90aXRsZT4KIDxnPgogIDx0aXRsZT5MYXllciAxPC90aXRsZT4KICA8ZyB0cmFuc2Zvcm09InJvdGF0ZSgtNDUsIDk3LjY3MTksIDk3LjY2OCkiIGlkPSJzdmdfNyI+CiAgIDxyZWN0IHN0cm9rZS13aWR0aD0iNSIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjRkYwMDAwIiBpZD0ic3ZnXzUiIGhlaWdodD0iNTYuMDAwMDAzIiB3aWR0aD0iMTc1IiB5PSI2OS42Njc5NjkiIHg9IjEwLjE3MTg3NSIvPgogICA8dGV4dCB4bWw6c3BhY2U9InByZXNlcnZlIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LWZhbWlseT0ic2VyaWYiIGZvbnQtc2l6ZT0iMjQiIHN0cm9rZS13aWR0aD0iMCIgc3Ryb2tlPSIjMDAwMDAwIiBmaWxsPSIjZmZmZjAwIiBpZD0ic3ZnXzYiIHk9IjEwNS42NjgiIHg9Ijk5LjY3MTkiPkhlbGxvLCB3b3JsZCE8L3RleHQ+CiAgPC9nPgogPC9nPgo8L3N2Zz4=). @@ -65,3 +67,11 @@ Of course, this way to display an image one needs to click a link, but it may be — [[Ivan_Shmakov]], 2010-03-12Z. [rfc2397]: http://tools.ietf.org/html/rfc2397 + +> You can do the same with img src actually. +> +> If svg markup allows unsafe elements (ie, javascript), +> which it appears to, +> then this is a security hole, and the htmlscrubber +> needs to lock it down more. Darn, now I have to spend my afternoon making +> security releases! --[[Joey]] -- cgit v1.2.3 From 4711076fad54ff8152f03a7e4bdd4b5c2df1916c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 12 Mar 2010 15:00:39 -0500 Subject: clarify --- doc/todo/mercurial.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn index e71c8106a..de1f148e5 100644 --- a/doc/todo/mercurial.mdwn +++ b/doc/todo/mercurial.mdwn @@ -119,3 +119,11 @@ I have a few notes on mercurial usage after trying it out for a while: >> I think the ideal solution would be to build `$destdir/recentchanges/*` directly from the output of `hg log`. --[[buo]] >>>> That would be 100 times as slow, so I chose not to do that. --[[Joey]] + +>>>> Since this is confusing people, allow me to clarify: Ikiwiki's +>>>> recentchanges generation pulls log information directly out of the VCS as +>>>> needed. It caches it in recentchanges/* in the `scrdir`. These cache +>>>> files need not be preserved, should never be checked into VCS, and if +>>>> you want to you can configure your VCSignore file to ignore them, +>>>> just as you can configure it to ignore the `.ikiwiki` directory in the +>>>> `scrdir`. --[[Joey]] -- cgit v1.2.3 From 08485ec444cf81015e39c52e6ce8e7b933a036f6 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 12 Mar 2010 15:40:47 -0500 Subject: response --- doc/todo/finer_control_over___60__object___47____62__s.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn index 714f5ae50..ac4b55568 100644 --- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn +++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn @@ -27,6 +27,13 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by [[wishlist]] +> SVG can contain embedded javascript. The spec that you link to contains +> examples of objects that contain python scripts, Microsoft OLE +> objects, and Java. And then there's flash. I don't think ikiwiki can +> assume all the possibilities are handled securely, particularly WRT XSS +> attacks. +> --[[Joey]] + ## See also * [Objects, Images, and Applets in HTML documents][objects-html] -- cgit v1.2.3 From b5e27e60ba38365f3e252df80c2a22503f00eb06 Mon Sep 17 00:00:00 2001 From: "http://oneingray.myopenid.com/" Date: Fri, 12 Mar 2010 21:24:53 +0000 Subject: Note that still may be allowed, although in a form not suitable for, say, SVG inclusion. --- ...er_control_over___60__object___47____62__s.mdwn | 34 +++++++++++++++++++++- 1 file changed, 33 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn index ac4b55568..c37d052db 100644 --- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn +++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn @@ -27,13 +27,43 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by [[wishlist]] -> SVG can contain embedded javascript. The spec that you link to contains +> SVG can contain embedded javascript. + +>> Indeed. + +>> So, a more general tool (`XML::Scrubber`?) will be necessary to +>> refine both [XHTML][] and SVG. + +>> … And to leave [MathML][] as is (?.) + +>> — [[Ivan_Shmakov]], 2010-03-12Z. + +> The spec that you link to contains > examples of objects that contain python scripts, Microsoft OLE > objects, and Java. And then there's flash. I don't think ikiwiki can > assume all the possibilities are handled securely, particularly WRT XSS > attacks. > --[[Joey]] +>> I've scanned over all the `object` examples in the specification and +>> all of those that hold references to code (as opposed to data) have a +>> distinguishing `classid` attribute. + +>> While I won't assert that it's impossible to reference code with +>> `data` (and, thanks to `text/xhtml+xml` and `image/svg+xml`, it is +>> *not* impossible), throwing away any of the “insecure” +>> attributes listed above together with limiting the possible URI's +>> (i. e., only *local* and certain `data:` ones for `data` and +>> `usemap`) should make `object` almost as harmless as, say, `img`. + +>> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being +>> restricted in such a way.) + +>> Of the remaining issues I could only think of recursive +>> `object` — the one that references its container document. + +>> — [[Ivan_Shmakov]], 2010-03-12Z. + ## See also * [Objects, Images, and Applets in HTML documents][objects-html] @@ -43,6 +73,8 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by * [Uniform Resource Identifier — the free encyclopedia][URI] [HTML::Scrubber]: http://search.cpan.org/~podmaster/HTML-Scrubber-0.08/Scrubber.pm +[MathML]: http://en.wikipedia.org/wiki/MathML [objects-html]: http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html [RFC 2397]: http://tools.ietf.org/html/rfc2397 [URI]: http://en.wikipedia.org/wiki/Uniform_Resource_Identifier +[XHTML]: http://en.wikipedia.org/wiki/XHTML -- cgit v1.2.3 From 29ca20b87c565412fa603127425ccdaf4ca58b79 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Fri, 12 Mar 2010 16:50:04 -0500 Subject: response --- doc/todo/finer_control_over___60__object___47____62__s.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn index c37d052db..0ca949954 100644 --- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn +++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn @@ -56,6 +56,11 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by >> (i. e., only *local* and certain `data:` ones for `data` and >> `usemap`) should make `object` almost as harmless as, say, `img`. +>>> But with local data, one could not embed youtube videos, which surely +>>> is the most obvious use case? Note that youtube embedding uses an +>>> object element with no classid. The swf file is provided via an +>>> enclosed param element. --[[Joey]] + >> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being >> restricted in such a way.) -- cgit v1.2.3 From c26b6c3be864aaf49fe0b0fc15c0af59323b7dde Mon Sep 17 00:00:00 2001 From: "http://oneingray.myopenid.com/" Date: Fri, 12 Mar 2010 22:12:41 +0000 Subject: Note the use of on YouTube. --- .../finer_control_over___60__object___47____62__s.mdwn | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/finer_control_over___60__object___47____62__s.mdwn b/doc/todo/finer_control_over___60__object___47____62__s.mdwn index 0ca949954..50c4d43bf 100644 --- a/doc/todo/finer_control_over___60__object___47____62__s.mdwn +++ b/doc/todo/finer_control_over___60__object___47____62__s.mdwn @@ -57,10 +57,23 @@ For Ikiwiki, it may be nice to be able to restrict [URI's][URI] (as required by >> `usemap`) should make `object` almost as harmless as, say, `img`. >>> But with local data, one could not embed youtube videos, which surely ->>> is the most obvious use case? Note that youtube embedding uses an +>>> is the most obvious use case? + +>>>> Allowing a “remote” object to render on one's page is a + security issue by itself. + Though, of course, having an explicit whitelist of URI's may make + this issue more tolerable. + — [[Ivan_Shmakov]], 2010-03-12Z. + +>>> Note that youtube embedding uses an >>> object element with no classid. The swf file is provided via an >>> enclosed param element. --[[Joey]] +>>>> I've just checked a random video on YouTube and I see that the + `.swf` file is provided via an enclosed `embed` element. Whether + to allow those or not is a different issue. + — [[Ivan_Shmakov]], 2010-03-12Z. + >> (Though it certainly won't solve the [[SVG_problem|/todo/SVG]] being >> restricted in such a way.) -- cgit v1.2.3 From e8f6c06ca81e4ebd8d244e3863d21517d87b6620 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 17:29:06 -0500 Subject: update; openid email addresses now available so this is unblocked --- doc/todo/avatar.mdwn | 31 ++++++++++--------------------- 1 file changed, 10 insertions(+), 21 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn index b8aa2327f..4409e7b14 100644 --- a/doc/todo/avatar.mdwn +++ b/doc/todo/avatar.mdwn @@ -1,35 +1,24 @@ [[!tag wishlist]] It would be nice if ikiwiki, particularly [[plugins/comments]] -supported user avatar icons. I was considering adding a directive for this, -as designed below. +supported user avatar icons. -However, there is no *good* service for mapping openids to avatars -- -openavatar has many issues, including not supporting delegated openids, and -after trying it, I don't trust it to push users toward. -Perhaps instead ikiwiki could get the email address from the openid -provider, though I think the perl openid modules don't support the openid -2.x feature that allows that. - -At the moment, working on this doesn't feel like a good use of my time. ---[[Joey]] - -Hmm.. unless is just always used a single provider (gravatar) and hashed -the openid. Then wavatars could be used to get a unique avatar per openid -at least. --[[Joey]] - ----- - -The directive displays a small avatar image for a user. Pass it the -email address, openid, or wiki username of the user. +Idea is to add a directive that displays a small avatar image for a user. +Pass it the email address, openid, or wiki username of the user. \[[!avatar user@example.com]] \[[!avatar http://joey.kitenet.net/]] \[[!avatar user]] +These directives can then be hand-inserted onto pages, or more likely, +included in eg, a comment post via a template. Possibly included in a +recentchanges page item via that template too? + The avatars are provided by various sites. For email addresses, it uses a [gravatar](http://gravatar.com/). For openid, -[openavatar](http://www.openvatar.com/) is used. For a wiki username, the +[openavatar](http://www.openvatar.com/) could used, but I am not very happy +with it; probably better to just get the email via SREG (as is done now for +openid), and use that. For a wiki username, the user's email address is looked up and the gravatar for that user is displayed. (Of course, the user has to have filled in their email address on their Preferences page for that to work.) -- cgit v1.2.3 From e2c9b425415a00012b2c579c40c369da4ac7c98b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 17:46:28 -0500 Subject: thoughts --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 2cd52e8c4..ae427d540 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -6,6 +6,25 @@ I see this being implemented in one of two possible ways. The easiest seems like A slightly more complex next step would be to request sreg from the provider and, if provided, automatically set the identity's username and email address from the provided persona. If username login to accounts with blank passwords is disabled, then you have the best of both worlds. Passwordless signin, human-friendly attribution, automatic setting of preferences. +> Given that openids are a global user identifier, that can look as pretty +> as the user cares to make it look via delegation, I am not a fan of +> having a site-local identifier that layered on top of that. Perhaps +> partly because every site that I have seen that does that has openid +> implemented as a badly-done wart on the side of their regular login +> system. +> +> Openid Simple Registration is now used to populate the userdb with the +> email address for openid users. +> +> I am considering displaying the userid or fullname, if available, +> instead of the munged openid url in recentchanges. It would be nice +> for those nasty [[google_openids|forum/google_openid_broken?]]. But, +> I first have to find a way to encode the name in the VCS commit log, +> while still keeping the openid of the committer in there too. +> Perhaps something like this (for git): --[[Joey]] +> +> Author: Joey Hess + Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. [[!tag wishlist]] -- cgit v1.2.3 From 4f6c544fa8e7dd21450952f0a9fc3918ee600705 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:12:52 -0500 Subject: munge to avoid markdown eating email addresses --- doc/todo/git_attribution/discussion.mdwn | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/git_attribution/discussion.mdwn b/doc/todo/git_attribution/discussion.mdwn index dfb490bc2..6905d9b4b 100644 --- a/doc/todo/git_attribution/discussion.mdwn +++ b/doc/todo/git_attribution/discussion.mdwn @@ -72,7 +72,7 @@ no determination of uniqueness) > GIT_AUTHOR_EMAIL can also be set. > > There is one thing yet to be solved, and that is how to tell the -> difference between a web commit by 'Joey Hess ', +> difference between a web commit by 'Joey Hess ', > and a git commit by the same. I think we do want to differentiate these, > and the best way to do it seems to be to add a line to the end of the > commit message. Something like: "\n\nWeb-commit: true" @@ -94,5 +94,5 @@ no determination of uniqueness) > * github pushes to twitter ;-) > > So while I tried that way at first, I'm now leaning toward encoding the -> username in the email address. Like "user ", or -> "joey ". +> username in the email address. Like "user ", or +> "joey ". -- cgit v1.2.3 From 8f4f81cdfdcb68be5efb385dc07e4a0a04352a9d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:24:51 -0500 Subject: wrinkles --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 9 ++++++--- doc/todo/avatar.mdwn | 14 ++++++++++---- 2 files changed, 16 insertions(+), 7 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index ae427d540..3fb952f96 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -13,8 +13,9 @@ A slightly more complex next step would be to request sreg from the provider and > implemented as a badly-done wart on the side of their regular login > system. > -> Openid Simple Registration is now used to populate the userdb with the -> email address for openid users. +> The openid plugin now attempts to get an email and a username, and stores +> them in the session database for later use (ie, when the user edits a +> page). > > I am considering displaying the userid or fullname, if available, > instead of the munged openid url in recentchanges. It would be nice @@ -23,7 +24,9 @@ A slightly more complex next step would be to request sreg from the provider and > while still keeping the openid of the committer in there too. > Perhaps something like this (for git): --[[Joey]] > -> Author: Joey Hess +> Author: Joey Hess <http://joey.kitenet.net/@web> +> +> Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn index 4409e7b14..3a4e64b95 100644 --- a/doc/todo/avatar.mdwn +++ b/doc/todo/avatar.mdwn @@ -15,14 +15,20 @@ included in eg, a comment post via a template. Possibly included in a recentchanges page item via that template too? The avatars are provided by various sites. For email addresses, it uses a -[gravatar](http://gravatar.com/). For openid, -[openavatar](http://www.openvatar.com/) could used, but I am not very happy -with it; probably better to just get the email via SREG (as is done now for -openid), and use that. For a wiki username, the +[gravatar](http://gravatar.com/). For a wiki username, the user's email address is looked up and the gravatar for that user is displayed. (Of course, the user has to have filled in their email address on their Preferences page for that to work.) +For openid, openavatar sucked and is now dead. So we need to use an email +address instead, I guess. Problem is that the email address of a given +openid is only known when that user is logged in and making a change. +And we don't want to leak an openid user's email into a page either. +Hmm. Suppose the gravatar hash could be calculated from the email address +and embedded instead of the openid? + +Or, for openid, could use . + An optional second parameter can be included, containing additional options to pass in the [gravatar url](http://en.gravatar.com/site/implement/url). -- cgit v1.2.3 From 702c097ac29f1b208158936a99317ebad3e4116f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:40:20 -0500 Subject: update --- doc/todo/Separate_OpenIDs_and_usernames.mdwn | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 3fb952f96..7cfe49a5a 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -18,15 +18,25 @@ A slightly more complex next step would be to request sreg from the provider and > page). > > I am considering displaying the userid or fullname, if available, -> instead of the munged openid url in recentchanges. It would be nice -> for those nasty [[google_openids|forum/google_openid_broken?]]. But, -> I first have to find a way to encode the name in the VCS commit log, +> instead of the munged openid url in recentchanges and comments. +> It would be nice for those nasty [[google_openids|forum/google_openid_broken?]]. +> But, I first have to find a way to encode the name in the VCS commit log, > while still keeping the openid of the committer in there too. > Perhaps something like this (for git): --[[Joey]] > > Author: Joey Hess <http://joey.kitenet.net/@web> > +> So, what needs to be done: > +> * Change `rcs_commit` and `rcs_commit_staged` to take a session object, +> instead of just a userid. (For back-compat, if the parameter is +> not an object, it's a userid.) Bump ikiwiki plugin interface version. +> * Modify all RCS plugins to include the session username somewhere +> in the commit, and parse it back out in `rcs_recentchanges`. +> * Modify recentchanges plugin to display the username instead of the +> `openiduser`. +> * Modify comment plugin to put the session username in the comment +> template instead of the `openiduser`. Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat. -- cgit v1.2.3 From fd43e83fcf7bf24493ecfff54111c1c5f1cab573 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 19:56:54 -0500 Subject: update --- doc/forum/google_openid_broken__63__.mdwn | 13 +++++++++++++ doc/todo/Separate_OpenIDs_and_usernames.mdwn | 7 +++++++ 2 files changed, 20 insertions(+) (limited to 'doc/todo') diff --git a/doc/forum/google_openid_broken__63__.mdwn b/doc/forum/google_openid_broken__63__.mdwn index 0e41d4ced..4ca5cac93 100644 --- a/doc/forum/google_openid_broken__63__.mdwn +++ b/doc/forum/google_openid_broken__63__.mdwn @@ -58,3 +58,16 @@ points to a fairly useless xml document, rather than a web page. --[[Joey]] > I've added buttons that submit the two above URLs for logging in with a Google and Yahoo OpenID, respectively, to my locally changed OpenID login plugin. > Using the Google profile page as the OpenID is really orthogonal to the above. --[[kaol]] + +>> Displaying email addresses is not really an option, because ikiwiki +>> can't leak user email addresses like that. Displaying nicknames or +>> usernames is, see [[todo/Separate_OpenIDs_and_usernames]]. +>> +>> It would probably be good if the openid plugin could be configured with +>> a list of generic openid urls, so it can add quick login buttons using +>> those urls. +>> +>> The ugly google url will still be exposed here and there where +>> a unique user id is needed. That can be avoided by not using the generic +>> , but instead your own profile +>> like . --[[Joey]] diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn index 7cfe49a5a..fcdb49f6d 100644 --- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn +++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn @@ -26,6 +26,13 @@ A slightly more complex next step would be to request sreg from the provider and > > Author: Joey Hess <http://joey.kitenet.net/@web> > +> Only problem with the above is that the openid will still be displayed +> by CIA. Other option is this, which solves that, but at the expense of +> having to munge the username to fit inside the email address, +> and generally seems backwards: --[[Joey]] +> +> Author: http://joey.kitenet.net/ <Joey_Hess@web> +> > So, what needs to be done: > > * Change `rcs_commit` and `rcs_commit_staged` to take a session object, -- cgit v1.2.3 From 725a1cf0e8d1fbdb7f449b632ee1fa3cb84835c7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 13 Mar 2010 20:45:44 -0500 Subject: update; bleargh --- doc/todo/avatar.mdwn | 50 ++++++++++++++++++++++++++++++++++---------------- 1 file changed, 34 insertions(+), 16 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn index 3a4e64b95..f0599e4ed 100644 --- a/doc/todo/avatar.mdwn +++ b/doc/todo/avatar.mdwn @@ -1,42 +1,60 @@ [[!tag wishlist]] It would be nice if ikiwiki, particularly [[plugins/comments]] -supported user avatar icons. +(but also, ideally, recentchanges) supported user avatar icons. Idea is to add a directive that displays a small avatar image for a user. -Pass it the email address, openid, or wiki username of the user. +Pass it a user's the email address, openid, username, or the md5 hash +of their email address: \[[!avatar user@example.com]] \[[!avatar http://joey.kitenet.net/]] \[[!avatar user]] + \[[!avatar hash]] These directives can then be hand-inserted onto pages, or more likely, -included in eg, a comment post via a template. Possibly included in a -recentchanges page item via that template too? +included in eg, a comment post via a template. + +An optional second parameter can be included, containing additional +options to pass in the +[gravatar url](http://en.gravatar.com/site/implement/url). +For example, this asks for a smaller gravatar, and if a user does +not have a gravatar, uses a cute auto-generated "wavatar" avatar. + + \[[!gravatar user@example.com "size=40&default=wavatar"]] + +The `gravitar_options` setting in the setup file can be used to +specify additional options to pass. So for example if you want +to use wavatars everywhere, set it to "default=wavatar". The avatars are provided by various sites. For email addresses, it uses a [gravatar](http://gravatar.com/). For a wiki username, the user's email address is looked up and the gravatar for that user is displayed. (Of course, the user has to have filled in their email address -on their Preferences page for that to work.) +on their Preferences page for that to work. Also, when the user changes +their email address in Preferences, the gravatar won't change until the +wiki is rebuilt.) For openid, openavatar sucked and is now dead. So we need to use an email address instead, I guess. Problem is that the email address of a given openid is only known when that user is logged in and making a change. And we don't want to leak an openid user's email into a page either. Hmm. Suppose the gravatar hash could be calculated from the email address -and embedded instead of the openid? +and embedded instead of the openid? That would work for comments, +but not if the directive were used elsewhere. -Or, for openid, could use . +Or, for openid, could use . Which +works fine, but users are not likely to figure out what they need to do to +get an avatar associated with their openid. -An optional second parameter can be included, containing additional -options to pass in the -[gravatar url](http://en.gravatar.com/site/implement/url). -For example, this asks for a smaller gravatar, and if a user does -not have a gravatar, uses a cute auto-generated "wavatar" avatar. +--- - \[[!gravatar user@example.com "size=40&default=wavatar"]] +Alternative, not overdesigned approach: -The `gravitar_options` setting in the setup file can be used to -specify additional options to pass. So for example if you want -to use wavatars everywhere, set it to "default=wavatar". +Modify comments plugin to have an option to display avatars. + +When posting a comment, fill in the avatarhash field in the template. +The hash is calculated from the user's email address. If the user's email +is not known, skip it. + +End. :P -- cgit v1.2.3 From 823ec815d4fc9625d6fa3553ad03e9f2ff737659 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 14 Mar 2010 14:58:13 -0400 Subject: Add a include setting, which can be used to make ikiwiki process wiki source files, such as .htaccess, that would normally be skipped for security or other reasons. Closes: #447267 (Thanks to Aaron Wilson for the original patch.) --- IkiWiki.pm | 13 +++++++++++++ debian/changelog | 4 ++++ doc/tips/htaccess_file.mdwn | 30 ++++++++++++++++++++++++++++++ doc/todo/enable-htaccess-files.mdwn | 5 +++++ doc/usage.mdwn | 6 ++++++ ikiwiki.in | 3 +++ 6 files changed, 61 insertions(+) create mode 100644 doc/tips/htaccess_file.mdwn (limited to 'doc/todo') diff --git a/IkiWiki.pm b/IkiWiki.pm index 251ed8cc8..ee94ce659 100644 --- a/IkiWiki.pm +++ b/IkiWiki.pm @@ -334,6 +334,15 @@ sub getsetup () { safe => 0, # paranoia rebuild => 0, }, + include => { + type => "string", + default => undef, + example => '^\.htaccess$', + description => "regexp of normally ignored source files to include", + advanced => 1, + safe => 0, # regexp + rebuild => 1, + }, exclude => { type => "string", default => undef, @@ -1820,6 +1829,10 @@ sub file_pruned ($;$) { $file =~ s#^\Q$base\E/+##; } + if (defined $config{include} && length $config{include}) { + return 0 if $file =~ m/$config{include}/; + } + my $regexp='('.join('|', @{$config{wiki_file_prune_regexps}}).')'; return $file =~ m/$regexp/; } diff --git a/debian/changelog b/debian/changelog index 92afe661f..e5347e2a1 100644 --- a/debian/changelog +++ b/debian/changelog @@ -8,6 +8,10 @@ ikiwiki (3.20100313) UNRELEASED; urgency=low as used by yahoo and google urls. * Add complete German basewiki and directives translation done by Sebastian Kuhnert. + * Add a include setting, which can be used to make ikiwiki process + wiki source files, such as .htaccess, that would normally be skipped + for security or other reasons. Closes: #447267 + (Thanks to Aaron Wilson for the original patch.) -- Joey Hess Sat, 13 Mar 2010 14:48:10 -0500 diff --git a/doc/tips/htaccess_file.mdwn b/doc/tips/htaccess_file.mdwn new file mode 100644 index 000000000..5266eba41 --- /dev/null +++ b/doc/tips/htaccess_file.mdwn @@ -0,0 +1,30 @@ +If you try to include a `.htaccess` file in your wiki's source, in order to +configure the web server, you'll find that ikiwiki excludes it from +processing. In fact, ikiwiki excludes any file starting with a dot, as well +as a lot of other files, for good security reasons. + +You can tell ikiwiki not to exclude the .htaccess file by adding this to +your setup file: + + include => '^\.htaccess$', + +Caution! Before you do that, please think for a minute about who can edit +your wiki. Are attachment uploads enabled? Can users commit changes +directly to the version control system? Do you trust everyone who can +make a change to not do Bad Things with the htaccess file? Do you trust +everyone who *might* be able to make a change in the future? Note that a +determined attacker who can write to the htaccess file can probably get a +shell on your web server. + +If any of these questions have given you pause, I suggest you find a +different way to configure the web server. One way is to not put the +`.htaccess` file under ikiwiki's control, and just manually install it +in the destdir. + +[Apache's documentation](http://httpd.apache.org/docs/1.3/howto/htaccess.html) +says +> In general, you should never use .htaccess files unless you don't have +> access to the main server configuration file. +This is good advice -- if you can edit apache's main configuration files, +then you should not use a htaccess file. +--[[Joey]] diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index 412cb5eba..c895db75d 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -61,3 +61,8 @@ It should be off by default of course. --Max +1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]] > I've described a workaround for one use case at the [[plugins/rsync]] [[plugins/rsync/discussion]] page. --[[schmonz]] + +--- + +[[done]], you can use the `include` setting to override the default +excludes now. Please use extreme caution when doing so. --[[Joey]] diff --git a/doc/usage.mdwn b/doc/usage.mdwn index a105d7e59..f735170f0 100644 --- a/doc/usage.mdwn +++ b/doc/usage.mdwn @@ -234,6 +234,12 @@ also be configured using a setup file. Specifies a rexexp of source files to exclude from processing. May be specified multiple times to add to exclude list. +* --include regexp + + Specifies a rexexp of source files, that would normally be excluded, + but that you wish to include in processing. + May be specified multiple times to add to include list. + * --adminuser name Specifies a username of a user (or, if openid is enabled, an openid) diff --git a/ikiwiki.in b/ikiwiki.in index ae1251ff6..da5555629 100755 --- a/ikiwiki.in +++ b/ikiwiki.in @@ -65,6 +65,9 @@ sub getconfig () { "exclude=s@" => sub { push @{$config{wiki_file_prune_regexps}}, $_[1]; }, + "include=s@" => sub { + $config{include}=defined $config{include} && length $config{include} ? "$config{include}|$_[1]" : $_[1]; + }, "adminuser=s@" => sub { push @{$config{adminuser}}, $_[1] }, -- cgit v1.2.3 From a5ee40104481ba06eaaf277ed2f6c363dd326608 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 14 Mar 2010 15:08:41 -0400 Subject: note that the patch on this page is complely broken, and allows any file starting with a dot to be included If you applied that patch to your site, you should remove it right away! --- doc/todo/enable-htaccess-files.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index c895db75d..c08502bdd 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -12,6 +12,13 @@ qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//], wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/, +> Note that the above patch is **completely broken**. +> It removes the crucial excludes of all files starting with a dot. +> The negative regexps for htaccess have no effect, so the whole +> thing only "works" because it allows *any* file starting with a dot. +> If you applied this patch to your ikiwiki, you opened a huge security +> hole. --[[Joey]] + [[!tag patch patch/core]] This lets the site administrator have a `.htaccess` file in their underlay -- cgit v1.2.3 From 223b8efab0a55075bd53d03fe3cb2df07f13d9c1 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 14 Mar 2010 15:12:59 -0400 Subject: update --- doc/todo/enable-htaccess-files.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index c08502bdd..3b9721d50 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -64,6 +64,11 @@ It should be off by default of course. --Max --- +1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]] +> Unless you cannot modify apache's configuration, you do not need htaccess +> to do that. Apache's documentation recommends against using htaccess +> unless you're a user who cannot modify the main server configuration. +> --[[Joey]] + --- +1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]] -- cgit v1.2.3 From 4054f8d8ce0802b43e1c2c6f9cb71badbbcaf919 Mon Sep 17 00:00:00 2001 From: kierun Date: Wed, 17 Mar 2010 09:14:46 +0000 Subject: --- doc/todo/ACL.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn index d40701d60..57979385d 100644 --- a/doc/todo/ACL.mdwn +++ b/doc/todo/ACL.mdwn @@ -76,3 +76,12 @@ Any idea when this is going to be finished? If you want, I am happy to beta tes > Example of use to only allow two users to edit the tipjar page: > locked_pages => 'tipjar and !(user(joey) or user(bob))', > --[[Joey]] + +> > Thank you for the hint but I am being still confused (read: dense)... What I am trying to do is this: + +> > * No anonymous access. +> > * Logged in users can edit and create pages. +> > * Users can set who can edit their pages. +> > * Some pages are only viewable by admins. + +> > Is it possible? If so how?... -- cgit v1.2.3 From ea07442e7ac6ef80cd98625b32f66bafc6af26b5 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Thu, 18 Mar 2010 15:21:38 +0000 Subject: comment --- doc/todo/ACL.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn index 57979385d..c1f5d86f0 100644 --- a/doc/todo/ACL.mdwn +++ b/doc/todo/ACL.mdwn @@ -21,6 +21,11 @@ something, that I think is very valuable. >>>> Which would rule out openid, or other fun forms of auth. And routing all access >>>> through the CGI sort of defeats the purpose of ikiwiki. --[[Ethan]] +>>>>> I think what Joey is suggesting is to use apache ACLs in conjunction +>>>>> with basic HTTP auth to control read access, and ikiwiki can use the +>>>>> information via the httpauth plugin for other ACLs (write, admin). But +>>>>> yes, that would rule out non-httpauth mechanisms. -- [[Jon]] + Also see [[!debbug 443346]]. > Just a few quick thoughts about this: -- cgit v1.2.3 From 760c315589dc0e3fa0ba5380113f4e86a989a7d9 Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Thu, 18 Mar 2010 15:23:18 +0000 Subject: comment --- doc/todo/ACL.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn index c1f5d86f0..cac6c9f18 100644 --- a/doc/todo/ACL.mdwn +++ b/doc/todo/ACL.mdwn @@ -90,3 +90,6 @@ Any idea when this is going to be finished? If you want, I am happy to beta tes > > * Some pages are only viewable by admins. > > Is it possible? If so how?... + +>>> I don't believe this is currently possible. What is missing is the concept +>>> of page 'ownership'. -- [[Jon]] -- cgit v1.2.3 From 96a54b35fe2cdcdc1450b5d38c80e7b27b428c14 Mon Sep 17 00:00:00 2001 From: kierun Date: Fri, 19 Mar 2010 15:45:26 +0000 Subject: --- doc/todo/ACL.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/ACL.mdwn b/doc/todo/ACL.mdwn index cac6c9f18..dd9793233 100644 --- a/doc/todo/ACL.mdwn +++ b/doc/todo/ACL.mdwn @@ -93,3 +93,6 @@ Any idea when this is going to be finished? If you want, I am happy to beta tes >>> I don't believe this is currently possible. What is missing is the concept >>> of page 'ownership'. -- [[Jon]] + +>>>> GAH! That is really a shame... Any chance of adding that? No, I do not really expect it to be added, after all my requirements are pushing the boundary of what a wikiwiki + should be. Nonetheless, thanks for your help! -- cgit v1.2.3 From 1c7d5eabd7c9e94498af7f89a005311a850d742c Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Wed, 24 Mar 2010 03:24:15 +0000 Subject: propsed branch --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 47 ++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 doc/todo/allow_plugins_to_add_sorting_methods.mdwn (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn new file mode 100644 index 000000000..3aa1d94a6 --- /dev/null +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -0,0 +1,47 @@ +[[!template id=gitbranch branch=smcv/sort-hooks author="[[Simon_McVittie|smcv]]"]] +[[!tag patch]] + +The available [[ikiwiki/pagespec/sorting]] methods are currently hard-coded in +IkiWiki.pm, making it difficult to add any extra sorting mechanisms. I've +prepared a branch which adds 'sort' as a hook type and uses it to implement a +new `meta_title` sort type. + +Someone could use this hook to make `\[[!inline sort=title]]` prefer the meta +title over the page name, but for compatibility, I'm not going to (I do wonder +whether it would be worth making sort=name an alias for the current sort=title, +and changing the meaning of sort=title in 4.0, though). + +Gitweb: + + +## Documentation extracted from the branch + +### sort hook (added to [[plugins/write]]) + + hook(type => "sort", id => "foo", call => \&sort_by_foo); + +This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides +an existing one. The callback is given two page names as arguments, and +returns negative, zero or positive if the first page should come before, +close to (i.e. undefined order), or after the second page. + +For instance, the built-in `title` sort order could be reimplemented as + + sub sort_by_title { + pagetitle(basename($_[0])) cmp pagetitle(basename($_[1])); + } + +### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]]) + +* `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]` + or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no + full title was set. + +### meta title sort parameter (added to [[ikiwiki/directive/meta]]) + +An optional `sort` parameter will be used preferentially when +[[ikiwiki/pagespec/sorting]] by `meta_title`: + + \[[!meta title="The Beatles" sort="Beatles, The"]] + + \[[!meta title="David Bowie" sort="Bowie, David"]] -- cgit v1.2.3 From 7fbddb032ee952c6d0b1ee290568ea4f42ef181f Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Wed, 24 Mar 2010 03:27:11 +0000 Subject: link to an alternative approach that I decided against --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn index 3aa1d94a6..1533b6c44 100644 --- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -14,6 +14,12 @@ and changing the meaning of sort=title in 4.0, though). Gitweb: +I briefly tried to turn *all* the current sort types into hook functions, and +have some of them pre-registered, but decided that probably wasn't a good idea. +That earlier version of the branch is also available for comparison: + + + ## Documentation extracted from the branch ### sort hook (added to [[plugins/write]]) -- cgit v1.2.3 From 48c09d44637dd724d084b1d06e2277f11e80d489 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Wed, 24 Mar 2010 03:30:06 +0000 Subject: note: old version untested --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn index 1533b6c44..99f256fbe 100644 --- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -20,6 +20,11 @@ That earlier version of the branch is also available for comparison: +(The older version is untested, and probably doesn't really work as-is - I +misunderstood the details of how the built-in function `sort` works when using +`$a` and `$b`. The newer version has been tested, and has a regression test for +its core functionality.) + ## Documentation extracted from the branch ### sort hook (added to [[plugins/write]]) -- cgit v1.2.3 From 9d4bedf760fbbbdba28986c01c3e429f67386217 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Wed, 24 Mar 2010 17:11:17 +0000 Subject: relationship with [[plugins/contrib/report]] --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn index 99f256fbe..21800f4de 100644 --- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -25,6 +25,21 @@ misunderstood the details of how the built-in function `sort` works when using `$a` and `$b`. The newer version has been tested, and has a regression test for its core functionality.) +This hook *isn't* (yet) sufficient to implement [[plugins/contrib/report]]'s +NIH'd sorting mechanisms: + +* `report` can sort by any [[plugins/contrib/field]], whereas this one has a + finite number of hooks: if the `field` plugin's functionality is desirable, + perhaps parameterized sort mechanisms similar to pagespec match functions + would be useful? Then the `field` plugin could register + `hook(type => "sort", id => "field")` and you could have + `\[[!inline ... sort="field(Mood)"]]` or something? + +* `report` can sort by multiple criteria, with independent direction-changing: + if this is desirable, perhaps `pagespec_match_list` could be enhanced to + interpret `sort="x -y z(w)"` as sorting by (pseudocode) + `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`? + ## Documentation extracted from the branch ### sort hook (added to [[plugins/write]]) -- cgit v1.2.3 From 1a587504e949bf0584acdf7737597c8332467332 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Wed, 24 Mar 2010 22:48:47 +0000 Subject: what about a SortSpec rather than a sort-hook? --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn index 21800f4de..5bfe102ac 100644 --- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -40,6 +40,8 @@ NIH'd sorting mechanisms: interpret `sort="x -y z(w)"` as sorting by (pseudocode) `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`? +>> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages? Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]] + ## Documentation extracted from the branch ### sort hook (added to [[plugins/write]]) -- cgit v1.2.3 From 81cd30690024db1fc0b300e3a09504f1c613be21 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Thu, 25 Mar 2010 00:05:58 +0000 Subject: an updated branch --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 29 +++++++++++++++++++++- 1 file changed, 28 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn index 5bfe102ac..419a73419 100644 --- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -40,8 +40,13 @@ NIH'd sorting mechanisms: interpret `sort="x -y z(w)"` as sorting by (pseudocode) `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`? +> I've now added both of these features to the sort-hooks branch. --[[smcv]] + >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages? Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]] +>>> I'd be inclined to think that's overkill, but it probably wouldn't be +>>> all that hard to implement... Joey? Any thoughts? --s + ## Documentation extracted from the branch ### sort hook (added to [[plugins/write]]) @@ -49,7 +54,9 @@ NIH'd sorting mechanisms: hook(type => "sort", id => "foo", call => \&sort_by_foo); This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides -an existing one. The callback is given two page names as arguments, and +an existing one. + +The callback is given two page names followed by the parameter as arguments, and returns negative, zero or positive if the first page should come before, close to (i.e. undefined order), or after the second page. @@ -59,12 +66,32 @@ For instance, the built-in `title` sort order could be reimplemented as pagetitle(basename($_[0])) cmp pagetitle(basename($_[1])); } +and to sort by an arbitrary `meta` value, you could use: + + # usage: sort="meta(description)" + sub sort_by_meta { + my $param = $_[2]; + error "sort=meta requires a parameter" unless defined $param; + my $left = $pagestate{$_[0]}{meta}{$param}; + $left = "" unless defined $left; + my $right = $pagestate{$_[1]}{meta}{$param}; + $right = "" unless defined $right; + return $left cmp $right; + } + + ### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]]) * `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]` or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no full title was set. +### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]]) + +In addition, you can combine several sort orders and/or reverse the order of +sorting, with a string like `age -title` (which would sort by age, then by +title in reverse order if two pages have the same age). + ### meta title sort parameter (added to [[ikiwiki/directive/meta]]) An optional `sort` parameter will be used preferentially when -- cgit v1.2.3 From 959d5b197d842e494076034f89d7bca84e531a45 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Thu, 25 Mar 2010 23:39:45 +0000 Subject: an alternative way to do plugins, as rubykat suggested --- doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 37 ++++++++++++++++++++-- 1 file changed, 34 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn index 419a73419..f37a0758e 100644 --- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn +++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn @@ -44,10 +44,13 @@ NIH'd sorting mechanisms: >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages? Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]] ->>> I'd be inclined to think that's overkill, but it probably wouldn't be ->>> all that hard to implement... Joey? Any thoughts? --s +>>> [[!template id=gitbranch branch=smcv/sort-package author="[[Simon_McVittie|smcv]]"]] +>>> I'd be inclined to think that's overkill, but it wasn't very hard to +>>> implement, and in a way is more elegant. I set it up so sort mechanisms +>>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb: +>>> -## Documentation extracted from the branch +## Documentation from sort-hooks branch ### sort hook (added to [[plugins/write]]) @@ -100,3 +103,31 @@ An optional `sort` parameter will be used preferentially when \[[!meta title="The Beatles" sort="Beatles, The"]] \[[!meta title="David Bowie" sort="Bowie, David"]] + +## Documentation from sort-hooks branch + +The changes to [[ikiwiki/pagespec/sorting]] are the same. +The changes to [[plugins/write]] are replaced by: + +### Sorting plugins + +Similarly, it's possible to write plugins that add new functions as +[[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to +the IkiWiki::PageSpec package named `cmp_foo`, which will be used when sorting +by `foo` or `foo(...)` is requested. + +The function will be passed three or more parameters. The first two are +page names, and the third is `undef` if invoked as `foo`, or the parameter +`"bar"` if invoked as `foo(bar)`. It may also be passed additional, named +parameters. + +It should return the same thing as Perl's `cmp` and `<=>` operators: negative +if the first argument is less than the second, positive if the first argument +is greater, or zero if they are considered equal. It may also raise an +error using `error`, for instance if it needs a parameter but one isn't +provided. + +You can also define a function called `check_cmp_foo` in the same package. +If you do, it will be called while preparing to sort by `foo` or `foo(bar)`, +with argument `undef` or `"bar"` respectively; it may raise an error using +`error`, if sorting like that isn't going to work. -- cgit v1.2.3 From 263d9548969dcdf9a6add96f46fe03ba7701a1ca Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 29 Mar 2010 14:58:21 +0100 Subject: ping joey: consider patch for next release? --- doc/todo/allow_site-wide_meta_definitions.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 99a9cf1e2..be66db99d 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -183,3 +183,5 @@ definitions essentially. >>> ikiwiki for the break, and now I've returned to watching recentchanges. >>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have >>> you had a chance to look at this yet? -- [[Jon]] +>>>> Ping :) Hi. [[Joey]], would you consider this patch for the next +>>>> ikiwiki release? -- [[Jon]] -- cgit v1.2.3 From 97898ce585b36dbcb0a83356ef3e54c41d369437 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 29 Mar 2010 12:16:53 -0400 Subject: review, multiple concerns --- doc/todo/allow_site-wide_meta_definitions.mdwn | 46 ++++++++++++++++++++++++++ 1 file changed, 46 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 99a9cf1e2..e4638f94b 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -36,6 +36,30 @@ definitions essentially. >> I've made may not be acceptable, though -- I'd appreciate someone providing >> some feedback on that hunk! +>>> Well, re that hunk, taint checking is currently disabled, but +>>> if the perl bug that disallows it is fixed and it is turned back on, +>>> the hash values will remain tainted, which will probably lead to +>>> problems. +>>> +>>> I'm also leery of using such a complex data structure in config. +>>> The websetup plugin would be hard pressed to provide a UI for such a +>>> data structure. (It lacks even UI for a single hash ref yet, let alone +>>> a list.) +>>> +>>> Also, it seems sorta wrong to have two so very different syntaxes to +>>> represent the same meta data. A user without a lot of experience will +>>> be hard pressed to map from a directive to this in the setup file. +>>> +>>> All of which leads me to think the setup file could just contain +>>> a text that could hold meta directives. Which generalizes really to +>>> a text that contains any directives, and is, perhaps appended to the +>>> top of every page. Which nearly generalizes to the sidebar plugin, +>>> or perhaps something more general than that... +>>> +>>> However, excessive generalization is the root of all evil, so +>>> I'm not necessarily saying that's a good idea. Indeed, my memory +>>> concerns below invalidate this idea pretty well. --[[Joey]] + diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm index 6fe9cda..2f8c098 100644 --- a/IkiWiki/Plugin/meta.pm @@ -125,6 +149,10 @@ definitions essentially. >> are only relevant to defined fields that you wouldn't want to specify a >> global default for anyway. >> +>>> I generally agree with this. It is *possible* that meta would have a new +>>> field added, that takes parameters and make sense to use globally. +>>> --[[Joey]] +>> >> Due to this, and the added complexity of the second patch (having to adjust >> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus >> reverted to it here. @@ -183,3 +211,21 @@ definitions essentially. >>> ikiwiki for the break, and now I've returned to watching recentchanges. >>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have >>> you had a chance to look at this yet? -- [[Jon]] + +>>> For this to work with websetup and --dumpsetup, it needs to define the +>>> `meta_*` settings in the getsetup function. +>>> +>>> I also have some concerns about both these patches, since both throw +>>> a lot of redundant data at meta, which then stores it in a very redundant +>>> way. Specifically, meta populates a per-page `%metaheaders` hash +>>> as well as storing per-page metadata in `%pagestate`. So, if you have +>>> a wiki with a thousand pages, and you add a 1k site-wide license text, +>>> that will bloat the memory usage of ikiwiki by in excess of 2 +>>> megabytes. It will also cause ikiwiki to write a similar amount more data +>>> to its state file which has to be loaded back in each +>>> run. +>>> +>>> Seems that this could be managed much more efficiently by having +>>> meta special-case the site-wide settings, not store them in these +>>> per-page data structures, and just make them be used if no per-page +>>> metadata of the given type is present. --[[Joey]] -- cgit v1.2.3 From 7a8bcf2a6745d570bf9055df7b0390f9a9ca8a0d Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 29 Mar 2010 12:19:22 -0400 Subject: fix bogus math --- doc/todo/allow_site-wide_meta_definitions.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 704cb2c64..01cf12c1a 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -222,7 +222,7 @@ definitions essentially. >>> a lot of redundant data at meta, which then stores it in a very redundant >>> way. Specifically, meta populates a per-page `%metaheaders` hash >>> as well as storing per-page metadata in `%pagestate`. So, if you have ->>> a wiki with a thousand pages, and you add a 1k site-wide license text, +>>> a wiki with 10 thousand pages, and you add a 1k site-wide license text, >>> that will bloat the memory usage of ikiwiki by in excess of 2 >>> megabytes. It will also cause ikiwiki to write a similar amount more data >>> to its state file which has to be loaded back in each -- cgit v1.2.3 From 675e34527f56021ce39e56e4288e8f0e32b36cfa Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 29 Mar 2010 19:59:40 +0100 Subject: thanks for the review, patch to be revised --- doc/todo/allow_site-wide_meta_definitions.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 01cf12c1a..7129a44ac 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -232,3 +232,6 @@ definitions essentially. >>> meta special-case the site-wide settings, not store them in these >>> per-page data structures, and just make them be used if no per-page >>> metadata of the given type is present. --[[Joey]] + +>>>> Thanks for the review - these are all valid points. I'll get working +>>>> on a revised patch. -- [[Jon]] -- cgit v1.2.3 From 0b63800df32fd6e5287a253ca01a099f79b77e6e Mon Sep 17 00:00:00 2001 From: Jon Dowland Date: Mon, 29 Mar 2010 20:00:56 +0100 Subject: this sounds like the correct approach --- doc/todo/more_flexible_inline_postform.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/more_flexible_inline_postform.mdwn b/doc/todo/more_flexible_inline_postform.mdwn index bc8bc0809..414476bd7 100644 --- a/doc/todo/more_flexible_inline_postform.mdwn +++ b/doc/todo/more_flexible_inline_postform.mdwn @@ -16,3 +16,8 @@ logical first step towards doing comment-like things with inlined pages). > Perhaps what we need is a `postform` plugin/directive that inline depends > on (automatically enables); its preprocess method could automatically be > invoked from preprocess_inline when needed. --[[smcv]] + +>> I've been looking at this stuff again. I think you are right, this would +>> be the right approach. The comments plugin could use it similarly, allowing +>> sites which desire it to have an inline comment submission form on all +>> pages with comments enabled. I'm going to take a look. -- [[Jon]] -- cgit v1.2.3 From f673ce266c8dadb263c6850cc5f7d3e6e7a68e70 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Tue, 30 Mar 2010 12:01:35 +0000 Subject: feature request (part of ftemplate) --- doc/todo/user-defined_templates_outside_the_wiki.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/todo/user-defined_templates_outside_the_wiki.mdwn (limited to 'doc/todo') diff --git a/doc/todo/user-defined_templates_outside_the_wiki.mdwn b/doc/todo/user-defined_templates_outside_the_wiki.mdwn new file mode 100644 index 000000000..880ad6493 --- /dev/null +++ b/doc/todo/user-defined_templates_outside_the_wiki.mdwn @@ -0,0 +1,8 @@ +[[!tag wishlist]] + +The [[plugins/contrib/ftemplate]] plugin looks for templates inside the wiki +source, but also looks in the system templates directory (the one with +`page.tmpl`). This means the wiki admin can provide templates that can be +invoked via `\[[!template]]`, but don't have to "work" as wiki pages in their +own right. I think the normal [[plugins/template]] plugin could benefit from +this functionality. -- cgit v1.2.3 From a7ef2204dc36777f847e282f57299d93342a8ad6 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Thu, 1 Apr 2010 23:40:37 +0000 Subject: implemented! --- doc/todo/matching_different_kinds_of_links.mdwn | 51 +++++++++++++++++++++++++ 1 file changed, 51 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn index 26c5a072b..0049281fe 100644 --- a/doc/todo/matching_different_kinds_of_links.mdwn +++ b/doc/todo/matching_different_kinds_of_links.mdwn @@ -36,6 +36,11 @@ Besides pagespecs, the `rel=` attribute could be used for styles. --Ivan Z. > normal links.) Might be better to go ahead and add the variable to > core though. --[[Joey]] +>> I've implemented this with the data structure you suggested, except that +>> I called it `%typedlinks` instead of `%linktype` (it seemed to make more +>> sense that way). I also ported `tag` to it, and added a `tagged_is_strict` +>> config option. See below! --[[smcv]] + I saw somewhere else here some suggestions for the wiki-syntax for specifying the relation name of a link. One more suggestion---[the syntax used in Semantic MediaWiki](http://en.wikipedia.org/wiki/Semantic_MediaWiki#Basic_usage), like this:
@@ -45,3 +50,49 @@ I saw somewhere else here some suggestions for the wiki-syntax for specifying th
 So a part of the effect of [[`\[[!taglink TAG\]\]`|plugins/tag]] could be represented as something like `\[[tag::TAG]]` or (more understandable relation name in what concerns the direction) `\[[tagged::TAG]]`.
 
 I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
+
+-------
+
+>> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/link-types]]
+>> [[!tag patch]]
+
+## Documentation for smcv's branch
+
+### added to [[ikiwiki/pagespec]]
+
+* "`typedlink(type glob)`" - matches pages that link to a given page (or glob)
+  with a given link type. Plugins can create links with a specific type:
+  for instance, the tag plugin creates links of type `tag`.
+
+### added to [[plugins/tag]]
+
+If the `tagged_is_strict` config option is set, `tagged()` will only match
+tags explicitly set with [[ikiwiki/directive/tag]] or
+[[ikiwiki/directive/taglink]]; if not (the default), it will also match
+any other [[WikiLinks|ikiwiki/WikiLink]] to the tag page.
+
+### added to [[plugins/write]]
+
+#### `%typedlinks`
+
+The `%typedlinks` hash records links of specific types. Do not modify this
+hash directly; call `add_link()`. The keys are page names, and the values
+are hash references. In each page's hash reference, the keys are link types
+defined by plugins, and the values are hash references with link targets
+as keys, and 1 as a dummy value, something like this:
+
+	$typedlinks{"foo"} = {
+		tag => { short_word => 1, metasyntactic_variable => 1 },
+		next_page => { bar => 1 },
+	};
+
+Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
+`%typedlinks`.
+
+#### `add_link($$;$)`
+ 
+ This adds a link to `%links`, ensuring that duplicate links are not
+ added. Pass it the page that contains the link, and the link text.
+ 
+An optional third parameter sets the link type (`undef` produces an ordinary
+[[ikiwiki/WikiLink]]).
-- 
cgit v1.2.3


From 1c8ac7d88c5a3d2c63892737e54be8a1b535936c Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 16:41:04 -0400
Subject: review from the woods

---
 doc/todo/matching_different_kinds_of_links.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 0049281fe..20acdde49 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -96,3 +96,22 @@ Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
  
 An optional third parameter sets the link type (`undef` produces an ordinary
 [[ikiwiki/WikiLink]]).
+
+> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
+> 
+> I'm curious what your reasoning was for adding a new variable
+> rather than using `pagestate`. Was it only because you needed
+> the `old` version to detect change, or was there other complexity?
+> 
+> I have not convinced myself this is a real problem, but..
+> If a page has a typed link, there seems to be no way to tell
+> if it also has a separate, regular link. `add_link` will add
+> to `@links` when adding a typed, or untyped link. If only untyped
+> links were recorded there, one could tell the difference. But then
+> typed links would not show up at all in eg, a linkmap,
+> unless it was changed to check for typed links too.
+> (Or, regular links could be recorded in typedlinks too,
+> with a empty type. (Bloaty.))
+> 
+> I suspect we could get away without having `tagged_is_strict`
+> without too much transitional trouble. --[[Joey]]
-- 
cgit v1.2.3


From 59ba938822ba0752e8d97e769c0d14f2eb0bbeb3 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 16:54:06 -0400
Subject: template: Search for templates in the templatedir, if they are not
 found as pages in the wiki.

---
 IkiWiki/Plugin/template.pm                            | 10 ++++++++--
 debian/changelog                                      |  2 ++
 doc/templates.mdwn                                    |  6 ++++++
 doc/todo/user-defined_templates_outside_the_wiki.mdwn |  2 ++
 doc/wikitemplates.mdwn                                |  6 ++++--
 5 files changed, 22 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/template.pm b/IkiWiki/Plugin/template.pm
index 3e024c5f8..36282055a 100644
--- a/IkiWiki/Plugin/template.pm
+++ b/IkiWiki/Plugin/template.pm
@@ -37,7 +37,13 @@ sub preprocess (@) {
 	my $template_page="templates/$params{id}";
 	add_depends($params{page}, $template_page);
 
-	my $template_file=$pagesources{$template_page};
+	my $template_file;
+	if (exists $pagesources{$template_page}) {
+		$template_file=srcfile($pagesources{$template_page});
+	}
+	else {
+		$template_file=template_file("$params{id}.tmpl")
+	}
 	return sprintf(gettext("template %s not found"),
 		htmllink($params{page}, $params{destpage}, "/".$template_page))
 			unless defined $template_file;
@@ -50,7 +56,7 @@ sub preprocess (@) {
 	                        $$text_ref=&Encode::decode_utf8($$text_ref);
 				chomp $$text_ref;
 	                },
-	                filename => srcfile($template_file),
+	                filename => $template_file,
        			die_on_bad_params => 0,
 			no_includes => 1,
 			blind_cache => 1,
diff --git a/debian/changelog b/debian/changelog
index adf0dfed6..362ba54ab 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -26,6 +26,8 @@ ikiwiki (3.20100324) UNRELEASED; urgency=low
   * page.tmpl: Add Cache-Control must-revalidate to ensure that users
     (especially of Firefox) see fresh page content.
   * htmlscrubber: Allow colons in urls after '?'
+  * template: Search for templates in the templatedir, if they are not
+    found as pages in the wiki.
 
  -- Joey Hess   Sat, 13 Mar 2010 14:48:10 -0500
 
diff --git a/doc/templates.mdwn b/doc/templates.mdwn
index eff0e15e9..07531ae98 100644
--- a/doc/templates.mdwn
+++ b/doc/templates.mdwn
@@ -43,6 +43,12 @@ page will provide a link that can be used to create the template. The template
 is a regular wiki page, located in the `templates/` subdirectory inside
 the source directory of the wiki.
 
+(Alternatively, templates can be stored in a directory outside the wiki,
+as files with the extension ".tmpl".
+By default, these are searched for in `/usr/share/ikiwiki/templates`;
+the `templatedir` setting can be used to make another directory be searched
+first.)
+
 The template uses the syntax used by the [[!cpan HTML::Template]] perl
 module, which allows for some fairly complex things to be done. Consult its
 documentation for the full syntax, but all you really need to know are a
diff --git a/doc/todo/user-defined_templates_outside_the_wiki.mdwn b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
index 880ad6493..1d72aa6a7 100644
--- a/doc/todo/user-defined_templates_outside_the_wiki.mdwn
+++ b/doc/todo/user-defined_templates_outside_the_wiki.mdwn
@@ -6,3 +6,5 @@ source, but also looks in the system templates directory (the one with
 invoked via `\[[!template]]`, but don't have to "work" as wiki pages in their
 own right. I think the normal [[plugins/template]] plugin could benefit from
 this functionality.
+
+[[done]] --[[Joey]] 
diff --git a/doc/wikitemplates.mdwn b/doc/wikitemplates.mdwn
index 6c0480cea..6e5a7261d 100644
--- a/doc/wikitemplates.mdwn
+++ b/doc/wikitemplates.mdwn
@@ -5,7 +5,8 @@ to learn.
 The aim is to keep almost all html out of ikiwiki and in the templates.
 
 It ships with some basic templates which can be customised. These are
-located in /usr/share/ikiwiki/templates by default.
+located in `/usr/share/ikiwiki/templates` by default; the `templatedir`
+setting can be used to make another directory be searched first.
 
 * `page.tmpl` - Used for displaying all regular wiki pages.
 * `misc.tmpl` - Generic template used for any page that doesn't
@@ -43,7 +44,8 @@ The [[plugins/pagetemplate]] plugin can allow individual pages to use a
 different template than `page.tmpl`.
 
 The [[plugins/template]] plugin also uses templates, though those
-[[templates]] are stored in the wiki and inserted into pages.
+[[templates]] are typically stored as pages in the wiki, and are inserted
+into pages.
 
 The [[plugins/edittemplate]] plugin is used to make new pages default to
 containing text from a template, which can be filled as out the page is
-- 
cgit v1.2.3


From de62ea1cc8111dd96bc84b9c839be99c921168e3 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:03:33 -0400
Subject: fix branch name

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index f37a0758e..8edc95fb9 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -104,7 +104,7 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
-## Documentation from sort-hooks branch
+## Documentation from sort-package branch
 
 The changes to [[ikiwiki/pagespec/sorting]] are the same.
 The changes to [[plugins/write]] are replaced by:
-- 
cgit v1.2.3


From 1b0d4e8d885ded59ca0ad1b4d1ca1315585cce06 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:16:12 -0400
Subject: minor comment

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 8edc95fb9..e4e1829dc 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -89,6 +89,9 @@ and to sort by an arbitrary `meta` value, you could use:
   or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
   full title was set.
 
+  > I feel it sould be clearer to call that "sortas", since "sort=" is used
+  > to specify a sort method in other directives. --[[Joey]]
+
 ### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
 
 In addition, you can combine several sort orders and/or reverse the order of
-- 
cgit v1.2.3


From 9e7dcefd7ed9424de20706f63c7bab5182c5df78 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:26:32 -0400
Subject: comments

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e4e1829dc..67d85f6f8 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -50,6 +50,21 @@ NIH'd sorting mechanisms:
 >>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
 >>> 
 
+>>>> I agree it seems more elegant, so I have focused on it.
+>>>>
+>>>> I don't know about reusing `IkiWiki::PageSpec` for this.
+>>>>
+>>>> I would be inclined to drop the `check_` stuff.
+>>>>
+>>>> Wouldn't it make sense to have `meta(title)` instead
+>>>> of `meta_title`?
+>>>>
+>>>> As I read the regexp in `cmpspec_translate`, the "command"
+>>>> is required to have params. They should be optional, 
+>>>> to match the documentation and because most sort methods
+>>>> do not need parameters.
+>>>> --[[Joey]]
+
 ## Documentation from sort-hooks branch
 
 ### sort hook (added to [[plugins/write]])
-- 
cgit v1.2.3


From 1faf9b08e16bde9b4b0d72620fcef79c715e64de Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 17:37:38 -0400
Subject: idea

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 67d85f6f8..e1e05e81c 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -63,6 +63,14 @@ NIH'd sorting mechanisms:
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
 >>>> do not need parameters.
+>>>>
+>>>> I wonder if it would make sense to add some combining keywords, so
+>>>> a sortspec reads like `sort="age then ascending title"`
+>>>> In a way, this reduces the amount of syntax that needs to be learned.
+>>>> I like the "then" (and it could allow other operations than
+>>>> simple combination, if any others make sense). Not so sure about the
+>>>> "ascending", which could be "reverse" instead, but "descending age" and
+>>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
 ## Documentation from sort-hooks branch
-- 
cgit v1.2.3


From 2c7fe7ae2cf73141eba817d4275d9a6a897df8a8 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Fri, 2 Apr 2010 22:25:16 +0000
Subject: respond (also unindent Joey's review to avoid very deep indentation)

---
 doc/todo/matching_different_kinds_of_links.mdwn | 61 +++++++++++++++++--------
 1 file changed, 43 insertions(+), 18 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 20acdde49..f8796652e 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -97,21 +97,46 @@ Ordinary [[WikiLinks|ikiwiki/WikiLink]] appear in `%links`, but not in
 An optional third parameter sets the link type (`undef` produces an ordinary
 [[ikiwiki/WikiLink]]).
 
-> Some code refers to `oldtypedlinks`, and other to `oldlinktypes`.
-> 
-> I'm curious what your reasoning was for adding a new variable
-> rather than using `pagestate`. Was it only because you needed
-> the `old` version to detect change, or was there other complexity?
-> 
-> I have not convinced myself this is a real problem, but..
-> If a page has a typed link, there seems to be no way to tell
-> if it also has a separate, regular link. `add_link` will add
-> to `@links` when adding a typed, or untyped link. If only untyped
-> links were recorded there, one could tell the difference. But then
-> typed links would not show up at all in eg, a linkmap,
-> unless it was changed to check for typed links too.
-> (Or, regular links could be recorded in typedlinks too,
-> with a empty type. (Bloaty.))
-> 
-> I suspect we could get away without having `tagged_is_strict`
-> without too much transitional trouble. --[[Joey]]
+## Review
+
+Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
+
+> Oops, I'll fix that. That must mean missing test coverage, too :-(
+> --s
+
+I'm curious what your reasoning was for adding a new variable
+rather than using `pagestate`. Was it only because you needed
+the `old` version to detect change, or was there other complexity?
+--J
+
+> You seemed to be more in favour of adding it to the core in
+> your proposal above, so I assumed that'd be more likely to be
+> accepted :-) I don't mind one way or the other - `%typedlinks`
+> costs one core variable, but saves one level of hash nesting. If
+> you're not sure either, then I think the decision should come down
+> to which one is easier to document clearly - I'm still unhappy with
+> my docs for `%typedlinks`, so I'll try to write docs for it as
+> `pagestate` and see if they work any better. --s
+
+I have not convinced myself this is a real problem, but..
+If a page has a typed link, there seems to be no way to tell
+if it also has a separate, regular link. `add_link` will add
+to `@links` when adding a typed, or untyped link. If only untyped
+links were recorded there, one could tell the difference. But then
+typed links would not show up at all in eg, a linkmap,
+unless it was changed to check for typed links too.
+(Or, regular links could be recorded in typedlinks too,
+with a empty type. (Bloaty.)) --J
+
+> I think I like the semantics as-is - I can't think of any
+> reason why you'd want to ask the question "does A link to B,
+> not counting tags and other typed links?". A typed link is
+> still a link, in my mind at least. --s
+
+I suspect we could get away without having `tagged_is_strict`
+without too much transitional trouble. --[[Joey]]
+
+> If you think so, I can delete about 5 LoC. I don't particularly
+> care either way; [[Jon]] expressed concern about people relying
+> on the current semantics, on one of the pages requesting this
+> change. --s
-- 
cgit v1.2.3


From 011fe920d162924876170d167be11dc64cf8be2f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:00:53 +0000
Subject: respond at some length

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 163 ++++++++++++---------
 1 file changed, 94 insertions(+), 69 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e1e05e81c..156678da7 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -1,4 +1,3 @@
-[[!template id=gitbranch branch=smcv/sort-hooks author="[[Simon_McVittie|smcv]]"]]
 [[!tag patch]]
 
 The available [[ikiwiki/pagespec/sorting]] methods are currently hard-coded in
@@ -11,36 +10,13 @@ title over the page name, but for compatibility, I'm not going to (I do wonder
 whether it would be worth making sort=name an alias for the current sort=title,
 and changing the meaning of sort=title in 4.0, though).
 
-Gitweb:
-
+*[sort-hooks branch now withdrawn in favour of sort-package --s]*
 
 I briefly tried to turn *all* the current sort types into hook functions, and
 have some of them pre-registered, but decided that probably wasn't a good idea.
 That earlier version of the branch is also available for comparison:
 
-
-
-(The older version is untested, and probably doesn't really work as-is - I
-misunderstood the details of how the built-in function `sort` works when using
-`$a` and `$b`. The newer version has been tested, and has a regression test for
-its core functionality.)
-
-This hook *isn't* (yet) sufficient to implement [[plugins/contrib/report]]'s
-NIH'd sorting mechanisms:
-
-* `report` can sort by any [[plugins/contrib/field]], whereas this one has a
-  finite number of hooks: if the `field` plugin's functionality is desirable,
-  perhaps parameterized sort mechanisms similar to pagespec match functions
-  would be useful? Then the `field` plugin could register
-  `hook(type => "sort", id => "field")` and you could have
-  `\[[!inline ... sort="field(Mood)"]]` or something?
-
-* `report` can sort by multiple criteria, with independent direction-changing:
-  if this is desirable, perhaps `pagespec_match_list` could be enhanced to
-  interpret `sort="x -y z(w)"` as sorting by (pseudocode)
-  `{ $cmp_x->($a, $b) || (-$cmp_y->($a, $b)) || $cmp_z->($a, $b, "w") }`?
-
-> I've now added both of these features to the sort-hooks branch. --[[smcv]]
+*[also withdrawn in favour of sort-package --s]*
 
 >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
 
@@ -53,17 +29,65 @@ NIH'd sorting mechanisms:
 >>>> I agree it seems more elegant, so I have focused on it.
 >>>>
 >>>> I don't know about reusing `IkiWiki::PageSpec` for this.
->>>>
+>>>> --[[Joey]]
+
+>>>>> Fair enough, `IkiWiki::SortSpec::cmp_foo` would be just
+>>>>> as easy, or `IkiWiki::Sorting::cmp_foo` if you don't like
+>>>>> introducing "sort spec" in the API. I took a cue from
+>>>>> [[ikiwiki/pagespec/sorting]] being a subpage of
+>>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
+>>>>> a bit like a pagespec :-) --s
+
 >>>> I would be inclined to drop the `check_` stuff.
->>>>
+
+>>>>> It basically exists to support `title_natural`, to avoid
+>>>>> firing up the whole import mechanism on every `cmp`
+>>>>> (although I suppose that could just be a call to a
+>>>>> memoized helper function). It also lets sort specs that
+>>>>> *must* have a parameter, like
+>>>>> [[field|plugins/contrib/field/discussion]], fail early
+>>>>> (again, not so valuable).
+>>>>>
+>>>>> The former function could be achieved at a small
+>>>>> compatibility cost by putting `title_natural` in a new
+>>>>> sortnatural plugin (that fails to load if you don't
+>>>>> have `title_natural`), if you'd prefer - that's what would
+>>>>> have happened if `title_natural` was written after this
+>>>>> code had been merged, I suspect. --s
+
 >>>> Wouldn't it make sense to have `meta(title)` instead
->>>> of `meta_title`?
->>>>
+>>>> of `meta_title`? --J
+
+>>>>> Yes, you're right. I added parameters to support `field`,
+>>>>> and didn't think about making `meta` use them too.
+>>>>> However, `title` does need a special case to make it
+>>>>> default to the basename instead of the empty string.
+>>>>>
+>>>>> Another special case for `title` is to use `titlesort`
+>>>>> first (the name `titlesort` is derived from Ogg/FLAC
+>>>>> tags, which can have `titlesort` and `artistsort`).
+>>>>> I could easily extend that to other metas, though;
+>>>>> in fact, for e.g. book lists it would be nice for
+>>>>> `field(bookauthor)` to behave similarly, so you can
+>>>>> display "Douglas Adams" but sort by "Adams, Douglas".
+>>>>>
+>>>>> `meta_title` is also meant to be a prototype of how
+>>>>> `sort=title` could behave in 4.0 or something - sorting
+>>>>> by page name (which usually sorts in approximately the
+>>>>> same place as the meta-title, but occasionally not), while
+>>>>> displaying meta-titles, does look quite odd. --s
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
->>>> do not need parameters.
->>>>
+>>>> do not need parameters. --J
+
+>>>>> No, `$2` is either `\w+\([^\)]*\)` or `[^\s]+` (with the
+>>>>> latter causing an error later if it doesn't also match `\w+`).
+>>>>> This branch doesn't add any parameterized sort methods,
+>>>>> in fact, although I did provide one on
+>>>>> [[field's_discussion_page|plugins/contrib/report/discussion]]. --s
+
 >>>> I wonder if it would make sense to add some combining keywords, so
 >>>> a sortspec reads like `sort="age then ascending title"`
 >>>> In a way, this reduces the amount of syntax that needs to be learned.
@@ -73,38 +97,42 @@ NIH'd sorting mechanisms:
 >>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
-## Documentation from sort-hooks branch
-
-### sort hook (added to [[plugins/write]])
-
-       hook(type => "sort", id => "foo", call => \&sort_by_foo);
-
-This hook adds an additional [[ikiwiki/pagespec/sorting]] order or overrides
-an existing one.
-
-The callback is given two page names followed by the parameter as arguments, and
-returns negative, zero or positive if the first page should come before,
-close to (i.e. undefined order), or after the second page.
-
-For instance, the built-in `title` sort order could be reimplemented as
-
-       sub sort_by_title {
-               pagetitle(basename($_[0])) cmp pagetitle(basename($_[1]));
-       }
-
-and to sort by an arbitrary `meta` value, you could use:
-
-       # usage: sort="meta(description)"
-       sub sort_by_meta {
-               my $param = $_[2];
-               error "sort=meta requires a parameter" unless defined $param;
-               my $left = $pagestate{$_[0]}{meta}{$param};
-               $left = "" unless defined $left;
-               my $right = $pagestate{$_[1]}{meta}{$param};
-               $right = "" unless defined $right;
-               return $left cmp $right;
-       }
+>>>>> Perhaps. I do like the simplicity of [[KathyrnAndersen]]'s syntax
+>>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
+>>>>> turning sort-by-`field` into a parameterized spec), and I can't really
+>>>>> think of any sensible way to combine sort specs other than "sort by a,
+>>>>> break ties by b, ...", possibly with some reversals thrown in.
+>>>>>
+>>>>> If no other combinations do make sense, is your proposal that "then"
+>>>>> is entirely redundant (easy, just make it a predefined sort spec that
+>>>>> returns 0!), or that it's mandatory "punctuation" (add an explicit
+>>>>> check, or make "then" expand to "||" and let Perl fail to compile
+>>>>> the generated code if it's omitted)?
+>>>>>
+>>>>> It is a little unfortunate that reversal has to move into the sort
+>>>>> spec - I prefer `reverse=yes` - but that's necessary for multi-level
+>>>>> sorting. I can see your point about ascending/descending being more
+>>>>> obvious to look at, but they're also considerably more verbose.
+>>>>>
+>>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
+>>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
+>>>>> now minus `ctime`). `sort=freshness` isn't right either, because
+>>>>> "sort by freshness" seems as though it ought to mean freshest first,
+>>>>> but "sort by ascending freshness" means put the least fresh first. If
+>>>>> we have ascending and descending keywords which are optional, I don't
+>>>>> think we really want different sort types to have different default
+>>>>> directions - it seems clearer to have `ascending` always be a no-op,
+>>>>> and `descending` always negate.
+>>>>>
+>>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
+>>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
+>>>>> makes me think that updateage is a quantity analagous to tonnage or
+>>>>> voltage, with more or less recently updated pages being said to have
+>>>>> more or less updateage. I don't know whether that's good or bad :-)
+>>>>>
+>>>>> I'm sure there's a much better word, but I can't see it. --s
 
+## Documentation from sort-package branch
 
 ### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
 
@@ -115,6 +143,8 @@ and to sort by an arbitrary `meta` value, you could use:
   > I feel it sould be clearer to call that "sortas", since "sort=" is used
   > to specify a sort method in other directives. --[[Joey]]
 
+  >> Fair enough, that's easy to do. --[[smcv]]
+
 ### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
 
 In addition, you can combine several sort orders and/or reverse the order of
@@ -130,12 +160,7 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
-## Documentation from sort-package branch
-
-The changes to [[ikiwiki/pagespec/sorting]] are the same.
-The changes to [[plugins/write]] are replaced by:
-
-### Sorting plugins
+### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as
 [[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to
-- 
cgit v1.2.3


From aec7dec2795aedfe1f13cff9a888bed83ee760df Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:12:59 +0000
Subject: make questions to Joey more explicit

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 156678da7..36c134a59 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -36,9 +36,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> introducing "sort spec" in the API. I took a cue from
 >>>>> [[ikiwiki/pagespec/sorting]] being a subpage of
 >>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
->>>>> a bit like a pagespec :-) --s
+>>>>> a bit like a pagespec :-) Which name would you prefer? --s
 
->>>> I would be inclined to drop the `check_` stuff.
+>>>> I would be inclined to drop the `check_` stuff. --J
 
 >>>>> It basically exists to support `title_natural`, to avoid
 >>>>> firing up the whole import mechanism on every `cmp`
@@ -50,10 +50,10 @@ That earlier version of the branch is also available for comparison:
 >>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
->>>>> sortnatural plugin (that fails to load if you don't
+>>>>> `sortnatural` plugin (that fails to load if you don't
 >>>>> have `title_natural`), if you'd prefer - that's what would
 >>>>> have happened if `title_natural` was written after this
->>>>> code had been merged, I suspect. --s
+>>>>> code had been merged, I suspect. Would you prefer this? --s
 
 >>>> Wouldn't it make sense to have `meta(title)` instead
 >>>> of `meta_title`? --J
@@ -97,7 +97,7 @@ That earlier version of the branch is also available for comparison:
 >>>> "ascending age" both seem useful to be able to explicitly specify.
 >>>> --[[Joey]]
 
->>>>> Perhaps. I do like the simplicity of [[KathyrnAndersen]]'s syntax
+>>>>> Perhaps. I do like the simplicity of [[KathrynAndersen]]'s syntax
 >>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
 >>>>> turning sort-by-`field` into a parameterized spec), and I can't really
 >>>>> think of any sensible way to combine sort specs other than "sort by a,
@@ -130,7 +130,8 @@ That earlier version of the branch is also available for comparison:
 >>>>> voltage, with more or less recently updated pages being said to have
 >>>>> more or less updateage. I don't know whether that's good or bad :-)
 >>>>>
->>>>> I'm sure there's a much better word, but I can't see it. --s
+>>>>> I'm sure there's a much better word, but I can't see it. Do you have
+>>>>> a better idea? --s
 
 ## Documentation from sort-package branch
 
-- 
cgit v1.2.3


From 5f87d5d242b87ce5cfbd7ac5fcb1efcc62fc5582 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:25:28 +0000
Subject: actually I can see a second use for "nonlinear" syntax - but I don't
 think it's worth it

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 32 ++++++++++++++--------
 1 file changed, 20 insertions(+), 12 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 36c134a59..1657ca8e9 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -99,20 +99,28 @@ That earlier version of the branch is also available for comparison:
 
 >>>>> Perhaps. I do like the simplicity of [[KathrynAndersen]]'s syntax
 >>>>> from [[plugins/contrib/report]] (which I copied verbatim, except for
->>>>> turning sort-by-`field` into a parameterized spec), and I can't really
->>>>> think of any sensible way to combine sort specs other than "sort by a,
->>>>> break ties by b, ...", possibly with some reversals thrown in.
+>>>>> turning sort-by-`field` into a parameterized spec).
 >>>>>
->>>>> If no other combinations do make sense, is your proposal that "then"
->>>>> is entirely redundant (easy, just make it a predefined sort spec that
->>>>> returns 0!), or that it's mandatory "punctuation" (add an explicit
->>>>> check, or make "then" expand to "||" and let Perl fail to compile
->>>>> the generated code if it's omitted)?
+>>>>> If we're getting into English-like (or at least SQL-like) queries,
+>>>>> it might make sense to change the signature of the hook function
+>>>>> so it's a function to return a key, e.g.
+>>>>> `sub key_age { return -%pagemtime{$_[0]) }`. Then we could sort like
+>>>>> this:
 >>>>>
->>>>> It is a little unfortunate that reversal has to move into the sort
->>>>> spec - I prefer `reverse=yes` - but that's necessary for multi-level
->>>>> sorting. I can see your point about ascending/descending being more
->>>>> obvious to look at, but they're also considerably more verbose.
+>>>>>     field(artistsort) or field(artist) or constant(Various Artists) then meta(titlesort) or meta(title) or title
+>>>>>
+>>>>> with "or" binding more closely than "then". Does this seem valuable?
+>>>>> I think the implementation would be somewhat more difficult. and
+>>>>> it's probably getting too complicated to be worthwhile, though?
+>>>>> (The keys that actually benefit from this could just
+>>>>> have smarter cmp functions, I think.)
+>>>>>
+>>>>> If the hooks return keys rather than cmp results, then we could even
+>>>>> have "lowercase" as an adjective used like "ascending"... maybe.
+>>>>> However, there are two types of adjective here: "lowercase"
+>>>>> really applies to the keys, whereas "ascending" applies to the "cmp"
+>>>>> result. Again, I think this is getting too complex, and could just
+>>>>> be solved with smarter cmp functions.
 >>>>>
 >>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
 >>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
-- 
cgit v1.2.3


From c2f54ccfb7b401b59f7eda13095e2ba2af69ed7a Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:41:31 +0000
Subject: sort-order could usefully be overridden for meta author, too

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 1657ca8e9..e79e52f39 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -169,6 +169,9 @@ An optional `sort` parameter will be used preferentially when
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
+> I now realise that `author` should also have this, again for use
+> with (Western) names. --s
+
 ### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as
-- 
cgit v1.2.3


From c4a838b33a34ff61a1dd5c6f65e40df3609e727f Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 00:53:59 +0000
Subject: perhaps the typedlink(tag foo) pagespec isn't so useful

---
 doc/todo/matching_different_kinds_of_links.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index f8796652e..4f52ade52 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -140,3 +140,12 @@ without too much transitional trouble. --[[Joey]]
 > care either way; [[Jon]] expressed concern about people relying
 > on the current semantics, on one of the pages requesting this
 > change. --s
+
+I might have been wrong to introduce `typedlink(tag foo)`. It's not
+very user-friendly, and is more useful as a backend for other plugins
+that as a feature in its own right - any plugin introducing a link
+type will probably also want to have its own preprocessor directive
+to set that link type, and its own pagespec function to match it.
+I wonder whether to make a `typedlink` plugin that has the typedlink
+pagespec match function and a new `\[[!typedlink to="foo" type="bar"]]`
+though... --[[smcv]]
-- 
cgit v1.2.3


From 3934759592c35ab475e06501e2e4613d5c1f2e08 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 01:13:08 +0000
Subject: vague musings about wikilinks

---
 .../link_plugin_perhaps_too_general__63__.mdwn     | 25 ++++++++++++++++++++++
 1 file changed, 25 insertions(+)
 create mode 100644 doc/todo/link_plugin_perhaps_too_general__63__.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/link_plugin_perhaps_too_general__63__.mdwn b/doc/todo/link_plugin_perhaps_too_general__63__.mdwn
new file mode 100644
index 000000000..8a5fd50eb
--- /dev/null
+++ b/doc/todo/link_plugin_perhaps_too_general__63__.mdwn
@@ -0,0 +1,25 @@
+[[!tag wishlist blue-sky]]
+(This isn't important to me - I don't use MediaWiki or Creole syntax myself -
+but just thinking out loud...)
+
+The [[ikiwiki/wikilink]] syntax IkiWiki uses sometimes conflicts with page
+languages' syntax (notably, [[plugins/contrib/MediaWiki]] and [[plugins/Creole]]
+want their wikilinks the other way round, like
+`\[[plugins/write|how to write a plugin]]`). It would be nice if there was
+some way for page language plugins to opt in/out of the normal wiki link
+processing - then MediaWiki and Creole could have their own `linkify` hook
+that was only active for *their* page types, and used the appropriate
+syntax.
+
+In [[todo/matching_different_kinds_of_links]] I wondered about adding a
+`\[[!typedlink to="foo" type="bar"]]` directive. This made me wonder whether
+a core `\[[!link]]` directive would be useful; this could be a fallback for
+page types where a normal wikilink can't be done for whatever reason, and
+could also provide extension points more easily than WikiLinks' special
+syntax with extra punctuation, which doesn't really scale?
+
+Straw-man:
+
+    \[[!link to="ikiwiki/wikilink" desc="WikiLinks"]]
+
+--[[smcv]]
-- 
cgit v1.2.3


From 5445fe765777dc6254c7e0e13d4fa5e07810751a Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 01:15:28 +0000
Subject: cross-reference

---
 doc/todo/rewrite_ikiwiki_in_haskell.mdwn | 1 +
 1 file changed, 1 insertion(+)

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
index 204c48cd7..48ed744b1 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
@@ -29,6 +29,7 @@ It's appealing for a lot of reasons, including:
     edit in html editors currently.
   - This would be a chance to make WikiLinks with link texts read
     "the right way round" (ie, vaguely wiki creole compatably).
+    *[See also [[todo/link_plugin_perhaps_too_general?]] --[[smcv]]]*
   - The data structures would probably be quite different.
   - I might want to drop a lot of the command-line flags, either
     requiring a setup file be used for those things, or leaving the
-- 
cgit v1.2.3


From e4e53d7a18ec18d1ba72b1a4f124e211148e0f12 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 22:23:36 -0400
Subject: response

---
 doc/todo/matching_different_kinds_of_links.mdwn | 7 +++++++
 1 file changed, 7 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 4f52ade52..2cd484852 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -104,6 +104,8 @@ Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
 > Oops, I'll fix that. That must mean missing test coverage, too :-(
 > --s
 
+>> A test suite for the dependency resolver *would* be nice. --[[Joey]]
+
 I'm curious what your reasoning was for adding a new variable
 rather than using `pagestate`. Was it only because you needed
 the `old` version to detect change, or was there other complexity?
@@ -133,6 +135,8 @@ with a empty type. (Bloaty.)) --J
 > not counting tags and other typed links?". A typed link is
 > still a link, in my mind at least. --s
 
+>> Me neither, let's not worry about it. --[[Joey]] 
+
 I suspect we could get away without having `tagged_is_strict`
 without too much transitional trouble. --[[Joey]]
 
@@ -149,3 +153,6 @@ to set that link type, and its own pagespec function to match it.
 I wonder whether to make a `typedlink` plugin that has the typedlink
 pagespec match function and a new `\[[!typedlink to="foo" type="bar"]]`
 though... --[[smcv]]
+
+> I agree, per-type matchers are more friendly and I'm not enamored of the
+> multi-parameter pagespec syntax. --[[Joey]]
-- 
cgit v1.2.3


From 931c7b00ccb47371ee6e1d56baf5c52d725a321f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 2 Apr 2010 22:46:31 -0400
Subject: response

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 25 +++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index e79e52f39..c6e18505e 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -38,7 +38,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> [[ikiwiki/pagespec]], and decided that yes, sorting is
 >>>>> a bit like a pagespec :-) Which name would you prefer? --s
 
->>>> I would be inclined to drop the `check_` stuff. --J
+>>>>>> `SortSpec` --[[Joey]] 
+
+>>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
 >>>>> It basically exists to support `title_natural`, to avoid
 >>>>> firing up the whole import mechanism on every `cmp`
@@ -48,6 +50,11 @@ That earlier version of the branch is also available for comparison:
 >>>>> [[field|plugins/contrib/field/discussion]], fail early
 >>>>> (again, not so valuable).
 >>>>>
+>>>>>> AFAIK, `use foo` has very low overhead when the module is already
+>>>>>> loaded. There could be some evalation overhead in `eval q{use foo}`,
+>>>>>> if so it would be worth addressing across the whole codebase.
+>>>>>> --[[Joey]] 
+>>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
 >>>>> `sortnatural` plugin (that fails to load if you don't
@@ -55,8 +62,12 @@ That earlier version of the branch is also available for comparison:
 >>>>> have happened if `title_natural` was written after this
 >>>>> code had been merged, I suspect. Would you prefer this? --s
 
+>>>>>> Yes! (Assuming it does not make sense to support
+>>>>>> natural order sort of other keys than the title, at least..)
+>>>>>>  --[[Joey]]
+
 >>>> Wouldn't it make sense to have `meta(title)` instead
->>>> of `meta_title`? --J
+>>>> of `meta_title`? --[[Joey]]
 
 >>>>> Yes, you're right. I added parameters to support `field`,
 >>>>> and didn't think about making `meta` use them too.
@@ -77,10 +88,12 @@ That earlier version of the branch is also available for comparison:
 >>>>> same place as the meta-title, but occasionally not), while
 >>>>> displaying meta-titles, does look quite odd. --s
 
+>>>>>> Agreed. --[[Joey]]
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
->>>> do not need parameters. --J
+>>>> do not need parameters. --[[Joey]]
 
 >>>>> No, `$2` is either `\w+\([^\)]*\)` or `[^\s]+` (with the
 >>>>> latter causing an error later if it doesn't also match `\w+`).
@@ -122,6 +135,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> result. Again, I think this is getting too complex, and could just
 >>>>> be solved with smarter cmp functions.
 >>>>>
+>>>>>> I agree. (Also, I think returning keys may make it harder to write
+>>>>>> smarter cmp functions.) --[[Joey]] 
+>>>>>
 >>>>> Unfortunately, `sort="ascending mtime"` actually sorts by *descending*
 >>>>> timestamp (but`sort=age` is fine, because `age` could be defined as
 >>>>> now minus `ctime`). `sort=freshness` isn't right either, because
@@ -132,6 +148,9 @@ That earlier version of the branch is also available for comparison:
 >>>>> directions - it seems clearer to have `ascending` always be a no-op,
 >>>>> and `descending` always negate.
 >>>>>
+>>>>>> I think you've convinced me that ascending/descending impose too
+>>>>>> much semantics on it, so "-" is better. --[[Joey]]
+>>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
 >>>>> makes me think that updateage is a quantity analagous to tonnage or
-- 
cgit v1.2.3


From 56c64ff1963b33da74677f08a0b8c6579bc2d68b Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sat, 3 Apr 2010 13:39:44 +0000
Subject: updated branch

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 56 +++++++++++++++-------
 1 file changed, 38 insertions(+), 18 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index c6e18505e..8c6e1df3b 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -40,6 +40,8 @@ That earlier version of the branch is also available for comparison:
 
 >>>>>> `SortSpec` --[[Joey]] 
 
+>>>>>>> Done. --s
+
 >>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
 >>>>> It basically exists to support `title_natural`, to avoid
@@ -54,6 +56,8 @@ That earlier version of the branch is also available for comparison:
 >>>>>> loaded. There could be some evalation overhead in `eval q{use foo}`,
 >>>>>> if so it would be worth addressing across the whole codebase.
 >>>>>> --[[Joey]] 
+>>>>>>
+>>>>>>> check_cmp_foo now dropped. --s
 >>>>>
 >>>>> The former function could be achieved at a small
 >>>>> compatibility cost by putting `title_natural` in a new
@@ -66,6 +70,8 @@ That earlier version of the branch is also available for comparison:
 >>>>>> natural order sort of other keys than the title, at least..)
 >>>>>>  --[[Joey]]
 
+>>>>>>> Done. I added some NEWS.Debian for it, too. --s
+
 >>>> Wouldn't it make sense to have `meta(title)` instead
 >>>> of `meta_title`? --[[Joey]]
 
@@ -90,6 +96,11 @@ That earlier version of the branch is also available for comparison:
 
 >>>>>> Agreed. --[[Joey]]
 
+>>>>>>> I've implemented meta(title). meta(author) also has the
+>>>>>>> `sortas` special case; meta(updated) and meta(date)
+>>>>>>> should also work how you'd expect them to (but they're
+>>>>>>> earliest-first, unlike age). --s
+
 >>>> As I read the regexp in `cmpspec_translate`, the "command"
 >>>> is required to have params. They should be optional, 
 >>>> to match the documentation and because most sort methods
@@ -150,6 +161,10 @@ That earlier version of the branch is also available for comparison:
 >>>>>
 >>>>>> I think you've convinced me that ascending/descending impose too
 >>>>>> much semantics on it, so "-" is better. --[[Joey]]
+
+>>>>>>> I've kept the semantics from `report` as-is, then:
+>>>>>>> e.g. `sort="age -title"`. --s
+
 >>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
@@ -160,18 +175,22 @@ That earlier version of the branch is also available for comparison:
 >>>>> I'm sure there's a much better word, but I can't see it. Do you have
 >>>>> a better idea? --s
 
-## Documentation from sort-package branch
+[Regarding the `meta title=foo sort=bar` special case]
 
-### meta_title sort order (conditionally added to [[ikiwiki/pagespec/sorting]])
+> I feel it sould be clearer to call that "sortas", since "sort=" is used
+> to specify a sort method in other directives. --[[Joey]]
+>> Done. --[[smcv]]
 
-* `meta_title` - Order according to the `\[[!meta title="foo" sort="bar"]]`
-  or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
-  full title was set.
+## Documentation from sort-package branch
 
-  > I feel it sould be clearer to call that "sortas", since "sort=" is used
-  > to specify a sort method in other directives. --[[Joey]]
+### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
 
-  >> Fair enough, that's easy to do. --[[smcv]]
+* `title_natural` - Orders by title, but numbers in the title are treated
+  as such, ("1 2 9 10 20" instead of "1 10 2 20 9")
+* `meta(title)` - Order according to the `\[[!meta title="foo" sortas="bar"]]`
+  or `\[[!meta title="foo"]]` [[ikiwiki/directive]], or the page name if no
+  full title was set. `meta(author)`, `meta(date)`, `meta(updated)`, etc.
+  also work.
 
 ### Multiple sort orders (added to [[ikiwiki/pagespec/sorting]])
 
@@ -179,23 +198,29 @@ In addition, you can combine several sort orders and/or reverse the order of
 sorting, with a string like `age -title` (which would sort by age, then by
 title in reverse order if two pages have the same age).
 
-### meta title sort parameter (added to [[ikiwiki/directive/meta]])
+### meta sortas parameter (added to [[ikiwiki/directive/meta]])
+
+[in title]
 
 An optional `sort` parameter will be used preferentially when
-[[ikiwiki/pagespec/sorting]] by `meta_title`:
+[[ikiwiki/pagespec/sorting]] by `meta(title)`:
 
        \[[!meta title="The Beatles" sort="Beatles, The"]]
 
        \[[!meta title="David Bowie" sort="Bowie, David"]]
 
-> I now realise that `author` should also have this, again for use
-> with (Western) names. --s
+[in author]
+
+  An optional `sortas` parameter will be used preferentially when
+  [[ikiwiki/pagespec/sorting]] by `meta(author)`:
+
+        \[[!meta author="Joey Hess" sortas="Hess, Joey"]]
 
 ### Sorting plugins (added to [[plugins/write]])
 
 Similarly, it's possible to write plugins that add new functions as
 [[ikiwiki/pagespec/sorting]] methods. To achieve this, add a function to
-the IkiWiki::PageSpec package named `cmp_foo`, which will be used when sorting
+the IkiWiki::SortSpec package named `cmp_foo`, which will be used when sorting
 by `foo` or `foo(...)` is requested.
 
 The function will be passed three or more parameters. The first two are
@@ -208,8 +233,3 @@ if the first argument is less than the second, positive if the first argument
 is greater, or zero if they are considered equal. It may also raise an
 error using `error`, for instance if it needs a parameter but one isn't
 provided.
-
-You can also define a function called `check_cmp_foo` in the same package.
-If you do, it will be called while preparing to sort by `foo` or `foo(bar)`,
-with argument `undef` or `"bar"` respectively; it may raise an error using
-`error`, if sorting like that isn't going to work.
-- 
cgit v1.2.3


From 36202d461f86bb3869444cf161d9bfe62298b8f8 Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 5 Feb 2010 12:54:07 +0100
Subject: link to commits

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index a0e76fd48..c4a92824b 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -165,7 +165,7 @@ wrong direction.
 > optimised, and security-sensitive ground, so I have to look at them very
 > carefully. --[[Joey]]
 > 
-> * In the refactoring in f3abeac919c4736429bd3362af6edf51ede8e7fe,
+> * In the refactoring in [f3abeac919c4736429bd3362af6edf51ede8e7fe][],
 >   you introduced at least 2 bugs, one a possible security hole.
 >   Now one part of the code tests `if ($file)` and the other
 >   caller tests `if ($f)`. These two tests both tested `if (! defined $f)`
@@ -181,14 +181,18 @@ wrong direction.
 > I'd like to cherry-pick the above commit, once it's in shape, before
 > looking at the rest in detail. So just a few other things that stood out.
 > 
-> * Commit 4af4d26582f0c2b915d7102fb4a604b176385748 seems unnecessary.
+> * Commit [4af4d26582f0c2b915d7102fb4a604b176385748][] seems unnecessary.
 >   `srcfile($file, 1)` already is documented to return undef if the
 >   file does not exist. (But without the second parameter, it throws
 >   an error.)
 >
-> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 adds a line
+> * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] adds a line
 >   that is intented by a space, not a tab.
 > 
-> * Commit f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 says that auto-added
+> * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] says that auto-added
 >   files will be recreated if the user deletes them. That seems bad.
 >   `autoindex` goes to some trouble to not recreate deleted files.
+
+[f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
+[4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
+[f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From 129bea3177b59be8ed4cc303720c8747f59a11ba Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Sat, 3 Apr 2010 23:38:05 +0200
Subject: answer about autofiles for tags

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 29 +++++++++++++++++++---
 1 file changed, 25 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index c4a92824b..07b570b1b 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -164,7 +164,11 @@ wrong direction.
 > Starting review of this. Some of your commits are to very delicate,
 > optimised, and security-sensitive ground, so I have to look at them very
 > carefully. --[[Joey]]
-> 
+
+>> First of, sorry that it took me so damn long to answer. I didn't lose
+>> interest but it took a while for me to find the time and motivation
+>> to address you suggestions. --[[David_Riebenbauer]]
+
 > * In the refactoring in [f3abeac919c4736429bd3362af6edf51ede8e7fe][],
 >   you introduced at least 2 bugs, one a possible security hole.
 >   Now one part of the code tests `if ($file)` and the other
@@ -177,7 +181,11 @@ wrong direction.
 >   bare `_` in the first to make perl reuse the stat buffer.
 > * (As a matter of style, could you put a space after the commas in your
 >   perl?)
-> 
+
+>> The first two points should be addressed in
+>> [da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0][]. And sure, I can add the
+>> spaces. --[[David_Riebenbauer]]
+
 > I'd like to cherry-pick the above commit, once it's in shape, before
 > looking at the rest in detail. So just a few other things that stood out.
 > 
@@ -185,14 +193,27 @@ wrong direction.
 >   `srcfile($file, 1)` already is documented to return undef if the
 >   file does not exist. (But without the second parameter, it throws
 >   an error.)
->
+
+>> You're right. I must have been some confused by some other promplem I
+>> introduced then. Reverted. --[[David_Riebenbauer]]
+
 > * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] adds a line
 >   that is intented by a space, not a tab.
-> 
+
+>> Sorry, That one was reverted anyway. --[[David_Riebenbauer]]
+
 > * Commit [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1][] says that auto-added
 >   files will be recreated if the user deletes them. That seems bad.
 >   `autoindex` goes to some trouble to not recreate deleted files.
 
+>> I reverted the commit and addressed the issue in
+>> [a358d74bef51dae31332ff27e897fe04834571e6][] and
+>> [981400177d68a279f485727be3f013e68f0bf691][].
+ --[[David_Riebenbauer]]
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
+[da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0 (commitdiff for da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0)
+[a358d74bef51dae31332ff27e897fe04834571e6]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=a358d74bef51dae31332ff27e897fe04834571e6 (commitdiff for a358d74bef51dae31332ff27e897fe04834571e6)
+[981400177d68a279f485727be3f013e68f0bf691]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=981400177d68a279f485727be3f013e68f0bf691 (commitdiff for 981400177d68a279f485727be3f013e68f0bf691)
-- 
cgit v1.2.3


From 61a31a3d63a19f75e3362c7e5ac2067f572c9dca Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Sun, 4 Apr 2010 00:34:36 +0000
Subject: updated branch

---
 doc/todo/matching_different_kinds_of_links.mdwn | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 2cd484852..c4383c0b7 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -106,6 +106,10 @@ Some code refers to `oldtypedlinks`, and other to `oldlinktypes`. --[[Joey]]
 
 >> A test suite for the dependency resolver *would* be nice. --[[Joey]]
 
+>>> Bug fixed, I think. A test suite for the dependency resolver seems
+>>> more ambitious than I want to get into right now, but I added a
+>>> unit test for this part of it... --s
+
 I'm curious what your reasoning was for adding a new variable
 rather than using `pagestate`. Was it only because you needed
 the `old` version to detect change, or was there other complexity?
@@ -120,6 +124,17 @@ the `old` version to detect change, or was there other complexity?
 > my docs for `%typedlinks`, so I'll try to write docs for it as
 > `pagestate` and see if they work any better. --s
 
+>> On reflection, I don't think it's any better as a pagestate, and
+>> the contents of pagestates (so far) aren't documented for other
+>> plugins' consumption, so I'm inclined to leave it as-is, unless
+>> you want to veto that. Loose rationale: it needs special handling
+>> in the core to be a dependency type (I re-used the existing link
+>> type), it's API beyond a single plugin, and it's really part of
+>> the core parallel to pagestate rather than being tied to a
+>> specific plugin. Also, I'd need to special-case it to have
+>> ikiwiki not delete it from the index, unless I introduced a
+>> dummy typedlinks plugin (or just hook) that did nothing... --s
+
 I have not convinced myself this is a real problem, but..
 If a page has a typed link, there seems to be no way to tell
 if it also has a separate, regular link. `add_link` will add
@@ -145,6 +160,8 @@ without too much transitional trouble. --[[Joey]]
 > on the current semantics, on one of the pages requesting this
 > change. --s
 
+>> Removed in a newer version of the branch. --s
+
 I might have been wrong to introduce `typedlink(tag foo)`. It's not
 very user-friendly, and is more useful as a backend for other plugins
 that as a feature in its own right - any plugin introducing a link
@@ -156,3 +173,6 @@ though... --[[smcv]]
 
 > I agree, per-type matchers are more friendly and I'm not enamored of the
 > multi-parameter pagespec syntax. --[[Joey]]
+
+>> Removed in a newer version of the branch. I re-introduced it as a
+>> plugin in `smcv/typedlink`, but I don't think we really need it. --s
-- 
cgit v1.2.3


From b51703569d35790f31dccc3dc2921e8bcccd5b49 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 5 Apr 2010 14:59:29 -0400
Subject: speed

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 8c6e1df3b..739a3d6b0 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -181,6 +181,20 @@ That earlier version of the branch is also available for comparison:
 > to specify a sort method in other directives. --[[Joey]]
 >> Done. --[[smcv]]
 
+## speed
+
+I notice the implementation does not use the magic `$a` and `$b` globals.
+That nasty perl optimisation is still worthwhile:
+
+	perl -e 'use warnings; use strict; use Benchmark; sub a { $a <=> $b } sub b ($$) { $_[0] <=> $_[1] }; my @list=reverse(1..9999); timethese(10000, {a => sub {my @f=sort a @list}, b => sub {my @f=sort b  @list}, c => => sub {my @f=sort { b($a,$b) } @list}})'
+	Benchmark: timing 10000 iterations of a, b, c...
+	         a: 80 wallclock secs (76.74 usr +  0.05 sys = 76.79 CPU) @ 130.23/s (n=10000)
+	         b: 112 wallclock secs (106.14 usr +  0.20 sys = 106.34 CPU) @ 94.04/s (n=10000)
+                 c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
+
+Unfortunatly, I think that c is closest to the new implementation.
+--[[Joey]]
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
-- 
cgit v1.2.3


From 861080b918ef71d82f4a4b9a22093f4a379b5ef8 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Mon, 5 Apr 2010 19:19:00 +0000
Subject: potential performance improvements

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 739a3d6b0..2ce1de6a4 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -195,6 +195,28 @@ That nasty perl optimisation is still worthwhile:
 Unfortunatly, I think that c is closest to the new implementation.
 --[[Joey]]
 
+> Unfortunately, `$a` isn't always `$main::a` - it's `$Package::a` where
+> `Package` is the call site of the sort call. This was a showstopper when
+> `sort` was a hook implemented in many packages, but now that it's a
+> `SortSpec`, I may be able to fix this by putting a `sort` wrapper in the
+> `SortSpec` namespace, so it's like this:
+>
+>     sub sort ($@)
+>     {
+>         my $cmp = shift;
+>         return sort $cmp @_;
+>     }
+>
+> which would mean that the comparison used `$IkiWiki::SortSpec::a`.
+>
+> I do notice that `pagespec_match_list` performs the sort before the
+> filter by pagespec. Is this a deliberate design choice, or
+> coincidence? I can see that when `limit` is used, this could be
+> used to only run the pagespec match function until `limit` pages
+> have been selected, but the cost is that every page in the wiki
+> is sorted. Or, it might be useful to do the filtering first, then
+> sort the sub-list thus produced, then finally apply the limit? --s
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
-- 
cgit v1.2.3


From 10f4695abd65db6c009864c5abb7cb5dfa1cf153 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 5 Apr 2010 15:28:54 -0400
Subject: response

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 2ce1de6a4..0aca74be2 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -165,7 +165,6 @@ That earlier version of the branch is also available for comparison:
 >>>>>>> I've kept the semantics from `report` as-is, then:
 >>>>>>> e.g. `sort="age -title"`. --s
 
->>>>>
 >>>>> Perhaps we could borrow from `meta updated` and use `update_age`?
 >>>>> `updateage` would perhaps be a more normal IkiWiki style - but that
 >>>>> makes me think that updateage is a quantity analagous to tonnage or
@@ -190,7 +189,7 @@ That nasty perl optimisation is still worthwhile:
 	Benchmark: timing 10000 iterations of a, b, c...
 	         a: 80 wallclock secs (76.74 usr +  0.05 sys = 76.79 CPU) @ 130.23/s (n=10000)
 	         b: 112 wallclock secs (106.14 usr +  0.20 sys = 106.34 CPU) @ 94.04/s (n=10000)
-                 c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
+	         c: 330 wallclock secs (320.25 usr +  0.17 sys = 320.42 CPU) @ 31.21/s (n=10000)
 
 Unfortunatly, I think that c is closest to the new implementation.
 --[[Joey]]
@@ -217,6 +216,10 @@ Unfortunatly, I think that c is closest to the new implementation.
 > is sorted. Or, it might be useful to do the filtering first, then
 > sort the sub-list thus produced, then finally apply the limit? --s
 
+>> Yes, it was deliberate, pagespec matching can be expensive enough that
+>> needing to sort a lot of pages seems likely to be less work. (I don't
+>> remember what benchmarking was done though.) --[[Joey]] 
+
 ## Documentation from sort-package branch
 
 ### advanced sort orders (conditionally added to [[ikiwiki/pagespec/sorting]])
-- 
cgit v1.2.3


From b186ec1b4cb8145d6a6cb68478e23d7fb0fa1476 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 6 Apr 2010 00:02:18 +0000
Subject: ready for review, I think

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 51 +++++++++++++++++-----
 1 file changed, 39 insertions(+), 12 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index 0aca74be2..d4da13feb 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -20,7 +20,7 @@ That earlier version of the branch is also available for comparison:
 
 >> I wonder if IkiWiki would benefit from the concept of a "sortspec", like a [[ikiwiki/PageSpec]] but dedicated to sorting lists of pages rather than defining lists of pages?  Rather than defining a sort-hook, define a SortSpec class, and enable people to add their own sort methods as functions defined inside that class, similarly to the way they can add their own pagespec definitions. --[[KathrynAndersen]]
 
->>> [[!template id=gitbranch branch=smcv/sort-package author="[[Simon_McVittie|smcv]]"]]
+>>> [[!template id=gitbranch branch=smcv/ready/sort-package author="[[Simon_McVittie|smcv]]"]]
 >>> I'd be inclined to think that's overkill, but it wasn't very hard to
 >>> implement, and in a way is more elegant. I set it up so sort mechanisms
 >>> share the `IkiWiki::PageSpec` package, but with a `cmp_` prefix. Gitweb:
@@ -207,7 +207,26 @@ Unfortunatly, I think that c is closest to the new implementation.
 >     }
 >
 > which would mean that the comparison used `$IkiWiki::SortSpec::a`.
->
+> --s
+
+>> I've now done this. On a wiki with many [[plugins/contrib/album]]s
+>> (a full rebuild takes half an hour!), I tested a refresh after
+>> `touch tags/*.mdwn` (my tag pages contain inlines of the form
+>> `tagged(foo)` sorted by date, so they exercise sorting).
+>> I also tried removing sorting from `pagespec_match_list`
+>> altogether, as an upper bound for how fast we can possibly make it.
+>>
+>> * `master` at branch point: 63.72user 0.29system
+>> * `master` at branch point: 63.91user 0.37system
+>> * my branch, with `@_`: 65.28user 0.29system
+>> * my branch, with `@_`: 65.21user 0.28system
+>> * my branch, with `$a`: 64.09user 0.28system
+>> * my branch, with `$a`: 63.83user 0.36system
+>> * not sorted at all: 58.99user 0.29system
+>> * not sorted at all: 58.92user 0.29system
+>>
+>> --s
+
 > I do notice that `pagespec_match_list` performs the sort before the
 > filter by pagespec. Is this a deliberate design choice, or
 > coincidence? I can see that when `limit` is used, this could be
@@ -218,7 +237,15 @@ Unfortunatly, I think that c is closest to the new implementation.
 
 >> Yes, it was deliberate, pagespec matching can be expensive enough that
 >> needing to sort a lot of pages seems likely to be less work. (I don't
->> remember what benchmarking was done though.) --[[Joey]] 
+>> remember what benchmarking was done though.) --[[Joey]]
+
+>>> We discussed this on IRC and Joey pointed out that this also affects
+>>> dependency calculation, so I'm not going to get into this now... --s
+
+Joey pointed out on IRC that the `titlesort` feature duplicates all the
+meta titles. I did that in order to sort by the unescaped version, but
+I've now changed the branch to only store that if it makes a difference.
+--s
 
 ## Documentation from sort-package branch
 
@@ -262,13 +289,13 @@ Similarly, it's possible to write plugins that add new functions as
 the IkiWiki::SortSpec package named `cmp_foo`, which will be used when sorting
 by `foo` or `foo(...)` is requested.
 
-The function will be passed three or more parameters. The first two are
-page names, and the third is `undef` if invoked as `foo`, or the parameter
-`"bar"` if invoked as `foo(bar)`. It may also be passed additional, named
-parameters.
+The names of pages to be compared are in the global variables `$a` and `$b`
+in the IkiWiki::SortSpec package. The function should return the same thing
+as Perl's `cmp` and `<=>` operators: negative if `$a` is less than `$b`,
+positive if `$a` is greater, or zero if they are considered equal. It may
+also raise an error using `error`, for instance if it needs a parameter but
+one isn't provided.
 
-It should return the same thing as Perl's `cmp` and `<=>` operators: negative
-if the first argument is less than the second, positive if the first argument
-is greater, or zero if they are considered equal. It may also raise an
-error using `error`, for instance if it needs a parameter but one isn't
-provided.
+The function will also be passed one or more parameters. The first is
+`undef` if invoked as `foo`, or the parameter `"bar"` if invoked as `foo(bar)`;
+it may also be passed additional, named parameters.
-- 
cgit v1.2.3


From 1fb5b9f61c114a0151416d2de69b5ea420c6706b Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 6 Apr 2010 00:04:47 +0000
Subject: switch branch for review to use ready/foo convention

---
 doc/todo/matching_different_kinds_of_links.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index c4383c0b7..5678ee7e2 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -53,7 +53,7 @@ I don't have any opinion on this syntax (whether it's good or not)...--Ivan Z.
 
 -------
 
->> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/link-types]]
+>> [[!template id=gitbranch author="[[Simon_McVittie|smcv]]" branch=smcv/ready/link-types]]
 >> [[!tag patch]]
 
 ## Documentation for smcv's branch
-- 
cgit v1.2.3


From ee1e7079ebe0a1e9d3d6c79cb221a0fb86f423d5 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 6 Apr 2010 04:41:55 +0000
Subject: more flexible underlays, please?

---
 doc/todo/optional_underlaydir_prefix.mdwn | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 doc/todo/optional_underlaydir_prefix.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
new file mode 100644
index 000000000..8fd6d76c5
--- /dev/null
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -0,0 +1,20 @@
+For security reasons, symlinks are disabled in IkiWiki.  That's fair enough, but that means that some problems, which one could otherwise solve by using a symlink, cannot be solved. The specfic problem in this case is that all underlays are placed at the root of the wiki, when it could be more convenient to place some underlays in specific sub-directories.
+
+Use-case 1 (to keep things tidy):
+
+Currently IkiWiki has some javascript files in `underlays/javascript`; that directory is given as one of the underlay directories.  Thus, all the javascript files appear in the root of the generated site.  But it would be tidier if one could say "put the contents of *this* underlaydir under the `js` directory".
+
+Use-case 2 (a read-only external dir):
+
+Suppose I want to include a subset of `/usr/local/share/docs` on my wiki, say the docs about `foo`.  But I want them to be under the `docs/foo` sub-directory on the generated site.  Currently I can't do that.  If I give `/usr/local/share/docs/foo` as an underlaydir, then the contents of that will be in the root of the site, rather than under `docs/foo`.  And if I give `/usr/local/share/docs` as an underlaydir, then the contents of the `foo` dir will be under `foo`, but it will also include every other thing in `/usr/local/share/docs`.
+
+Since we can't use symlinks in an underlay dir to link to these directories, then perhaps one could give a specific underlay dir a specific prefix, which defines the sub-directory that the underlay should appear in.
+
+I'm not sure how this would be implemented, but I guess it could be configured something like this:
+
+    prefixed_underlay => {
+         'js' => '/usr/local/share/ikiwiki/javascript',
+         'docs/foo' => '/usr/local/share/docs/foo',
+    }
+
+[[!taglink wishlist]]
-- 
cgit v1.2.3


From c87ddb6908485fecff9c516223ca0b2973df88f6 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 13:58:55 -0400
Subject: idea

---
 doc/todo/optional_underlaydir_prefix.mdwn | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
index 8fd6d76c5..dd11d062d 100644
--- a/doc/todo/optional_underlaydir_prefix.mdwn
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -4,6 +4,9 @@ Use-case 1 (to keep things tidy):
 
 Currently IkiWiki has some javascript files in `underlays/javascript`; that directory is given as one of the underlay directories.  Thus, all the javascript files appear in the root of the generated site.  But it would be tidier if one could say "put the contents of *this* underlaydir under the `js` directory".
 
+> Of course, this could be accomplished, if we wanted to, by moving the
+> files to `underlays/javascript/js`. --[[Joey]] 
+
 Use-case 2 (a read-only external dir):
 
 Suppose I want to include a subset of `/usr/local/share/docs` on my wiki, say the docs about `foo`.  But I want them to be under the `docs/foo` sub-directory on the generated site.  Currently I can't do that.  If I give `/usr/local/share/docs/foo` as an underlaydir, then the contents of that will be in the root of the site, rather than under `docs/foo`.  And if I give `/usr/local/share/docs` as an underlaydir, then the contents of the `foo` dir will be under `foo`, but it will also include every other thing in `/usr/local/share/docs`.
@@ -17,4 +20,25 @@ I'm not sure how this would be implemented, but I guess it could be configured s
          'docs/foo' => '/usr/local/share/docs/foo',
     }
 
+> So, let me review why symlinks are an issue. For normal, non-underlay
+> pages, users who do not have filesystem access to the server may have 
+> commit access, and so could commit eg, a symlink to `/etc/passwd` (or
+> to `/` !). The guards are there to prevent ikiwiki either exposing the
+> symlink target's contents, or potentially overwriting it.
+> 
+> Is this a concern for underlays? Most of the time, certianly not;
+> the underlay tends to be something only the site admin controls.
+> Not all the security checks that are done on the srcdir are done
+> on the underlays, either. Most checks done on files in the underlay
+> are only done because the same code handles srcdir files. The one
+> exception is the test that skips processing symlinks in the underlay dir.
+> (But note that the underlay directory can be a symlinkt to elsewhere
+> which the srcdir, by default, cannot.)
+> 
+> So, one way to approach this is to make ikiwiki follow directory symlinks
+> inside the underlay directory. Just a matter of passing `follow => 1` to
+> find. (This would still not allow individual files to be symlinks, because
+> `readfile` does not allow reading symlinks. But I don't see much need
+> for that.) --[[Joey]]
+
 [[!taglink wishlist]]
-- 
cgit v1.2.3


From 407a3493599afbb2f16a0ace49ff1924997895d2 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 14:20:44 -0400
Subject: nearly there!

---
 doc/todo/matching_different_kinds_of_links.mdwn | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 5678ee7e2..76a99f6a5 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -176,3 +176,15 @@ though... --[[smcv]]
 
 >> Removed in a newer version of the branch. I re-introduced it as a
 >> plugin in `smcv/typedlink`, but I don't think we really need it. --s
+
+----
+
+I am ready to merge this, but I noticed one problem -- since `match_tagged`
+now only matches pages with the tag linktype, a wiki will need to be
+rebuilt on upgrade in order to get the linktype of existing tags in it
+recorded. So there needs to be a NEWS item about this and
+the postinst modified to force the rebuild.
+
+Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
+but you removed that feature as documented above.
+--[[Joey]]
-- 
cgit v1.2.3


From 899639f10d49cff410059c3af2e1d5717c25b738 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 6 Apr 2010 20:03:26 +0000
Subject: fixed

---
 doc/todo/matching_different_kinds_of_links.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 76a99f6a5..8e81860a1 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -185,6 +185,12 @@ rebuilt on upgrade in order to get the linktype of existing tags in it
 recorded. So there needs to be a NEWS item about this and
 the postinst modified to force the rebuild.
 
+> Done, although you'll need to plug in an appropriate version number when
+> you release it. Is there a distinctive reminder string you grep for
+> during releases? I've used `UNRELEASED` for now. --[[smcv]]
+
 Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
 but you removed that feature as documented above.
 --[[Joey]]
+
+> Done. --s
-- 
cgit v1.2.3


From 811d398646337717f8f2ad92897c6410faa42777 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 6 Apr 2010 23:20:49 +0000
Subject: response

---
 doc/todo/optional_underlaydir_prefix.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/optional_underlaydir_prefix.mdwn b/doc/todo/optional_underlaydir_prefix.mdwn
index dd11d062d..06900a904 100644
--- a/doc/todo/optional_underlaydir_prefix.mdwn
+++ b/doc/todo/optional_underlaydir_prefix.mdwn
@@ -41,4 +41,6 @@ I'm not sure how this would be implemented, but I guess it could be configured s
 > `readfile` does not allow reading symlinks. But I don't see much need
 > for that.) --[[Joey]]
 
+>> If you think that enabling symlinks in underlay directories wouldn't be a security issue, then I'm all for it!  That would be much simpler to implement, I'm sure. --[[KathrynAndersen]]
+
 [[!taglink wishlist]]
-- 
cgit v1.2.3


From fcd810d236fdf779beb740082953a14feba07f0d Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 23:04:54 -0400
Subject: close

---
 doc/todo/matching_different_kinds_of_links.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/matching_different_kinds_of_links.mdwn b/doc/todo/matching_different_kinds_of_links.mdwn
index 8e81860a1..da3ea49f6 100644
--- a/doc/todo/matching_different_kinds_of_links.mdwn
+++ b/doc/todo/matching_different_kinds_of_links.mdwn
@@ -193,4 +193,4 @@ Also, the ready branch adds `typedlink()` to [[ikiwiki/pagespec]],
 but you removed that feature as documented above.
 --[[Joey]]
 
-> Done. --s
+> [[Done]]. --s
-- 
cgit v1.2.3


From dad7ac5a21bc049b9f559c98f4e113c99edb4eb5 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 23:24:22 -0400
Subject: question

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index d4da13feb..d7f10528a 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -10,6 +10,9 @@ title over the page name, but for compatibility, I'm not going to (I do wonder
 whether it would be worth making sort=name an alias for the current sort=title,
 and changing the meaning of sort=title in 4.0, though).
 
+> What compatability concerns, exactly, are there that prevent making that
+> change now? --[[Joey]] 
+
 *[sort-hooks branch now withdrawn in favour of sort-package --s]*
 
 I briefly tried to turn *all* the current sort types into hook functions, and
-- 
cgit v1.2.3


From 32ce94f5a30e52da17f06b9b9dce7f3d3112da98 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 6 Apr 2010 23:30:10 -0400
Subject: close (but one question remains!)

---
 doc/todo/allow_plugins_to_add_sorting_methods.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
index d7f10528a..b523cd19f 100644
--- a/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
+++ b/doc/todo/allow_plugins_to_add_sorting_methods.mdwn
@@ -43,7 +43,7 @@ That earlier version of the branch is also available for comparison:
 
 >>>>>> `SortSpec` --[[Joey]] 
 
->>>>>>> Done. --s
+>>>>>>> [[Done]]. --s
 
 >>>> I would be inclined to drop the `check_` stuff. --[[Joey]] 
 
-- 
cgit v1.2.3


From c127e964f1704a6704639350851afee722825529 Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Wed, 7 Apr 2010 21:25:26 +0100
Subject: expand my response

---
 doc/todo/allow_site-wide_meta_definitions.mdwn | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn
index 7129a44ac..82670250e 100644
--- a/doc/todo/allow_site-wide_meta_definitions.mdwn
+++ b/doc/todo/allow_site-wide_meta_definitions.mdwn
@@ -217,6 +217,16 @@ definitions essentially.
 
 >>> For this to work with websetup and --dumpsetup, it needs to define the
 >>> `meta_*` settings in the getsetup function.
+>>>> 
+>>>> I think this will be problematic with the current implementation of this
+>>>> patch. The datatype here is an array of hash references, with each hash
+>>>> having a variable (and arbitrary) number of key/value pairs.  I can't
+>>>> think of an intuitive way of implementing a way of editing such a
+>>>> datatype in the web interface, let alone registering the option in
+>>>> getsetup.
+>>>> 
+>>>> Perhaps a limited set of defined meta values could be exposed via
+>>>> websetup (the obvious ones: author, copyright, license, etc.) -- [[Jon]]
 >>>
 >>> I also have some concerns about both these patches, since both throw
 >>> a lot of redundant data at meta, which then stores it in a very redundant
@@ -232,6 +242,5 @@ definitions essentially.
 >>> meta special-case the site-wide settings, not store them in these
 >>> per-page data structures, and just make them be used if no per-page
 >>> metadata of the given type is present. --[[Joey]]
-
->>>> Thanks for the review - these are all valid points. I'll get working
->>>> on a revised patch. -- [[Jon]]
+>>>> 
+>>>> that should be easy enough to do. I will work on a patch. -- [[Jon]]
-- 
cgit v1.2.3


From a8761a086ebf353192e4721090ff11d3f67707b6 Mon Sep 17 00:00:00 2001
From: Cord 
Date: Sat, 10 Apr 2010 07:06:06 +0000
Subject:

---
 doc/todo/More_flexible_po-plugin_for_translation.mdwn | 5 +++++
 1 file changed, 5 insertions(+)
 create mode 100644 doc/todo/More_flexible_po-plugin_for_translation.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/More_flexible_po-plugin_for_translation.mdwn b/doc/todo/More_flexible_po-plugin_for_translation.mdwn
new file mode 100644
index 000000000..3399f7834
--- /dev/null
+++ b/doc/todo/More_flexible_po-plugin_for_translation.mdwn
@@ -0,0 +1,5 @@
+I have a website with multi-language content, where some content is only in English, some in German, and some is available in both languages.
+
+The po-module currently has only one master-language, with slave languages, and a  PageSpec should be considered.
+
+It would be nice to flag the content which should have a translation on a file-by-file basis (with some inline directive?) which could contain the information of the master-language for that file and the desired target-languages.
-- 
cgit v1.2.3


From cecbd529389788c1f1cb647e2ff297cda7554456 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 11 Apr 2010 00:30:27 -0400
Subject: plan for more efficient pagespec_match_list sorting

(smcv please note)
---
 doc/todo/smarter_sorting.mdwn | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 doc/todo/smarter_sorting.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
new file mode 100644
index 000000000..5a6d63ef1
--- /dev/null
+++ b/doc/todo/smarter_sorting.mdwn
@@ -0,0 +1,33 @@
+I benchmarked a build of a large wiki (my home wiki), and it was spending
+quite a lot of time sorting; `CORE::sort` was called only 1138 times, but
+still flagged as the #1 time sink. (I'm not sure I trust NYTProf fully
+about that FWIW, since it also said 27238263 calls to `cmp_age` were
+the #3 timesink, and I suspect it may not entirely accurately measure
+the overhead of so many short function calls.)
+
+`pagespec_match_list` currently always sorts *all* pages first, and then
+finds the top M that match the pagespec. That's innefficient when M is
+small (as for example in a typical blog, where only 20 posts are shown,
+out of maybe thousands).
+
+As [[smcv]] noted, It could be flipped, so the pagespec is applied first,
+and then sort the smaller matching set. But, checking pagespecs is likely
+more expensive than sorting. (Also, influence calculation complicates
+doing that, since only influences for the M returned pages should be tracked.)
+
+Another option, when there is a limit on M pages to return, might be to
+cull the M top pages without sorting the rest. This could be done using
+a variant of Ye Olde Bubble Sort. Take the first M pages, and (quick)sort.
+Then for each of the rest, check if it is higher than the Mth page.
+If it is, bubble it up so it's sorted.
+If not, throw it out (that's the fast bit and why this is not O(N^2)).
+
+This would be bad when M is very large, and particularly, of course, when
+there is no limit and all pages are being matched on. (For example, an
+archive page shows all pages that match a pagespec specifying a creation
+date range.) Well, in this case, it *does* make sense to flip it, limit by
+pagespe first, and do a (quick)sort second. (No influence complications,
+either.)
+
+Adding these special cases will be more complicated, but I think the best
+of both worlds. --[[Joey]]
-- 
cgit v1.2.3


From 0bfc364a7df124509855b8ed0b1b33ab5bc9ebbb Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sun, 11 Apr 2010 01:30:03 -0400
Subject: optimization: pagespec_match_list with no num limit matches before
 sorting

This can be a lot faster, since huge numbers of pages are not sorted
only to mostly be thrown away. It sped up a build of my blog by at least
5 minutes.
---
 IkiWiki.pm                    | 38 ++++++++++++++++++++++++++------------
 doc/todo/smarter_sorting.mdwn |  3 +++
 t/pagespec_match_list.t       |  6 +++++-
 3 files changed, 34 insertions(+), 13 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki.pm b/IkiWiki.pm
index 2cad6a3ef..74d452c50 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -1951,8 +1951,9 @@ sub add_link ($$;$) {
 	}
 }
 
-sub sortspec_translate ($) {
+sub sortspec_translate ($$) {
 	my $spec = shift;
+	my $reverse = shift;
 
 	my $code = "";
 	my @data;
@@ -2007,6 +2008,10 @@ sub sortspec_translate ($) {
 		return sub { 0 };
 	}
 
+	if ($reverse) {
+		$code="-($code)";
+	}
+
 	no warnings;
 	return eval 'sub { '.$code.' }';
 }
@@ -2109,18 +2114,20 @@ sub pagespec_match_list ($$;@) {
 			? grep { ! $params{filter}->($_) } keys %pagesources
 			: keys %pagesources;
 	}
-
-	if (defined $params{sort}) {
-		@candidates = IkiWiki::SortSpec::sort_pages($params{sort},
-			@candidates);
+	
+	my $num=$params{num};
+	my $sort=$params{sort};
+	my $reverse=$params{reverse};
+	# when only the top matches will be returned, it's efficient to
+	# sort before matching to pagespec,
+	if (defined $num && defined $sort) {
+		@candidates=IkiWiki::SortSpec::sort_pages(
+			$sort, $reverse, @candidates);
 	}
-
-	@candidates=reverse(@candidates) if $params{reverse};
 	
 	$depends{$page}{$pagespec} |= ($params{deptype} || $DEPEND_CONTENT);
 	
 	# clear params, remainder is passed to pagespec
-	my $num=$params{num};
 	delete @params{qw{num deptype reverse sort filter list}};
 	
 	my @matches;
@@ -2144,7 +2151,15 @@ sub pagespec_match_list ($$;@) {
 		$depends_simple{$page}{lc $k} |= $i->{$k};
 	}
 
-	return @matches;
+	# when all matches will be returned, it's efficient to
+	# sort after matching
+	if (! defined $num && defined $sort) {
+		return IkiWiki::SortSpec::sort_pages(
+			$sort, $reverse, @matches);
+	}
+	else {
+		return @matches;
+	}
 }
 
 sub pagespec_valid ($) {
@@ -2437,9 +2452,8 @@ package IkiWiki::SortSpec;
 # This is in the SortSpec namespace so that the $a and $b that sort() uses
 # are easily available in this namespace, for cmp functions to use them.
 sub sort_pages {
-	my $f = IkiWiki::sortspec_translate(shift);
-
-	return sort $f @_;
+	my $f=IkiWiki::sortspec_translate(shift, shift);
+	sort $f @_
 }
 
 sub cmp_title {
diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index 5a6d63ef1..f8ac216dc 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -29,5 +29,8 @@ date range.) Well, in this case, it *does* make sense to flip it, limit by
 pagespe first, and do a (quick)sort second. (No influence complications,
 either.)
 
+> Flipping when there's no limit implemented, and it knocked 1/3 off
+> the rebuild time of my blog's archive pages. --[[Joey]] 
+
 Adding these special cases will be more complicated, but I think the best
 of both worlds. --[[Joey]]
diff --git a/t/pagespec_match_list.t b/t/pagespec_match_list.t
index 2ad7a9105..c7688c6c0 100755
--- a/t/pagespec_match_list.t
+++ b/t/pagespec_match_list.t
@@ -1,7 +1,7 @@
 #!/usr/bin/perl
 use warnings;
 use strict;
-use Test::More tests => 90;
+use Test::More tests => 92;
 
 BEGIN { use_ok("IkiWiki"); }
 
@@ -38,12 +38,16 @@ $links{foo3}=[qw{bar}];
 is_deeply([pagespec_match_list("foo", "bar")], ["bar"]);
 is_deeply([sort(pagespec_match_list("foo", "* and !post/*"))], ["bar", "foo", "foo2", "foo3"]);
 is_deeply([sort(pagespec_match_list("foo", "post/*"))], ["post/1", "post/2", "post/3"]);
+is_deeply([pagespec_match_list("foo", "post/*", sort => "title")],
+	["post/1", "post/2", "post/3"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title", reverse => 1)],
 	["post/3", "post/2", "post/1"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title", num => 2)],
 	["post/1", "post/2"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title", num => 50)],
 	["post/1", "post/2", "post/3"]);
+is_deeply([pagespec_match_list("foo", "post/*", sort => "title", num => 50, reverse => 1)],
+	["post/3", "post/2", "post/1"]);
 is_deeply([pagespec_match_list("foo", "post/*", sort => "title",
                          filter => sub { $_[0] =~ /3/}) ],
 	["post/1", "post/2"]);
-- 
cgit v1.2.3


From df022df35e3e3fd1d2916e762a2359f23a84a955 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 12 Apr 2010 14:57:40 -0400
Subject: implemented the other half of this

Writing my own sort code actually was faster than the built in sort. Whee!
(That's not supposed to happen, is it. ;)

But, I need to make sure influences are calculated alright.
---
 doc/todo/smarter_sorting.mdwn | 107 +++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 106 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index f8ac216dc..4a638213f 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -13,7 +13,7 @@ out of maybe thousands).
 As [[smcv]] noted, It could be flipped, so the pagespec is applied first,
 and then sort the smaller matching set. But, checking pagespecs is likely
 more expensive than sorting. (Also, influence calculation complicates
-doing that, since only influences for the M returned pages should be tracked.)
+doing that.)
 
 Another option, when there is a limit on M pages to return, might be to
 cull the M top pages without sorting the rest. This could be done using
@@ -22,6 +22,111 @@ Then for each of the rest, check if it is higher than the Mth page.
 If it is, bubble it up so it's sorted.
 If not, throw it out (that's the fast bit and why this is not O(N^2)).
 
+> The patch below implements this, perhaps not as efficiently as possible.
+> It speeds up building just the top page of my blog by 1 second (out of
+> 18). It's probably buggy.
+> 
+> But, I have not thought enough about influence calculation.
+> I need to figure out which pagespec matches influences need to be
+> accumulated for in order to determine all possible influences of a
+> pagespec are known.
+> 
+> The old code accumulates influences from matching all successful pages
+> up to the num cutoff, as well as influences from an arbitrary (sometimes
+> zero) number of failed matches. New code does not accumulate influences
+> from all the top successful matches, only an arbitrary group of
+> successes and some failures.
+
+
+diff --git a/IkiWiki.pm b/IkiWiki.pm
+index 1730e47..6798799 100644
+--- a/IkiWiki.pm
++++ b/IkiWiki.pm
+@@ -2122,36 +2122,53 @@ sub pagespec_match_list ($$;@) {
+ 	my $num=$params{num};
+ 	delete @params{qw{num deptype reverse sort filter list}};
+ 	
+-	# when only the top matches will be returned, it's efficient to
+-	# sort before matching to pagespec,
+-	if (defined $num && defined $sort) {
+-		@candidates=IkiWiki::SortSpec::sort_pages(
+-			$sort, @candidates);
+-	}
+-	
++	# Find the first num matches (or all), before sorting.
+ 	my @matches;
+-	my $firstfail;
+ 	my $count=0;
+ 	my $accum=IkiWiki::SuccessReason->new();
+-	foreach my $p (@candidates) {
+-		my $r=$sub->($p, %params, location => $page);
++	my $i;
++	for ($i=0; $i < @candidates; $i++) {
++		my $r=$sub->($candidates[$i], %params, location => $page);
+ 		error(sprintf(gettext("cannot match pages: %s"), $r))
+ 			if $r->isa("IkiWiki::ErrorReason");
+ 		$accum |= $r;
+ 		if ($r) {
+-			push @matches, $p;
++			push @matches, $candidates[$i];
+ 			last if defined $num && ++$count == $num;
+ 		}
+ 	}
+ 
++	# We have num natches, but they may not be the best.
++	# Efficiently find and add the rest, without sorting the full list of
++	# candidates.
++	if (defined $num && defined $sort) {
++		@matches=IkiWiki::SortSpec::sort_pages($sort, @matches);
++
++		for ($i++; $i < @candidates; $i++) {
++			# Comparing candidate with lowest match is cheaper,
++			# so it's done before testing against pagespec.
++			if (IkiWiki::SortSpec::cmptwo($candidates[$i], $matches[-1], $sort) < 0 &&
++			    $sub->($candidates[$i], %params, location => $page)
++			) {
++				# this could be done less expensively
++				# using a binary search
++				for (my $j=0; $j < @matches; $j++) {
++					if (IkiWiki::SortSpec::cmptwo($candidates[$i], $matches[$j], $sort) < 0) {
++						$matches[$j]=$candidates[$i];
++						last;
++					}
++				}
++			}
++		}
++	}
++
+ 	# Add simple dependencies for accumulated influences.
+-	my $i=$accum->influences;
+-	foreach my $k (keys %$i) {
+-		$depends_simple{$page}{lc $k} |= $i->{$k};
++	my $inf=$accum->influences;
++	foreach my $k (keys %$inf) {
++		$depends_simple{$page}{lc $k} |= $inf->{$k};
+ 	}
+ 
+-	# when all matches will be returned, it's efficient to
+-	# sort after matching
++	# Sort if we didn't already.
+ 	if (! defined $num && defined $sort) {
+ 		return IkiWiki::SortSpec::sort_pages(
+ 			$sort, @matches);
+@@ -2455,6 +2472,12 @@ sub sort_pages {
+ 	sort $f @_
+ }
+ 
++sub cmptwo {
++	$a=$_[0];
++	$b=$_[1];
++	$_[2]->();
++}
++
+ sub cmp_title {
+ 	IkiWiki::pagetitle(IkiWiki::basename($a))
+ 	cmp
+
+ This would be bad when M is very large, and particularly, of course, when there is no limit and all pages are being matched on. (For example, an archive page shows all pages that match a pagespec specifying a creation -- cgit v1.2.3 From 24fb346938037b0d41988510bc6e19e81aa62190 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 12 Apr 2010 16:04:49 -0400 Subject: fix bug --- doc/todo/smarter_sorting.mdwn | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn index 4a638213f..33c825641 100644 --- a/doc/todo/smarter_sorting.mdwn +++ b/doc/todo/smarter_sorting.mdwn @@ -24,7 +24,7 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)). > The patch below implements this, perhaps not as efficiently as possible. > It speeds up building just the top page of my blog by 1 second (out of -> 18). It's probably buggy. +> 18). > > But, I have not thought enough about influence calculation. > I need to figure out which pagespec matches influences need to be @@ -39,10 +39,10 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)).
 diff --git a/IkiWiki.pm b/IkiWiki.pm
-index 1730e47..6798799 100644
+index 1730e47..bc8b23d 100644
 --- a/IkiWiki.pm
 +++ b/IkiWiki.pm
-@@ -2122,36 +2122,53 @@ sub pagespec_match_list ($$;@) {
+@@ -2122,36 +2122,54 @@ sub pagespec_match_list ($$;@) {
  	my $num=$params{num};
  	delete @params{qw{num deptype reverse sort filter list}};
  	
@@ -89,7 +89,8 @@ index 1730e47..6798799 100644
 +				# using a binary search
 +				for (my $j=0; $j < @matches; $j++) {
 +					if (IkiWiki::SortSpec::cmptwo($candidates[$i], $matches[$j], $sort) < 0) {
-+						$matches[$j]=$candidates[$i];
++						splice @matches, $j, $#matches-$j+1, $candidates[$i],
++							@matches[$j..$#matches-1];
 +						last;
 +					}
 +				}
@@ -112,7 +113,7 @@ index 1730e47..6798799 100644
  	if (! defined $num && defined $sort) {
  		return IkiWiki::SortSpec::sort_pages(
  			$sort, @matches);
-@@ -2455,6 +2472,12 @@ sub sort_pages {
+@@ -2455,6 +2473,12 @@ sub sort_pages {
  	sort $f @_
  }
  
-- 
cgit v1.2.3


From aaaef740107aacd8f6987711da6895c02e4473ad Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 12 Apr 2010 16:46:38 -0400
Subject: update

---
 doc/todo/smarter_sorting.mdwn | 15 +++++++--------
 1 file changed, 7 insertions(+), 8 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/smarter_sorting.mdwn b/doc/todo/smarter_sorting.mdwn
index 33c825641..901e143a7 100644
--- a/doc/todo/smarter_sorting.mdwn
+++ b/doc/todo/smarter_sorting.mdwn
@@ -16,15 +16,9 @@ more expensive than sorting. (Also, influence calculation complicates
 doing that.)
 
 Another option, when there is a limit on M pages to return, might be to
-cull the M top pages without sorting the rest. This could be done using
-a variant of Ye Olde Bubble Sort. Take the first M pages, and (quick)sort.
-Then for each of the rest, check if it is higher than the Mth page.
-If it is, bubble it up so it's sorted.
-If not, throw it out (that's the fast bit and why this is not O(N^2)).
+cull the M top pages without sorting the rest.
 
-> The patch below implements this, perhaps not as efficiently as possible.
-> It speeds up building just the top page of my blog by 1 second (out of
-> 18).
+> The patch below implements this.
 > 
 > But, I have not thought enough about influence calculation.
 > I need to figure out which pagespec matches influences need to be
@@ -36,6 +30,11 @@ If not, throw it out (that's the fast bit and why this is not O(N^2)).
 > zero) number of failed matches. New code does not accumulate influences
 > from all the top successful matches, only an arbitrary group of
 > successes and some failures.
+> 
+> Also, by the time I finished this, it was not measuarably faster than 
+> the old method. At least not with a few thousand pages; it
+> might be worth revisiting this sometime for many more pages? [[done]]
+> --[[Joey]] 
 
 
 diff --git a/IkiWiki.pm b/IkiWiki.pm
-- 
cgit v1.2.3


From 43ed0cd07ece2b5238d1c148552620a6a1c37436 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 14 Apr 2010 16:04:52 -0400
Subject: note link types are now available

---
 doc/todo/structured_page_data.mdwn            | 3 +++
 doc/todo/tracking_bugs_with_dependencies.mdwn | 3 +++
 2 files changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn
index da9da9663..9f21fab7f 100644
--- a/doc/todo/structured_page_data.mdwn
+++ b/doc/todo/structured_page_data.mdwn
@@ -253,6 +253,9 @@ in a large number of other cases.
 > dependencies between bugs from arbitrary links.
 >> This issue (the need for distinguished kinds of links) has also been brought up in other discussions: [[tracking_bugs_with_dependencies#another_kind_of_links]] (deps vs. links) and [[tag_pagespec_function]] (tags vs. links). --Ivan Z.
 
+>>> And multiple link types are now supported; plugins can set the link
+>>> type when registering a link, and pagespec functions can match on them. --[[Joey]] 
+
 ----
 
     #!/usr/bin/perl
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index 5f3ece290..456dadad0 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -81,6 +81,9 @@ I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so
 
 >> I saw that this issue is targeted at by the work on [[structured page data#another_kind_of_links]]. --Ivan Z.
 
+>>> It's fixed now; links can have a type, such as "tag", or "dependency", 
+>>> and pagespecs can match links of a given typo. --[[Joey]] 
+
 Okie - I've had a quick attempt at this.  Initial patch attached.  This one doesn't quite work.
 And there is still a lot of debugging stuff in there.
 
-- 
cgit v1.2.3


From 2f6da5fd2b17541ff88072862d37c4d6f95a50b5 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Thu, 15 Apr 2010 07:19:47 +0000
Subject: Describe my tag type proposal

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)
 create mode 100644 doc/todo/Multiple_categorization_namespaces.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
new file mode 100644
index 000000000..8a0866dc5
--- /dev/null
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -0,0 +1,24 @@
+I came across this when working on converting my old blog into an ikiwiki, but I think it could be of more general use.
+
+The background: I have a (currently suspended, waiting to be converted) blog on the [il Cannocchiale](http://www.ilcannocchiale.it) hosting platform. Aside from the usual metatadata (title, author), il Cannocchiale also provides tags and two additional categorization namespaces: a blog-specific user-defind "column" (Rubrica) and a platform-wide "category" (Categoria). The latter is used to group and label a couple of platform-wide lists of latest posts, the former may be used in many different ways (e.g. multi-author blogs could have one column per author or so, or as a form of 'macro-tagging'). Columns are also a little more sophisticated than classical tags because you can assign them a subtitle too.
+
+When I started working on the conversion, my first idea was to convert Rubriche to subdirectories of an ikiwiki blog. However, this left me with a few annoying things: when rebuilding links from the import, I had to (programmatically) dive into each subdirectory to see where each post was; this would also be problematic for future posting, too. It also meant that moving a post from a Robrica to the other would break all links (unless ikiwiki has a way to fix this automagically). And I wasn't too keen on the fact that the Rubrica would come up in the URL of the post. And finally, of course, I couldn't use this to preserve the Categoria metadata.
+
+Another solution I thought about was to use special deeper tags for the Rubrica and Categoria (like: `\[[!tag "Rubrica/Some name"]]`), but this is horrible, clumsy, and makes special treatment of these tags a PITN (for example you wouldn't want the Rubrica to be displayed together with the other tags, and you would want it displayed somewhere else like next to the title of the post). This solution however looks to me as the proper path, as long as tags could support totally separate namespaces. I have a tentative implementation of this `tagtype` feature at [my git clone of ikiwiki](http://git.oblomov.eu/ikiwiki).
+
+The feature is currently implemented as follows: a `tagtypes` config options takes an array of strings: the tag types to be defined _aside from the usual tags_. Each tag type automatically provides a new directive which sets up tags that different from standard tags by having a different tagbase (the same as the tagtype) and link type (again, the same as the tagtype) (a TODO item for this would to make the directive, tagbase and link type customizable). For example, for my imported blog I would define
+
+    tagtypes => [qw{Categoria Rubrica}]
+
+and then in the blog posts I would have stuff like
+
+    \[[!Categoria "LAVORO/Vita da impiegato"]]
+    \[[!Rubrica "Il mio mondo"]]
+    \[[!meta title="Blah blah"]]
+    \[[!meta author="oblomov"]]
+
+    The body of the article
+
+    \[[!tag a bunch of tags]]
+
+and the tags would appear at the bottom of the post, the Rubrica next to the title, etc. All of this information would end up as categories in the feeds (although I would like to rework that code to make use of namespaces, terms and labels in a different way).
-- 
cgit v1.2.3


From 19700c70e54cd6d94cf02bf160d65f951dcb7d66 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Thu, 15 Apr 2010 07:39:32 +0000
Subject: response, alternative proposal

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 11 +++++++++++
 1 file changed, 11 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 8a0866dc5..dc66a0245 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -22,3 +22,14 @@ and then in the blog posts I would have stuff like
     \[[!tag a bunch of tags]]
 
 and the tags would appear at the bottom of the post, the Rubrica next to the title, etc. All of this information would end up as categories in the feeds (although I would like to rework that code to make use of namespaces, terms and labels in a different way).
+
+> Note [[plugins/contrib/report/discussion]].  To quote myself from the latter page:
+> *I find tags as they currently exist to be too limiting. I prefer something that can be used for Faceted Tagging http://en.wikipedia.org/wiki/Faceted_classification; that is, things like Author:Fred Nurk, Genre:Historical, Rating:Good, and so on. Of course, that doesn't mean that each tag is limited to only one value, either; just to take the above examples, something might have more than one author, or have multiple genres (such as Historical + Romance).*
+
+> So you aren't the only one who wants to do more with tags, but I don't think that adding a new directive for each tag type is the way to go; I think it would be simpler to just have one directive, and take advantage of the new [[matching different kinds of links]] functionality, and enhance the tag directive.
+> Perhaps something like this:
+
+	     \[[!tag categorica="LAVORO/Vita da impiegato" rubrica="Il mio mondo"]]
+
+> Part of my thinking in this is to also combine tags with [[plugins/contrib/field]], so that the tags for a page could be queried and displayed; that way, one could put them wherever you wanted on the page, using any of [[plugins/contrib/getfield]], [[plugins/contrib/ftemplate]], or [[plugins/contrib/report]].
+> --[[KathrynAndersen]]
-- 
cgit v1.2.3


From 55d4e6bdce5cf16c629765bf227125ea8899417b Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Thu, 15 Apr 2010 13:54:54 +0000
Subject: Reply to KA about collapsing metadata functionality

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index dc66a0245..15b97e480 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -2,7 +2,7 @@ I came across this when working on converting my old blog into an ikiwiki, but I
 
 The background: I have a (currently suspended, waiting to be converted) blog on the [il Cannocchiale](http://www.ilcannocchiale.it) hosting platform. Aside from the usual metatadata (title, author), il Cannocchiale also provides tags and two additional categorization namespaces: a blog-specific user-defind "column" (Rubrica) and a platform-wide "category" (Categoria). The latter is used to group and label a couple of platform-wide lists of latest posts, the former may be used in many different ways (e.g. multi-author blogs could have one column per author or so, or as a form of 'macro-tagging'). Columns are also a little more sophisticated than classical tags because you can assign them a subtitle too.
 
-When I started working on the conversion, my first idea was to convert Rubriche to subdirectories of an ikiwiki blog. However, this left me with a few annoying things: when rebuilding links from the import, I had to (programmatically) dive into each subdirectory to see where each post was; this would also be problematic for future posting, too. It also meant that moving a post from a Robrica to the other would break all links (unless ikiwiki has a way to fix this automagically). And I wasn't too keen on the fact that the Rubrica would come up in the URL of the post. And finally, of course, I couldn't use this to preserve the Categoria metadata.
+When I started working on the conversion, my first idea was to convert Rubriche to subdirectories of an ikiwiki blog. However, this left me with a few annoying things: when rebuilding links from the import, I had to (programmatically) dive into each subdirectory to see where each post was; this would also be problematic for future posting, too. It also meant that moving a post from a Rubrica to the other would break all links (unless ikiwiki has a way to fix this automagically). And I wasn't too keen on the fact that the Rubrica would come up in the URL of the post. And finally, of course, I couldn't use this to preserve the Categoria metadata.
 
 Another solution I thought about was to use special deeper tags for the Rubrica and Categoria (like: `\[[!tag "Rubrica/Some name"]]`), but this is horrible, clumsy, and makes special treatment of these tags a PITN (for example you wouldn't want the Rubrica to be displayed together with the other tags, and you would want it displayed somewhere else like next to the title of the post). This solution however looks to me as the proper path, as long as tags could support totally separate namespaces. I have a tentative implementation of this `tagtype` feature at [my git clone of ikiwiki](http://git.oblomov.eu/ikiwiki).
 
@@ -33,3 +33,13 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 
 > Part of my thinking in this is to also combine tags with [[plugins/contrib/field]], so that the tags for a page could be queried and displayed; that way, one could put them wherever you wanted on the page, using any of [[plugins/contrib/getfield]], [[plugins/contrib/ftemplate]], or [[plugins/contrib/report]].
 > --[[KathrynAndersen]]
+
+>> A very generic metadata framework could cover all possible usages of fields, tags, and related metadata, but keeping its _user interface_ generic would only make it hard to use. Note that this is not an objection to the idea of collapsing the fields and tags functionality (at quick glance, I cannot see a real difference between single-valued custom tagtypes and fields, but see below), but more about the syntax.
+
+>> I had thought about the `\[[!tag type1=value1 type2=value2]]` syntax myself, but ultimately decided against it for a number of reasons, most importantly the fact that (1) it's harder to type, (2) it's harder to spot errors in the tag types (so for example if one misspelled `categoria` as `categorica`, he might not notice it as quickly as seeing the un-parsed `\[[!categorica ]]` directive in the output html) and (3) it encourages collapsing possibly unrelated metadata together (for example, I would never consider putting the categoria information together with the rubrica  one; of course with your syntax it's perfectly possible to keep them separate as well).
+
+>> Point (2) may be considered a downside as well as an upside, depending on perspective, of course. And it would be possible to have a set of predefined tag types to match against, like in my tagtype directive approach but with your syntax. Point (3) is of course entirely in the hands of the user, but that's exactly what syntax should be about. There is nothing functionally wrong with e.g. `\[[!meta tag=sometag author=someauthor title=sometitle rubrica=somecolumn]]`, but I honestly find it horrible.
+
+>> A solution could be to allow both syntaxes, getting to have for example `\[[!sometagtype "blah"]]` as a shortcut for `\[[!tag sometagtype="blah"]]` (or, in the more general case, `\[[!somefieldname "blah"]]` as a shortcut for `\[[!meta fieldname="blah"]]`).
+
+>> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me.
-- 
cgit v1.2.3


From f0ed76441d94c9bec9ebc1314b81301fe179a7fc Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Thu, 15 Apr 2010 23:36:42 +0000
Subject: some comments about this and autoindex

---
 ...auto-create_tag_pages_according_to_a_template.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 07b570b1b..7631e6fc8 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -211,6 +211,25 @@ wrong direction.
 >> [981400177d68a279f485727be3f013e68f0bf691][].
  --[[David_Riebenbauer]]
 
+>>> This doesn't seem to have all the refinements that autoindex has:
+>>>
+>>> * `autoindex` attaches the record of deletions off the `index` page, which
+>>>   is (nearly) guaranteed to exist; this one attaches the record of
+>>>   deletions to the deleted page's page state.
+>>>
+>>> * `autoindex` forgets that a page was deleted when that page is
+>>>   re-created
+>>>
+>>> * `autoindex` forgets that a page was deleted when it's no longer needed
+>>>   anyway (this may be harder for `autotag`?)
+>>>
+>>> It'd probably be an interesting test of the core change to port
+>>> `autoindex` to use it? (Adding the file to the RCS would be
+>>> necessary to get parity with `autoindex`.) --[[smcv]]
+
+> Regarding the call from `IkiWiki.pm` to `Render.pm`, wouldn't this be
+> quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From b5e7f7a67f9893c7083afe3594c4a274c1b96062 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Thu, 15 Apr 2010 23:39:02 +0000
Subject: slight clarification

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 7631e6fc8..6118cb014 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -213,9 +213,10 @@ wrong direction.
 
 >>> This doesn't seem to have all the refinements that autoindex has:
 >>>
->>> * `autoindex` attaches the record of deletions off the `index` page, which
+>>> * `autoindex` attaches the record of deletions to the `index` page, which
 >>>   is (nearly) guaranteed to exist; this one attaches the record of
->>>   deletions to the deleted page's page state.
+>>>   deletions to the deleted page's page state. Won't that tend to result
+>>>   in losing the record along with the deleted page?
 >>>
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
-- 
cgit v1.2.3


From 208a77a977615b3e285d08b33345daca7072432e Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Fri, 16 Apr 2010 03:41:25 +0000
Subject: response

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 15b97e480..eb1f58cfa 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -38,8 +38,16 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 
 >> I had thought about the `\[[!tag type1=value1 type2=value2]]` syntax myself, but ultimately decided against it for a number of reasons, most importantly the fact that (1) it's harder to type, (2) it's harder to spot errors in the tag types (so for example if one misspelled `categoria` as `categorica`, he might not notice it as quickly as seeing the un-parsed `\[[!categorica ]]` directive in the output html) and (3) it encourages collapsing possibly unrelated metadata together (for example, I would never consider putting the categoria information together with the rubrica  one; of course with your syntax it's perfectly possible to keep them separate as well).
 
->> Point (2) may be considered a downside as well as an upside, depending on perspective, of course. And it would be possible to have a set of predefined tag types to match against, like in my tagtype directive approach but with your syntax. Point (3) is of course entirely in the hands of the user, but that's exactly what syntax should be about. There is nothing functionally wrong with e.g. `\[[!meta tag=sometag author=someauthor title=sometitle rubrica=somecolumn]]`, but I honestly find it horrible.
+>> Point (2) may be considered a downside as well as an upside, depending on perspective, of course. And it would be possible to have a set of predefined tag types to match against, like in my tagtype directive approach but with your syntax.
+
+>>> You seem to have answered your own objections already. -- K.A.
+
+>>Point (3) is of course entirely in the hands of the user, but that's exactly what syntax should be about. There is nothing functionally wrong with e.g. `\[[!meta tag=sometag author=someauthor title=sometitle rubrica=somecolumn]]`, but I honestly find it horrible.
+
+>>> So, really, point 3 comes down to differing aesthetics. -- K.A.
 
 >> A solution could be to allow both syntaxes, getting to have for example `\[[!sometagtype "blah"]]` as a shortcut for `\[[!tag sometagtype="blah"]]` (or, in the more general case, `\[[!somefieldname "blah"]]` as a shortcut for `\[[!meta fieldname="blah"]]`).
 
 >> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me.
+
+>>> Whereas I prefer being able to control such things with templates, because it gives more flexibility AND control. - K.A.
-- 
cgit v1.2.3


From 5c263623c2446191332088a29fda4e045cc06f1e Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 16 Apr 2010 17:19:44 +0200
Subject: answer about the `%pagestate` of autopages.

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 26 +++++++++++++++++++---
 1 file changed, 23 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 6118cb014..ca3475149 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -217,20 +217,40 @@ wrong direction.
 >>>   is (nearly) guaranteed to exist; this one attaches the record of
 >>>   deletions to the deleted page's page state. Won't that tend to result
 >>>   in losing the record along with the deleted page?
->>>
+
+>>>> This is probably on of the harder things to do, 'cause there are (most of the
+>>>> time) several pages that are responsible for the creation of a single tag page.
+>>>> Of course I could attach the info to all of them.
+
+>>>> With current behaviour I think the information in `%pagestate` is kept around
+>>>> regardless whether the corresponding page exists or not.
+>>>> --[[David_Riebenbauer]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
->>>
+
+>>>> Yes, I forgot about that and that is a bug. I'll fix that.
+>>>> --[[David_Riebenbauer]]
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
->>>
+
+>>>> I don't think so. AFAIK ikiwiki can detect whether there are taglinks to a page
+>>>> anyway, so it should be quite easy. I'll try to implement that too.
+>>>> --[[David_Riebenbauer]]
+
 >>> It'd probably be an interesting test of the core change to port
 >>> `autoindex` to use it? (Adding the file to the RCS would be
 >>> necessary to get parity with `autoindex`.) --[[smcv]]
 
+>>>> Good suggestion. Adding the files to RCS is on my todo list anyway.
+>>>> --[[David_Riebenbauer]]
+
 > Regarding the call from `IkiWiki.pm` to `Render.pm`, wouldn't this be
 > quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
 
+>> True. I'll do that. --[[David_Riebenbauer]]
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From e26ac520bffe39e400a037aa35b68f617991da2b Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 16 Apr 2010 17:21:54 +0200
Subject: typo

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index ca3475149..c4d9538a1 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -126,7 +126,7 @@ is not satisfied for the newly created tag page. I shall put debug msgs into Ren
 
 ---
 
-I've made another attempt at fixiing this
+I've made another attempt at fixing this
 
 The current progress can be found at my [git repository][gitweb] on branch
 `autotag`:
-- 
cgit v1.2.3


From 18b39ff9757a0e6bc8672a2453411676a09bffea Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Fri, 16 Apr 2010 15:31:31 +0000
Subject: try to clarify

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index c4d9538a1..b8b0186b4 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -226,6 +226,11 @@ wrong direction.
 >>>> regardless whether the corresponding page exists or not.
 >>>> --[[David_Riebenbauer]]
 
+>>>>> Sorry, I'll try to be clearer: `autoindex` hard-codes that the [[index]] page
+>>>>> of the entire wiki is the one responsible for storing the page state. That
+>>>>> page isn't responsible for the creation of the tag page, it's just an
+>>>>> arbitrary page that's (more or less) guaranteed to exist. --[[smcv]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
 
-- 
cgit v1.2.3


From 49be30eae88b4a027becc3e67bc321e0bf89840f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 16 Apr 2010 12:08:12 -0400
Subject: clarify re %pagestate persistence

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index b8b0186b4..1259552bf 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -231,6 +231,11 @@ wrong direction.
 >>>>> page isn't responsible for the creation of the tag page, it's just an
 >>>>> arbitrary page that's (more or less) guaranteed to exist. --[[smcv]]
 
+>>>>> I don't like that [[plugins/autoindex]] has to do that,
+>>>>> but `%pagestate` values are only stored for pages that exist,
+>>>>> so it was necessary. (Another way to look at this is that
+>>>>> `%pagestate` is not the ideal data structure.) --[[Joey]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
 
-- 
cgit v1.2.3


From a70c2518af7f48036a21d04c5b4070f3ea96002c Mon Sep 17 00:00:00 2001
From: David Riebenbauer 
Date: Fri, 16 Apr 2010 18:16:47 +0200
Subject: answer to clarification.

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 1259552bf..0ae025a13 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -236,6 +236,8 @@ wrong direction.
 >>>>> so it was necessary. (Another way to look at this is that
 >>>>> `%pagestate` is not the ideal data structure.) --[[Joey]]
 
+>>>>> Ok, now I know what you mean. --[[David_Riebenbauer]]
+
 >>> * `autoindex` forgets that a page was deleted when that page is
 >>>   re-created
 
-- 
cgit v1.2.3


From 720522859806d9cf50231ed6aa28085754713701 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Fri, 16 Apr 2010 17:51:51 +0000
Subject: ... and indeed there is a better way to store it

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 0ae025a13..8fc97578c 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -236,6 +236,9 @@ wrong direction.
 >>>>> so it was necessary. (Another way to look at this is that
 >>>>> `%pagestate` is not the ideal data structure.) --[[Joey]]
 
+>>>>>> Aha! Having looked at [[plugins/write]] again, it turns out that what this
+>>>>>> feature should really use is `%wikistate`, I think? :-) --[[smcv]]
+
 >>>>> Ok, now I know what you mean. --[[David_Riebenbauer]]
 
 >>> * `autoindex` forgets that a page was deleted when that page is
-- 
cgit v1.2.3


From ff5b73163f97110e83dd777cf7e14debebf85288 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Fri, 16 Apr 2010 18:20:29 +0000
Subject: Proposal for tags/meta/field coalescing

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index eb1f58cfa..ee3bbd88d 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -51,3 +51,22 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 >> I would like to point out however that there are some functional differences between categorization metadata vs other metadata that might suggest to keep fields and (my extended) tags separate. For examples, in feeds you'd want all categorization metadata to fall in one place, with some appropriate manipulation (which I still have to implement, by the way), while things like author or title would go to the corresponding feed item properties. Although it all would be possible with appropriate report or template juggling, having such default metadata handled natively looks like a bonus to me.
 
 >>> Whereas I prefer being able to control such things with templates, because it gives more flexibility AND control. - K.A.
+
+>>>> Flexibility and control is good for tuning and power-usage, but sensible defaults are a must for a platform to be usable out of the box without much intervention. Moreover, there's a possible problem with what kind of data must be passed over to templates.
+
+Aside from the name of the plugin (and thus of the main directive), which could be `tag`, `meta`, `field` or whatever (maybe extending `meta` would be the most sensible choice), the features we want are
+
+  1. allow multiple values per type/attribute/field/whatever (fields currently only allows one)
+  2. allow both hidden and visible references (à la tag vs taglink)
+  3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
+  4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
+
+Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters:
+
+  * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
+  * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
+  * `linktype` : link type for (hidden and visible) references
+  * `linkbase` : akin to the tagbase parameter
+  * `queries` : list of template queries this type/attribute/field/whatever is exposed to
+
+Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From b14f84c4acccbc8450a9102b3b647013989b27bb Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 16 Apr 2010 17:02:29 -0400
Subject: --gettime revamp

* Rename --getctime to --gettime. (The old name still works for
  backwards compatability.)
* --gettime now also looks up last modification time.
* Add rcs_getmtime to plugin API; currently only implemented
  for git.
---
 IkiWiki.pm                                         |  8 +++++--
 IkiWiki/Plugin/bzr.pm                              |  5 +++++
 IkiWiki/Plugin/cvs.pm                              |  5 +++++
 IkiWiki/Plugin/darcs.pm                            |  5 +++++
 IkiWiki/Plugin/git.pm                              |  5 +++++
 IkiWiki/Plugin/mercurial.pm                        |  5 +++++
 IkiWiki/Plugin/monotone.pm                         |  5 +++++
 IkiWiki/Plugin/norcs.pm                            |  7 +++++-
 IkiWiki/Plugin/svn.pm                              |  5 +++++
 IkiWiki/Plugin/tla.pm                              |  5 +++++
 IkiWiki/Render.pm                                  | 18 +++++++++++++---
 debian/changelog                                   |  5 +++++
 .../How_does_ikiwiki_remember_times__63__.mdwn     | 25 ++++++----------------
 ...old_repository_to_new_ikiwiki_system__63__.mdwn |  4 ----
 doc/plugins/write.mdwn                             |  7 ++++++
 doc/rcs.mdwn                                       |  8 +++++--
 doc/tips/Importing_posts_from_Wordpress.mdwn       |  2 +-
 doc/tips/inside_dot_ikiwiki/discussion.mdwn        |  7 +++---
 doc/todo/auto_getctime_on_fresh_build.mdwn         |  8 +++++--
 doc/usage.mdwn                                     | 10 ++++-----
 ikiwiki.in                                         |  3 ++-
 mtime-to-git                                       | 14 ------------
 22 files changed, 109 insertions(+), 57 deletions(-)
 delete mode 100755 mtime-to-git

(limited to 'doc/todo')

diff --git a/IkiWiki.pm b/IkiWiki.pm
index 1730e476a..7655dada5 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -440,10 +440,10 @@ sub getsetup () {
 		safe => 0,
 		rebuild => 0,
 	},
-	getctime => {
+	gettime => {
 		type => "internal",
 		default => 0,
-		description => "running in getctime mode",
+		description => "running in gettime mode",
 		safe => 0,
 		rebuild => 0,
 	},
@@ -1790,6 +1790,10 @@ sub rcs_getctime ($) {
 	$hooks{rcs}{rcs_getctime}{call}->(@_);
 }
 
+sub rcs_getmtime ($) {
+	$hooks{rcs}{rcs_getmtime}{call}->(@_);
+}
+
 sub rcs_receive () {
 	$hooks{rcs}{rcs_receive}{call}->();
 }
diff --git a/IkiWiki/Plugin/bzr.pm b/IkiWiki/Plugin/bzr.pm
index 0efc26b49..f79ca7c8f 100644
--- a/IkiWiki/Plugin/bzr.pm
+++ b/IkiWiki/Plugin/bzr.pm
@@ -20,6 +20,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -306,4 +307,8 @@ sub rcs_getctime ($) {
 	return $ctime;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for bzr\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/cvs.pm b/IkiWiki/Plugin/cvs.pm
index 26a3e9dd2..360d97249 100644
--- a/IkiWiki/Plugin/cvs.pm
+++ b/IkiWiki/Plugin/cvs.pm
@@ -49,6 +49,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub genwrapper () {
@@ -485,4 +486,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for cvs\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/darcs.pm b/IkiWiki/Plugin/darcs.pm
index bc8394b90..c1d6661d3 100644
--- a/IkiWiki/Plugin/darcs.pm
+++ b/IkiWiki/Plugin/darcs.pm
@@ -18,6 +18,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub silentsystem (@) {
@@ -427,4 +428,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for darcs\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm
index b02f4a5ed..86d80186f 100644
--- a/IkiWiki/Plugin/git.pm
+++ b/IkiWiki/Plugin/git.pm
@@ -25,6 +25,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 	hook(type => "rcs", id => "rcs_receive", call => \&rcs_receive);
 }
 
@@ -634,6 +635,10 @@ sub rcs_getctime ($) {
 	return $ctime;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for git\n"; # TODO
+}
+
 sub rcs_receive () {
 	# The wiki may not be the only thing in the git repo.
 	# Determine if it is in a subdirectory by examining the srcdir,
diff --git a/IkiWiki/Plugin/mercurial.pm b/IkiWiki/Plugin/mercurial.pm
index ea00a3364..34e009c7a 100644
--- a/IkiWiki/Plugin/mercurial.pm
+++ b/IkiWiki/Plugin/mercurial.pm
@@ -20,6 +20,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -254,4 +255,8 @@ sub rcs_getctime ($) {
 	return $ctime;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for mercurial\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/monotone.pm b/IkiWiki/Plugin/monotone.pm
index c33cf7e3a..67d4abbaa 100644
--- a/IkiWiki/Plugin/monotone.pm
+++ b/IkiWiki/Plugin/monotone.pm
@@ -23,6 +23,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -693,4 +694,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for monotone\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/norcs.pm b/IkiWiki/Plugin/norcs.pm
index e6a05a3c5..053652a5f 100644
--- a/IkiWiki/Plugin/norcs.pm
+++ b/IkiWiki/Plugin/norcs.pm
@@ -18,6 +18,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub getsetup () {
@@ -63,7 +64,11 @@ sub rcs_diff ($) {
 }
 
 sub rcs_getctime ($) {
-	error gettext("getctime not implemented");
+	return 0;
+}
+
+sub rcs_getmtime ($) {
+	return 0;
 }
 
 1
diff --git a/IkiWiki/Plugin/svn.pm b/IkiWiki/Plugin/svn.pm
index 7d27ec842..85c205f09 100644
--- a/IkiWiki/Plugin/svn.pm
+++ b/IkiWiki/Plugin/svn.pm
@@ -19,6 +19,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -379,4 +380,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for svn\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Plugin/tla.pm b/IkiWiki/Plugin/tla.pm
index 764da9b98..f5ad0cc96 100644
--- a/IkiWiki/Plugin/tla.pm
+++ b/IkiWiki/Plugin/tla.pm
@@ -18,6 +18,7 @@ sub import {
 	hook(type => "rcs", id => "rcs_recentchanges", call => \&rcs_recentchanges);
 	hook(type => "rcs", id => "rcs_diff", call => \&rcs_diff);
 	hook(type => "rcs", id => "rcs_getctime", call => \&rcs_getctime);
+	hook(type => "rcs", id => "rcs_getmtime", call => \&rcs_getmtime);
 }
 
 sub checkconfig () {
@@ -284,4 +285,8 @@ sub rcs_getctime ($) {
 	return $date;
 }
 
+sub rcs_getmtime ($) {
+	error "rcs_getmtime is not implemented for tla\n"; # TODO
+}
+
 1
diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm
index e98888d76..e1cb68462 100644
--- a/IkiWiki/Render.pm
+++ b/IkiWiki/Render.pm
@@ -365,14 +365,26 @@ sub find_new_files ($) {
 			}
 			else {
 				push @new, $file;
-				if ($config{getctime} && -e "$config{srcdir}/$file") {
+				if ($config{gettime} && -e "$config{srcdir}/$file") {
 					eval {
-						my $time=rcs_getctime("$config{srcdir}/$file");
-						$pagectime{$page}=$time;
+						my $ctime=rcs_getctime("$config{srcdir}/$file");
+						if ($ctime > 0) {
+							$pagectime{$page}=$ctime;
+						}
 					};
 					if ($@) {
 						print STDERR $@;
 					}
+					my $mtime;
+					eval {
+						my $mtime=rcs_getmtime("$config{srcdir}/$file");
+					};
+					if ($@) {
+						print STDERR $@;
+					}
+					elsif ($mtime > 0) {
+						utime($mtime, $mtime, "$config{srcdir}/$file");
+					}
 				}
 			}
 			$pagecase{lc $page}=$page;
diff --git a/debian/changelog b/debian/changelog
index 737d73655..615d5916f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -44,6 +44,11 @@ ikiwiki (3.20100415) UNRELEASED; urgency=low
   * conditional: Fix bug that forced "all" mode off by default.
   * calendarmonth.tmpl: The month calendar is now put in a sidebar.
   * calendar: Improved display of arrows.
+  * Rename --getctime to --gettime. (The old name still works for
+    backwards compatability.)
+  * --gettime now also looks up last modification time.
+  * Add rcs_getmtime to plugin API; currently only implemented
+    for git.
 
  -- Joey Hess   Sun, 04 Apr 2010 12:17:11 -0400
 
diff --git a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
index 6ce576db1..6b7739fd0 100644
--- a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
+++ b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
@@ -20,15 +20,17 @@ Do I have it right?
 > Some VCS, like git, set the file mtimes to the current time
 > when making a new checkout, so they will be lost if you do that.
 > The creation times can be retrived using the `--getctime` option.
-> I suppose it might be nice if there were a `--getmtime` that pulled
-> true modification times out of the VCS, but I haven't found it a big
-> deal in practice for the last modification times to be updated to the
-> current time when rebuilding a wiki like this. --[[Joey]] 
+> --[[Joey]] 
 >
 > > Thanks for the clarification. I ran some tests of my own to make sure I understand it right, and I'm satisfied
 > > that the order of posts in my blog can be retrieved from the VCS using the `--getctime` option, at least if I
 > > choose to order my posts by creation time rather than modification time. But I now know that I can't rely on
 > > page modification times in ikiwiki as these can be lost permanently.
+> 
+> > > Update: It's now renamed to `--gettime`, and pulls both the creation
+> > > and modification times. Also, per [[todo/auto_getctime_on_fresh_build]],
+> > > this is now done automatically the first time ikiwiki builds a
+> > > srcdir. So, no need to worry about this any more! --[[Joey]] 
 > >
 > > I would suggest that there should at least be a `--getmtime` option like you describe, and perhaps that 
 > > `--getctime` and `--getmtime` be _on by default_. In my opinion the creation times and modification times of 
@@ -91,19 +93,6 @@ Do I have it right?
 > A quick workaround for me to get modification times right is the following
 > little zsh script, which unfortunately only works for git:
 
-    #!/usr/bin/env zsh
-    
-    set +x
-    
-    for FILE in **/*(.); do
-      TIMES="`git log --pretty=format:%ai $FILE`"
-      MTIME="`echo $TIMES | head -n1`"
-    
-      if [ ! -z $MTIME ]; then
-        echo  touch -m -d "$MTIME" $FILE
-        touch -m -d "$MTIME" $FILE
-      fi
-    
-    done
+>> Elided; no longer needed since --gettime does that, and much faster! --[[Joey]] 
 
 > --[[David_Riebenbauer]]
diff --git a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
index fe67e6aba..d7a33b526 100644
--- a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
+++ b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
@@ -20,10 +20,6 @@ How do I set up an ikiwiki system using a pre-existing repository (instead of cr
 >    recreate the ikiwiki srcdir
 > 3. `git clone` from the bare git repository a second time,
 >    to create a checkout you can manually edit (optional)
-> 4. run `ikiwiki --getctime --setup your.setup`
->    The getctime will ensure page creation times are accurate
->    by putting the info out of the git history,
->    and only needs to be done once.
 >
 > If you preserved your repository, but not the setup file,
 > the easiest way to make one is probably to run
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 707622956..cf7044b2c 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -1085,6 +1085,13 @@ it up in the history.
 
 It's ok if this is not implemented, and throws an error.
 
+#### `rcs_getmtime($)`
+
+This is used to get the page modification time for a file from the RCS, by
+looking it up in the history.
+
+It's ok if this is not implemented, and throws an error.
+
 #### `rcs_receive()`
 
 This is called when ikiwiki is running as a pre-receive hook (or
diff --git a/doc/rcs.mdwn b/doc/rcs.mdwn
index 4e7a8d2a6..b5bfc2414 100644
--- a/doc/rcs.mdwn
+++ b/doc/rcs.mdwn
@@ -14,8 +14,10 @@ use, some advanced or special features are not supported in all of them.
 Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to
 set up a wiki using that revision control system. The `rcs_commit_staged`
 hook is needed to use [[attachments|plugins/attachment]] or
-[[plugins/comments]]. And so on. The table below summarises this for each
-revision control system and links to more information about each.
+[[plugins/comments]]. `rcs_getctime` may be implemented in a fast way
+(ie, one log lookup for all files), or very slowly (one lookup per file).
+And so on. The table below summarises this for each revision control
+system and links to more information about each.
 
 [[!table data="""
 feature             |[[git]]|[[svn]]|[[bzr]]   |[[monotone]]|[[mercurial]]|[[darcs]]|[[tla]]   |[[cvs]]
@@ -25,6 +27,8 @@ auto.setup          |yes    |yes    |incomplete|yes         |incomplete   |yes
 `rcs_rename`        |yes    |yes    |yes       |yes         |no           |yes      |no        |yes
 `rcs_remove`        |yes    |yes    |yes       |yes         |no           |yes      |no        |yes
 `rcs_diff`          |yes    |yes    |yes       |yes         |no           |yes      |yes       |yes
+`rcs_getctime`      |fast   |slow   |slow      |slow        |slow         |slow     |slow      |slow
+`rcs_getmtime`      |fast   |no     |no        |no          |no           |no       |no        |no
 anonymous push      |yes    |no     |no        |no          |no           |no       |no        |no
 conflict handling   |yes    |yes    |yes       |buggy       |yes          |yes      |yes       |yes
 """]]
diff --git a/doc/tips/Importing_posts_from_Wordpress.mdwn b/doc/tips/Importing_posts_from_Wordpress.mdwn
index 59330caa4..8774c9723 100644
--- a/doc/tips/Importing_posts_from_Wordpress.mdwn
+++ b/doc/tips/Importing_posts_from_Wordpress.mdwn
@@ -1,6 +1,6 @@
 Use case: You want to move away from Wordpress to Ikiwiki as your blogging/website platform, but you want to retain your old posts.
 
-[This](http://git.chris-lamb.co.uk/?p=ikiwiki-wordpress-import.git) is a simple tool that generates [git-fast-import](http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html)-compatible data from a WordPress export XML file. It retains creation time of each post, so you can use Ikiwiki's --getctime to get the preserve creation times on checkout. 
+[This](http://git.chris-lamb.co.uk/?p=ikiwiki-wordpress-import.git) is a simple tool that generates [git-fast-import](http://www.kernel.org/pub/software/scm/git/docs/git-fast-import.html)-compatible data from a WordPress export XML file. It retains creation time of each post, so you can use Ikiwiki's --gettime to get the preserve creation times on checkout. 
 
 WordPress categories are mapped onto Ikiwiki tags. The ability to import comments is planned.
 
diff --git a/doc/tips/inside_dot_ikiwiki/discussion.mdwn b/doc/tips/inside_dot_ikiwiki/discussion.mdwn
index 34d5b9252..69df369ec 100644
--- a/doc/tips/inside_dot_ikiwiki/discussion.mdwn
+++ b/doc/tips/inside_dot_ikiwiki/discussion.mdwn
@@ -6,14 +6,15 @@ My database appears corrupted:
 No idea how this happened.  I've blown it away and recreated it but, for future reference, is there any less violent way to recover from this situation?  I miss having the correct created and last edited times.  --[[sabr]]
 > update: fixed ctimes and mtimes using [these instructions](http://u32.net/Mediawiki_Conversion/Git_Import/#Correct%20Creation%20and%20Last%20Edited%20time) --[[sabr]]
 
-> That's overly complex. Just run `ikiwiki -setup your.setup -getctime`. 
+> That's overly complex. Just run `ikiwiki -setup your.setup -gettime`. 
 > BTW, I'd be interested in examining such a corrupt storable file to try
 > to see what happened to it. --[[Joey]]
 
->> --getctime appears to only set the last edited date.  It's not supposed to set the creation date, is it?  The only place that info is stored is in the git repo.
+>> --gettime appears to only set the last edited date.  It's not supposed to set the creation date, is it?  The only place that info is stored is in the git repo.
 
 >>> Pulling the page creation date out of the git history is exactly what
->>> --getctime does. --[[Joey]]
+>>> --gettime does. (It used to be called --getctime, and only do that; now
+>>> it also pulls out the last modified date). --[[Joey]]
 
 >> Alas, I seem to have lost the bad index file to periodic /tmp wiping; I'll send it to you if it happens again.  --[[sabr]]
 
diff --git a/doc/todo/auto_getctime_on_fresh_build.mdwn b/doc/todo/auto_getctime_on_fresh_build.mdwn
index ea95fb8c9..760c56fa1 100644
--- a/doc/todo/auto_getctime_on_fresh_build.mdwn
+++ b/doc/todo/auto_getctime_on_fresh_build.mdwn
@@ -1,9 +1,13 @@
 [[!tag wishlist]]
 
-It might be a good idea to enable --getctime when `.ikiwiki` does not
+It might be a good idea to enable --gettime when `.ikiwiki` does not
 exist. This way a new checkout of a `srcdir` would automatically get
-ctimes right. (Running --getctime whenever a rebuild is done would be too
+ctimes right. (Running --gettime whenever a rebuild is done would be too
 slow.) --[[Joey]] 
 
 Could this be too annoying in some cases, eg, checking out a large wiki
 that needs to get set up right away? --[[Joey]] 
+
+> Not for git with the new, optimised --getctime. For other VCS.. well,
+> pity they're not as fast as git ;), but it is a one-time expense...
+> [[done]] --[[Joey]]
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index db1e36a10..553fef01e 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -320,13 +320,11 @@ also be configured using a setup file.
   intercepted. If you enable this option then you must run at least the 
   CGI portion of ikiwiki over SSL.
 
-* --getctime
+* --gettime
 
-  Pull creation time for each new page out of the revision control
-  system. This rarely used option provides a way to get the real creation
-  times of items in weblogs, such as when building a wiki from a new
-  VCS checkout. It is unoptimised and quite slow. It is best used
-  with --rebuild, to force ikiwiki to get the ctime for all pages.
+  Extract creation and modification times for each new page from the
+  the revision control's log. This is done automatically when building a
+  wiki for the first time, so you normally do not need to use this option.
 
 * --set var=value
   
diff --git a/ikiwiki.in b/ikiwiki.in
index 38e4d3201..801ff9a0b 100755
--- a/ikiwiki.in
+++ b/ikiwiki.in
@@ -44,7 +44,8 @@ sub getconfig () {
 			"wrappergroup=s" => \$config{wrappergroup},
 			"usedirs!" => \$config{usedirs},
 			"prefix-directives!" => \$config{prefix_directives},
-			"getctime" => \$config{getctime},
+			"getctime" => \$config{gettime},
+			"gettime" => \$config{gettime},
 			"numbacklinks=i" => \$config{numbacklinks},
 			"rcs=s" => \$config{rcs},
 			"no-rcs" => sub { $config{rcs}="" },
diff --git a/mtime-to-git b/mtime-to-git
deleted file mode 100755
index 9875af5d7..000000000
--- a/mtime-to-git
+++ /dev/null
@@ -1,14 +0,0 @@
-#!/bin/sh
-# Sets mtimes of all files in the tree their last change date
-# based on git's log. Useful to avoid too new dates after a
-# fresh checkout, which lead to ikiwiki unnecessarily rebuilding
-# basewiki files on upgrade.
-if [ -d .git ]; then
-	for file in $(git ls-files); do
-		date="$(git log -1 --date=rfc "$file" | grep ^Date: | sed -e 's/Date://')"
-		if [ -n "$date" ]; then
-			echo "$date $file"
-			touch -d"$date" $file
-		fi
-	done
-fi
-- 
cgit v1.2.3


From c769a33392c4dedbabfb1fa1fda5c8bb30b84c78 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 12:20:50 -0400
Subject: autoindex: Switch to using %wikistate instead of abusing
 $pagestate{index}.

---
 IkiWiki/Plugin/autoindex.pm                          | 20 ++++++++++++++------
 debian/changelog                                     |  2 ++
 ...uto-create_tag_pages_according_to_a_template.mdwn |  3 +++
 3 files changed, 19 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/autoindex.pm b/IkiWiki/Plugin/autoindex.pm
index 555856b11..c71d73349 100644
--- a/IkiWiki/Plugin/autoindex.pm
+++ b/IkiWiki/Plugin/autoindex.pm
@@ -61,8 +61,16 @@ sub refresh () {
 	}
 	
 	my %deleted;
-        if (ref $pagestate{index}{autoindex}{deleted}) {
-	       %deleted=%{$pagestate{index}{autoindex}{deleted}};
+	if (ref $wikistate{autoindex}{deleted}) {
+		%deleted=%{$wikistate{autoindex}{deleted}};
+	}
+        elsif (ref $pagestate{index}{autoindex}{deleted}) {
+		# compatability code
+		%deleted=%{$pagestate{index}{autoindex}{deleted}};
+		delete $pagestate{index}{autoindex};
+	}
+
+	if (keys %deleted) {
 		foreach my $dir (keys %deleted) {
 			# remove deleted page state if the deleted page is re-added,
 			# or if all its subpages are deleted
@@ -71,7 +79,7 @@ sub refresh () {
 				delete $deleted{$dir};
 			}
 		}
-		$pagestate{index}{autoindex}{deleted}=\%deleted;
+		$wikistate{autoindex}{deleted}=\%deleted;
 	}
 
 	my @needed;
@@ -82,10 +90,10 @@ sub refresh () {
 				# This page must have just been deleted, so
 				# don't re-add it. And remember it was
 				# deleted.
-				if (! ref $pagestate{index}{autoindex}{deleted}) {
-					$pagestate{index}{autoindex}{deleted}={};
+				if (! ref $wikistate{autoindex}{deleted}) {
+					$wikistate{autoindex}{deleted}={};
 				}
-				${$pagestate{index}{autoindex}{deleted}}{$dir}=1;
+				${$wikistate{autoindex}{deleted}}{$dir}=1;
 			}
 			else {
 				push @needed, $dir;
diff --git a/debian/changelog b/debian/changelog
index d65ffffd7..4721c5309 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -58,6 +58,8 @@ ikiwiki (3.20100415) UNRELEASED; urgency=low
     an iffy thing.
   * Use above to fix up timestamps on docwiki, as well as ensure that
     timestamps on basewiki files shipped in the deb are sane.
+  * autoindex: Switch to using %wikistate instead of abusing
+    $pagestate{index}.
 
  -- Joey Hess   Sun, 04 Apr 2010 12:17:11 -0400
 
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 8fc97578c..49da3c80c 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -239,6 +239,9 @@ wrong direction.
 >>>>>> Aha! Having looked at [[plugins/write]] again, it turns out that what this
 >>>>>> feature should really use is `%wikistate`, I think? :-) --[[smcv]]
 
+>>>>>>> Ah, indeed, that came after I wrote autoindex. I've fixed autoindex to
+>>>>>>> use it. --[[Joey]]
+
 >>>>> Ok, now I know what you mean. --[[David_Riebenbauer]]
 
 >>> * `autoindex` forgets that a page was deleted when that page is
-- 
cgit v1.2.3


From 7fcc0faf8367c5ae64a3ff06d0d74baa063c4dfc Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 12:45:20 -0400
Subject: few more suggestions

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 9 +++++++++
 1 file changed, 9 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 49da3c80c..def55f3ee 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -269,6 +269,15 @@ wrong direction.
 
 >> True. I'll do that. --[[David_Riebenbauer]]
 
+> Seems that `%autofiles` stores plugin names as keys, but never
+> really uses them. So it could just as easily be an array.
+> 
+> I'd be happy if the `%del_hash` global were not needed. 
+> Looks like it could be avoided by moving the checks
+> that `add_autofile` does into the autofile handling loop in
+> `Render`. (Also, that loop should probably be in its own
+> function anyway.) --[[Joey]] 
+
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
 [f58f3e1bec41ccf9316f37b014ce0b373c8e49e1]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f58f3e1bec41ccf9316f37b014ce0b373c8e49e1 (commitdiff for f58f3e1bec41ccf9316f37b014ce0b373c8e49e1)
-- 
cgit v1.2.3


From c721a9ef872db85b26d430a2098234a4fca6ec51 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 13:41:06 -0400
Subject: my autotag branch

---
 .../auto-create_tag_pages_according_to_a_template.mdwn     | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index def55f3ee..867306f0d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -269,14 +269,12 @@ wrong direction.
 
 >> True. I'll do that. --[[David_Riebenbauer]]
 
-> Seems that `%autofiles` stores plugin names as keys, but never
-> really uses them. So it could just as easily be an array.
-> 
-> I'd be happy if the `%del_hash` global were not needed. 
-> Looks like it could be avoided by moving the checks
-> that `add_autofile` does into the autofile handling loop in
-> `Render`. (Also, that loop should probably be in its own
-> function anyway.) --[[Joey]] 
+>> I've pushed an autotag branch of my own, which refactors
+>> things a bit. It is untested so far though. --[[Joey]]
+>>
+>> * `verify_src_file` only called from Render.pm
+>> * Gets rid of `%del_files`.
+>> * Uses `%wikistate`.
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 9fbef7e1d2c4e8bbaf3eaf89885f18b88edbe429 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 17 Apr 2010 13:42:50 -0400
Subject: reformat

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 867306f0d..ed681ac4d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -269,12 +269,13 @@ wrong direction.
 
 >> True. I'll do that. --[[David_Riebenbauer]]
 
->> I've pushed an autotag branch of my own, which refactors
->> things a bit. It is untested so far though. --[[Joey]]
->>
->> * `verify_src_file` only called from Render.pm
->> * Gets rid of `%del_files`.
->> * Uses `%wikistate`.
+[[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
+I've pushed an autotag branch of my own, which refactors
+things a bit. It is untested so far though. --[[Joey]]
+
+* `verify_src_file` only called from Render.pm
+* Gets rid of `%del_files`.
+* Uses `%wikistate`.
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 63e6c00890a11144f8d035f7052a6229227fce52 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Mon, 19 Apr 2010 02:23:12 +0000
Subject: response to the further thoughts

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 26 ++++++++++++++++--------
 1 file changed, 17 insertions(+), 9 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index ee3bbd88d..1861d860c 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -56,17 +56,25 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit
 
 Aside from the name of the plugin (and thus of the main directive), which could be `tag`, `meta`, `field` or whatever (maybe extending `meta` would be the most sensible choice), the features we want are
 
-  1. allow multiple values per type/attribute/field/whatever (fields currently only allows one)
-  2. allow both hidden and visible references (à la tag vs taglink)
-  3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
-  4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
+1. allow multiple values per type/attribute/field/whatever (fields currently only allows one)
+   * Agreed about multiple values; I've been considering whether I should add that to `field`. -- K.A.
+2. allow both hidden and visible references (a la tag vs taglink)
+   * Hidden and visible references; that's fair enough too.  My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A.
+3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
+   * I'm not sure what you mean here. -- K.A.
+4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
+   * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A.
 
 Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters:
 
-  * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
-  * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
-  * `linktype` : link type for (hidden and visible) references
-  * `linkbase` : akin to the tagbase parameter
-  * `queries` : list of template queries this type/attribute/field/whatever is exposed to
+* `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
+  * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A.
+* `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
+* `linktype` : link type for (hidden and visible) references
+  * Is this the equivalent to "field name"? -- K.A.
+* `linkbase` : akin to the tagbase parameter
+  * Is this a field-name -> directory mapping? -- K.A.
+* `queries` : list of template queries this type/attribute/field/whatever is exposed to
+  * I'm not sure what you mean here. -- K.A.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From 99cdd38dd54047d0e79dbf65d58ba11ee38f2c92 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Mon, 19 Apr 2010 08:36:38 +0000
Subject: Respond

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 1861d860c..ae35e8dfe 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -62,19 +62,25 @@ Aside from the name of the plugin (and thus of the main directive), which could
    * Hidden and visible references; that's fair enough too.  My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A.
 3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too)
    * I'm not sure what you mean here. -- K.A.
+     * Typical example is tags: they are accessible both as `tags` and as `categories`, although the way they are presented changes a little -- G.B.
 4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones)
    * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A.
+     * I am saying that the user should be able to define (e.g. in the config) some set of types/fields/attributes/whatever, following the specification illustrated below, but also be able to use something like `\[[!meta somefield="somevalue"]]` where `somefield` was never defined before. In this case `somefield` will have some default values for the properties described in the spec below. -- G.B.
 
 Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters:
 
 * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined.
   * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A.
+     * The possibility to use a directive does not preclude other ways of defining the field values. IOW, even if the directive `somefield` is defined, the user would still be able to use the syntax `\[[!meta somefield="somevalue"]]`, or any other syntax (such as YAML). -- G.B.
 * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default
 * `linktype` : link type for (hidden and visible) references
   * Is this the equivalent to "field name"? -- K.A.
+     * This would be such by default, but it could be set to something different. [[Typed links|matching_different_kinds_of_links]] is a very recent ikiwiki feature. -- G.B.
 * `linkbase` : akin to the tagbase parameter
   * Is this a field-name -> directory mapping? -- K.A.
+     * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
+     * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
 
-Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
+Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From 1b7c455f4a4214bc9df766be4ec2b12adcf679e1 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 19 Apr 2010 16:03:53 -0400
Subject: thinking about changing how templatedir works and allowing
 wikitemplate files into the srcdir

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 33 +++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)
 create mode 100644 doc/todo/auto_rebuild_on_template_change.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
new file mode 100644
index 000000000..c4ffae178
--- /dev/null
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -0,0 +1,33 @@
+If `page.tmpl` is changed, it would be nice if ikiwiki automatically
+noticed, and rebuilt all pages. If `inlinepage.tmpl` is changed, a rebuild
+of all pages using it in an inline would be stellar.
+
+This would allow setting:
+
+	templatedir => "$srcdir/templates",
+
+.. and then the [[wikitemplates]] are managed like other wiki files; and
+like other wiki files, a change to them automatically updates dependent
+pages.
+
+Originally, it made good sense not to have the templatedir inside the wiki.
+Those templates can be used to bypass the htmlscrubber, and you don't want
+just anyone to edit them. But the same can be said of `style.css` and
+`ikiwiki.js`, which *are* in the wiki. We rely on `allowed_attachments`
+being set to secure those to prevent users uploading replacements. And we
+assume that users who can directly (non-anon) commit *can* edit them, and
+that's ok.
+
+So, perhaps the easiest way to solve this [[wishlist]] would be to
+make templatedir *default* to "$srcdir/templates/, and make ikiwiki
+register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're
+used. Although, having every page declare an explicit dep on `page.tmpl`
+is perhaps a bit much; might be better to implement a special case for that
+one. Also, having the templates be copied to `destdir` is not desirable.
+
+The risk is that a site might have `allowed_attachments` set to "templates/*"
+or "*.tmpl" something like that. I think such a configuration is the *only*
+risk, and it's unlikely enough that a NEWS warning should suffice.
+
+(This would also help to clear up the tricky disctinction between
+wikitemplates and in-wiki templates.)
-- 
cgit v1.2.3


From 09c647c1773d5c8eafacea486082684909e47449 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:31:00 +0000
Subject: response

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index c4ffae178..2799842ed 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -31,3 +31,5 @@ risk, and it's unlikely enough that a NEWS warning should suffice.
 
 (This would also help to clear up the tricky disctinction between
 wikitemplates and in-wiki templates.)
+
+> But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
-- 
cgit v1.2.3


From 9f00692a798888b9cc9edb30a961c6418efba39b Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 19 Apr 2010 22:37:55 -0400
Subject: response

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 2799842ed..cde19700c 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -25,11 +25,15 @@ used. Although, having every page declare an explicit dep on `page.tmpl`
 is perhaps a bit much; might be better to implement a special case for that
 one. Also, having the templates be copied to `destdir` is not desirable.
 
-The risk is that a site might have `allowed_attachments` set to "templates/*"
-or "*.tmpl" something like that. I think such a configuration is the *only*
-risk, and it's unlikely enough that a NEWS warning should suffice.
+The risk is that a site might have `allowed_attachments` set to
+`templates/*` or `*.tmpl` something like that. I think such a configuration
+is the *only* risk, and it's unlikely enough that a NEWS warning should
+suffice.
 
 (This would also help to clear up the tricky disctinction between
 wikitemplates and in-wiki templates.)
 
 > But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
+
+>> It would be better for them not to be rendered separately at all.
+>> --[[Joey]]  
-- 
cgit v1.2.3


From 16afa9e8446771fabe45ab45d8a36d09034d0319 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:41:13 +0000
Subject: further clarification

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index ae35e8dfe..190070816 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -79,8 +79,10 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t
 * `linkbase` : akin to the tagbase parameter
   * Is this a field-name -> directory mapping? -- K.A.
      * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
+       * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
      * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
+       * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From fda191cbbbfa76114a27a53bfc5b90289f26f72b Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:43:44 +0000
Subject: formatting

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 190070816..74e5bc812 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -79,10 +79,10 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t
 * `linkbase` : akin to the tagbase parameter
   * Is this a field-name -> directory mapping? -- K.A.
      * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
-       * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
+         * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
      * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
-       * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
+         * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
-- 
cgit v1.2.3


From 529929e732e1c6604d31b68e81898780de06e640 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Tue, 20 Apr 2010 02:45:14 +0000
Subject: non comprend

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index cde19700c..6a1013f8d 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -37,3 +37,5 @@ wikitemplates and in-wiki templates.)
 
 >> It would be better for them not to be rendered separately at all.
 >> --[[Joey]]  
+
+>>> I don't follow you. --[[KathrynAndersen]]
-- 
cgit v1.2.3


From 563428ebd2a75cfabccf1974da0c1cbbe07eb369 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Mon, 19 Apr 2010 23:52:16 -0400
Subject: response

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 6a1013f8d..2558d5f3e 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -24,6 +24,7 @@ register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're
 used. Although, having every page declare an explicit dep on `page.tmpl`
 is perhaps a bit much; might be better to implement a special case for that
 one. Also, having the templates be copied to `destdir` is not desirable.
+(However, if they're not copied, wikilinks to them will be broken. Hmm.)
 
 The risk is that a site might have `allowed_attachments` set to
 `templates/*` or `*.tmpl` something like that. I think such a configuration
@@ -39,3 +40,8 @@ wikitemplates and in-wiki templates.)
 >> --[[Joey]]  
 
 >>> I don't follow you. --[[KathrynAndersen]]
+
+>>>> If they don't render to output files, they clearly don't
+>>>> need to be treated as wiki pages. (They need to be treated
+>>>> as raw files anyway, because you don't want random users editing them 
+>>>> in the online editor.) --[[Joey]] 
-- 
cgit v1.2.3


From 11718519348382892d5c6fdb21b8e721c2413eb0 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Tue, 20 Apr 2010 01:32:19 -0400
Subject: similarity to internal pages

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 2558d5f3e..2e4ba8e9a 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -24,7 +24,8 @@ register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're
 used. Although, having every page declare an explicit dep on `page.tmpl`
 is perhaps a bit much; might be better to implement a special case for that
 one. Also, having the templates be copied to `destdir` is not desirable.
-(However, if they're not copied, wikilinks to them will be broken. Hmm.)
+In a sense, these template would be like internal pages, except not wiki
+pages, but raw files.
 
 The risk is that a site might have `allowed_attachments` set to
 `templates/*` or `*.tmpl` something like that. I think such a configuration
-- 
cgit v1.2.3


From 52ccc03d10c532b3cf6335b00a9b60057061596b Mon Sep 17 00:00:00 2001
From: Jon Dowland 
Date: Tue, 20 Apr 2010 15:40:10 +0100
Subject: clarify whether the raw files would be put in destdir

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 2e4ba8e9a..09a623427 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -46,3 +46,6 @@ wikitemplates and in-wiki templates.)
 >>>> need to be treated as wiki pages. (They need to be treated
 >>>> as raw files anyway, because you don't want random users editing them 
 >>>> in the online editor.) --[[Joey]] 
+
+>>>>> Just to be clear, the raw files would not be copied across to the output
+>>>>> directory? -- [[Jon]]
-- 
cgit v1.2.3


From 3b8f4f59d6720e5a77cae30eacc4c46582b1603b Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Tue, 20 Apr 2010 15:01:39 +0000
Subject: internal pages: the revenge?

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 09a623427..b5c107915 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -49,3 +49,9 @@ wikitemplates and in-wiki templates.)
 
 >>>>> Just to be clear, the raw files would not be copied across to the output
 >>>>> directory? -- [[Jon]]
+
+>>>>>> Without modifying ikiwiki, they'd be copied to the output directory as
+>>>>>> (e.g.) http://ikiwiki.info/templates/inlinepage.tmpl; to not copy them,
+>>>>>> it'd either be necessary to make them be internal pages
+>>>>>> (templates/inlinepage._tmpl) or special-case them in some other way.
+>>>>>> --[[smcv]]
-- 
cgit v1.2.3


From 4b4fdc85abba7200eed78eb473341e44fecc6087 Mon Sep 17 00:00:00 2001
From: "http://oblomov.myopenid.com/" 
Date: Tue, 20 Apr 2010 20:18:29 +0000
Subject: Clarifications

---
 doc/todo/Multiple_categorization_namespaces.mdwn | 5 +++++
 1 file changed, 5 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn
index 74e5bc812..a8ee6755c 100644
--- a/doc/todo/Multiple_categorization_namespaces.mdwn
+++ b/doc/todo/Multiple_categorization_namespaces.mdwn
@@ -80,9 +80,14 @@ Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would t
   * Is this a field-name -> directory mapping? -- K.A.
      * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B.
          * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name.  Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A.
+             * that's the idea. In your case you could have the linkbase of genre be fiction/genre, and it would be created if it was missing. -- G.B.
 * `queries` : list of template queries this type/attribute/field/whatever is exposed to
   * I'm not sure what you mean here. -- K.A.
      * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B.
          * Ah, do you mean that the input value is the same, but the output format is different?  Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A.
+              * Actually this is about the same information appearing in different queries (e.g. NAME="FOO" and NAME="BAR"). Example: say that I defined a "Rubrica" field. I would want both tags and categories to appear in `categories` template query, but only tags would appear in the `tags` query, and only Rubrica values to appear in `rubrica` queries. The issue of different output formats was presented in the next paragraph instead. -- G.B.
 
 Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome.
+
+One possibility could be to have the `queries` configuration allow a hash mapping query names to functions that would transform the data. Lacking that possibility, we might have to leave some predefined fields to have custom Perl-side treatment and leave custom fields to be untransformable.
+
-- 
cgit v1.2.3


From 9fa5f71034497043e2b5dbb2c40417aebd94e327 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 15:18:11 -0400
Subject: update; my branch is (partially) debugged now

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index ed681ac4d..63bcabaee 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -273,7 +273,7 @@ wrong direction.
 I've pushed an autotag branch of my own, which refactors
 things a bit. It is untested so far though. --[[Joey]]
 
-* `verify_src_file` only called from Render.pm
+* `verify_src_file` only called from Render.pm (actually, function removed)
 * Gets rid of `%del_files`.
 * Uses `%wikistate`.
 
-- 
cgit v1.2.3


From e3ea28f8c7fb9682d9e5bea32de835cee7605846 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 15:53:44 -0400
Subject: update, tag deletion bug

---
 ...uto-create_tag_pages_according_to_a_template.mdwn | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 63bcabaee..d7637ef1b 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -152,12 +152,12 @@ consider this a feature, not a bug)
 Todo/Bugs:
 
 * Will still create a page even if there's a page other than `$tag` under
-`tagbase` satisfying the tag link.
+`tagbase` satisfying the tag link. (details? --[[Joey]])
 * Call from `IkiWiki.pm` to `Render.pm`, which adds a module dependency in the
-wrong direction.
+wrong direction. (fixed --[[Joey]] )
 * Add files to RCS.
 * Unit tests.
-* Proper documentation.
+* Proper documentation. (fixed (mostly) --[[Joey]])
 
 --[[David_Riebenbauer]]
 
@@ -273,9 +273,17 @@ wrong direction.
 I've pushed an autotag branch of my own, which refactors
 things a bit. It is untested so far though. --[[Joey]]
 
-* `verify_src_file` only called from Render.pm (actually, function removed)
-* Gets rid of `%del_files`.
-* Uses `%wikistate`.
+---
+
+Known bugs in my branch (probably also in David's):
+
+* Does not remember that a tag was deleted.
+  
+  The code to do that only works if, at the same time the tag
+  is deleted, one of the pages that has the tag is modified.
+  That's because `add_autofile` needs to be called before it's
+  aware the autofile exists, and if it's not aware, it does not
+  record it as a deleted autofile.
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 6a30b45e7521f98a3e94b04ff46eeeb7f80774ca Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:07:23 -0400
Subject: update

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 28 ++++++++++++----------
 1 file changed, 15 insertions(+), 13 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index d7637ef1b..f10c2cdee 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -250,6 +250,12 @@ wrong direction. (fixed --[[Joey]] )
 >>>> Yes, I forgot about that and that is a bug. I'll fix that.
 >>>> --[[David_Riebenbauer]]
 
+>>>>> In my branch, it keeps a list of autofiles that were created,
+>>>>> not deleted. And I think that turns out to be necessary, really.
+>>>>> However, I see no way to clean out that list on deletion and
+>>>>> manual recreation -- it still needs to remember it was once an autofile,
+>>>>> in order to avoid recreating it if it's deleted yet again. --[[Joey]]
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
 
@@ -264,6 +270,13 @@ wrong direction. (fixed --[[Joey]] )
 >>>> Good suggestion. Adding the files to RCS is on my todo list anyway.
 >>>> --[[David_Riebenbauer]]
 
+>>>>> I think it may be better to allow the `add_autofile` caller
+>>>>> to specify if it is added to RCS. In my branch, it can do
+>>>>> so by just making the callback it registers call `rcs_add`; 
+>>>>> and I have tag do this. Other plugins might want autofiles
+>>>>> that do not get checked in, conceivably.
+>>>>> --[[Joey]] 
+
 > Regarding the call from `IkiWiki.pm` to `Render.pm`, wouldn't this be
 > quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
 
@@ -271,19 +284,8 @@ wrong direction. (fixed --[[Joey]] )
 
 [[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
 I've pushed an autotag branch of my own, which refactors
-things a bit. It is untested so far though. --[[Joey]]
-
----
-
-Known bugs in my branch (probably also in David's):
-
-* Does not remember that a tag was deleted.
-  
-  The code to do that only works if, at the same time the tag
-  is deleted, one of the pages that has the tag is modified.
-  That's because `add_autofile` needs to be called before it's
-  aware the autofile exists, and if it's not aware, it does not
-  record it as a deleted autofile.
+things a bit and fixes bugs around deletion/recreation.
+I've tested it somewhat. --[[Joey]]
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 760b840e8f5af9e8ea0197bda783fd9b54a8ab7c Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:19:16 -0400
Subject: update

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 1 +
 1 file changed, 1 insertion(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f10c2cdee..724a52ec9 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -281,6 +281,7 @@ wrong direction. (fixed --[[Joey]] )
 > quite easy to solve by moving `verify_src_file` to IkiWiki.pm? --[[smcv]]
 
 >> True. I'll do that. --[[David_Riebenbauer]]
+>> Fixed in my branch --[[Joey]]
 
 [[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
 I've pushed an autotag branch of my own, which refactors
-- 
cgit v1.2.3


From b21db4197802ebd4d268b81b3df9448aa8108742 Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 21 Apr 2010 20:23:19 +0000
Subject: elide an older patch that's no longer under discussion

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 81 +---------------------
 1 file changed, 1 insertion(+), 80 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f10c2cdee..e993a9aa4 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -15,86 +15,7 @@ A new setting is used to enable or disable auto-create tag pages, `tag_autocreat
 The new tag file is created during the preprocess phase. 
 The new tag file is then complied during the change phase.
 
-_tag.pm from version 3.01_
-
-
-	--- tag.pm      2009-02-06 10:26:03.000000000 -0700
-	+++ tag_new.pm  2009-02-06 12:17:19.000000000 -0700
-	@@ -14,6 +14,7 @@
-			hook(type => "preprocess", id => "tag", call => \&preprocess_tag, scan => 1);
-			hook(type => "preprocess", id => "taglink", call => \&preprocess_taglink, scan => 1);
-			hook(type => "pagetemplate", id => "tag", call => \&pagetemplate);
-	+       hook(type => "change", id => "tag", call => \&change);
-	 }
-	 
-	 sub getopt () {
-	@@ -36,6 +37,36 @@
-							safe => 1,
-							rebuild => 1,
-					},
-	+               tag_autocreate => {
-	+                       type => "boolean",
-	+                       example => 0,
-	+                       description => "Auto-create the new tag pages, uses autotagpage.tmpl ",
-	+                       safe => 1,
-	+                       rebulid => 1,
-	+               },
-	+}
-	+
-	+my $autocreated_page = 0;
-	+
-	+sub gen_tag_page($)    {
-	+       my $tag=shift;
-	+
-	+       my $tag_file=$tag.'.'.$config{default_pageext};
-	+       return if (-f $config{srcdir}.$tag_file);
-	+
-	+       my $template=template("autotagpage.tmpl");
-	+       $template->param(tag => $tag);
-	+       writefile($tag_file, $config{srcdir}, $template->output);
-	+       $autocreated_page = 1;
-	+
-	+       if ($config{rcs}) {
-	+               IkiWiki::disable_commit_hook();
-	+               IkiWiki::rcs_add($tag_file);
-	+               IkiWiki::rcs_commit_staged(
-	+                       gettext("Automatic tag page generation"),
-	+                       undef, undef);
-	+               IkiWiki::enable_commit_hook();
-	+       }
-	 }
-	 
-	 sub tagpage ($) {
-	@@ -47,6 +78,10 @@
-					$tag=~y#/#/#s; # squash dups
-			}
-	 
-	+       if (defined $config{tag_autocreate} && $config{tag_autocreate} ) {
-	+               gen_tag_page($tag);
-	+       }
-	+
-			return $tag;
-	 }
-	 
-	@@ -125,4 +160,18 @@
-			}
-	 }
-	 
-	+sub change(@) {
-	+       return unless($autocreated_page);
-	+       $autocreated_page = 0;
-	+
-	+       # This refresh/saveindex is to complie the autocreated tag pages
-	+       IkiWiki::refresh();
-	+       IkiWiki::saveindex();
-	+
-	+       # This refresh/saveindex is to fix the Tags link
-	+       # With out this additional refresh/saveindex the tag link displays ?tag
-	+       IkiWiki::refresh();
-	+       IkiWiki::saveindex();
-	+}
-	+
-
+*see git history of this page if you want the patch --[[smcv]]*
 
 This uses a [[template|wikitemplates]] called `autotagpage.tmpl`, here is my template file:
 
-- 
cgit v1.2.3


From ffe9fd8eb14cedaf31477dbce72c28dd38cc78ae Mon Sep 17 00:00:00 2001
From: "http://smcv.pseudorandom.co.uk/" 
Date: Wed, 21 Apr 2010 20:30:14 +0000
Subject: suppressing auto-creation can be quite counter-intuitive

---
 ...o-create_tag_pages_according_to_a_template.mdwn | 26 ++++++++++++++++++++++
 1 file changed, 26 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index e993a9aa4..5a1aff928 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -177,6 +177,32 @@ wrong direction. (fixed --[[Joey]] )
 >>>>> manual recreation -- it still needs to remember it was once an autofile,
 >>>>> in order to avoid recreating it if it's deleted yet again. --[[Joey]]
 
+>>>>>> Are these really the semantics we want? It seems strange to me
+>>>>>> that this:
+>>>>>>
+>>>>>> * tag a page as foo
+>>>>>> * tags/foo automatically appears
+>>>>>> * delete tags/foo
+>>>>>> * create tags/foo manually
+>>>>>> * delete tags/foo again
+>>>>>> * tags/foo isn't automatically created
+>>>>>>
+>>>>>> isn't the same as this:
+>>>>>>
+>>>>>> * create tags/foo
+>>>>>> * delete tags/foo
+>>>>>> * tag a page as foo
+>>>>>> * tags/foo automatically appears
+>>>>>>
+>>>>>> or even this:
+>>>>>>
+>>>>>> * create tags/foo
+>>>>>> * tag a page as foo
+>>>>>> * delete tags/foo
+>>>>>> * tags/foo automatically appears (?)
+>>>>>>
+>>>>>> --[[smcv]]
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
 
-- 
cgit v1.2.3


From 463ba55dce0d07e97fa44500146e850f72d7ea24 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:33:03 -0400
Subject: note re includes

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 4 ++++
 1 file changed, 4 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index b5c107915..a112cb9da 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -35,6 +35,10 @@ suffice.
 (This would also help to clear up the tricky disctinction between
 wikitemplates and in-wiki templates.)
 
+Note also that when using templates from "$srcdir/templates/", `no_includes`
+needs to be set. Currently this is done by the two plugins that use
+such templates, while includes are allowed in `templatedir`.
+
 > But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
 
 >> It would be better for them not to be rendered separately at all.
-- 
cgit v1.2.3


From 1336a3270b664dbd548c6ad66ec981d5fa24a953 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 16:36:58 -0400
Subject: response

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 254ec42b5..32870dd3d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -203,6 +203,12 @@ wrong direction. (fixed --[[Joey]] )
 >>>>>>
 >>>>>> --[[smcv]]
 
+>>>>>>> I agree that the last of these is not desired. It could be avoided
+>>>>>>> by extending the list of autofiles to include those that were not
+>>>>>>> created due to the file/page already existing.
+>>>>>>> 
+>>>>>>> Hmm, that would fix the previous scenario too. --[[Joey]] 
+
 >>> * `autoindex` forgets that a page was deleted when it's no longer needed
 >>>   anyway (this may be harder for `autotag`?)
 
-- 
cgit v1.2.3


From 557912c723a6e8df320a3c6dae461956cf893f10 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 20:47:18 -0400
Subject: my autotag branch seems ready

---
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 32870dd3d..b05e1db3d 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -239,7 +239,7 @@ wrong direction. (fixed --[[Joey]] )
 [[!template id=gitbranch branch=origin/autotag author="[[Joey]]"]]
 I've pushed an autotag branch of my own, which refactors
 things a bit and fixes bugs around deletion/recreation.
-I've tested it somewhat. --[[Joey]]
+I've tested it fairly thouroughly. --[[Joey]]
 
 [f3abeac919c4736429bd3362af6edf51ede8e7fe]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=f3abeac919c4736429bd3362af6edf51ede8e7fe (commitdiff for f3abeac919c4736429bd3362af6edf51ede8e7fe)
 [4af4d26582f0c2b915d7102fb4a604b176385748]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=4af4d26582f0c2b915d7102fb4a604b176385748 (commitdiff for 4af4d26582f0c2b915d7102fb4a604b176385748)
-- 
cgit v1.2.3


From 17a89d3d19f3a04ca2686ff18df127e5afaf9577 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 21 Apr 2010 21:57:12 -0400
Subject: update

---
 doc/plugins/tag/discussion.mdwn                             | 1 +
 doc/todo/auto-create_tag_pages_according_to_a_template.mdwn | 2 ++
 2 files changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/plugins/tag/discussion.mdwn b/doc/plugins/tag/discussion.mdwn
index 03dcb7b2f..dfd749252 100644
--- a/doc/plugins/tag/discussion.mdwn
+++ b/doc/plugins/tag/discussion.mdwn
@@ -28,3 +28,4 @@ See [[todo/auto-create tag pages according to a template]]
 
 -- Jeremy Schultz 
 
+`tag_autocreate` can now enable this. --[[Joey]] 
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index 32870dd3d..1e0a910f4 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -247,3 +247,5 @@ I've tested it somewhat. --[[Joey]]
 [da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0 (commitdiff for da5d29f95f6e693e8c14be1b896cf25cf4fdb3c0)
 [a358d74bef51dae31332ff27e897fe04834571e6]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=a358d74bef51dae31332ff27e897fe04834571e6 (commitdiff for a358d74bef51dae31332ff27e897fe04834571e6)
 [981400177d68a279f485727be3f013e68f0bf691]: http://git.liegesta.at/?p=ikiwiki.git;a=commitdiff;h=981400177d68a279f485727be3f013e68f0bf691 (commitdiff for 981400177d68a279f485727be3f013e68f0bf691)
+
+[[!tag done]]
-- 
cgit v1.2.3


From ad296f90c3b99bb5e033f769c44e5653f518f264 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Thu, 22 Apr 2010 13:45:25 -0400
Subject: add

---
 ...dittemplate_should_look_in_templates_directory_by_default.mdwn | 8 ++++++++
 1 file changed, 8 insertions(+)
 create mode 100644 doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn b/doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn
new file mode 100644
index 000000000..4bc10e432
--- /dev/null
+++ b/doc/todo/edittemplate_should_look_in_templates_directory_by_default.mdwn
@@ -0,0 +1,8 @@
+[[plugins/edittemplate]] looks for the specified template relative to the
+page the directive appears on. Which can be handy, eg, make a
+blog/mytemplate and put the directive on blog, and it will find
+"mytemplate". However, it can also be confusing, since other templates
+always are looked for in `templates/`.
+
+I think it should probably fall back to looking for `templates/$foo`.
+--[[Joey]] 
-- 
cgit v1.2.3


From 4c99904af30c9213060809937962c1a4ab9c5ad2 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Thu, 22 Apr 2010 16:29:49 -0400
Subject: reference my branch for this

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index a112cb9da..66aa07193 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -39,6 +39,9 @@ Note also that when using templates from "$srcdir/templates/", `no_includes`
 needs to be set. Currently this is done by the two plugins that use
 such templates, while includes are allowed in `templatedir`.
 
+Have started working on this.
+[[!template id=gitbranch branch=origin/templatemove author="[[Joey]]"]]
+
 > But would this require that templates be parseable as wiki pages?  Because that would be a nuisance. --[[KathrynAndersen]]
 
 >> It would be better for them not to be rendered separately at all.
-- 
cgit v1.2.3


From 53c8bf9ed98f263163768daeb1d4e0fdbf6e7ef3 Mon Sep 17 00:00:00 2001
From: privat 
Date: Fri, 23 Apr 2010 17:28:38 +0000
Subject: multiple_sidebars in a gitbranch

---
 doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index 02b83244e..bb4339f88 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -15,6 +15,8 @@ those contents instead.
 
 >> Here a simple [[patch]] for multiple sidebars. Not too fancy but better than having multiple copies of the sidebar plugin. --[[jeanprivat]]
 
+>>> I made a [[git]] branch for it [[!template id=gitbranch branch="privat/multiple_sidebars" author="[[jeanprivat]]"]] --[[jeanprivat]]
+
 
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
-- 
cgit v1.2.3


From 7e79da76332b93214a7d9a5c91bc046db4219ee2 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 23 Apr 2010 16:10:46 -0400
Subject: template docu reorg

Remove wikitemplates page; fold its contents into templates page.
Update all backlinks. Document new ability to put templates inside srcdir.
---
 doc/bugs/SSI_include_stripped_from_mdwn.mdwn       |  2 +-
 doc/bugs/login_page_non-obvious_with_openid.mdwn   |  4 +-
 doc/features.mdwn                                  |  2 +-
 doc/freesoftware.mdwn                              |  2 +-
 doc/ikiwiki-calendar.mdwn                          |  2 +-
 doc/ikiwiki/directive/edittemplate.mdwn            |  2 +-
 doc/ikiwiki/directive/pagetemplate.mdwn            |  8 +-
 doc/ikiwiki/directive/template.mdwn                |  8 +-
 doc/plugins/autoindex.mdwn                         |  2 +-
 doc/plugins/map/discussion.mdwn                    |  2 +-
 doc/plugins/pagetemplate.mdwn                      |  6 +-
 doc/plugins/template.mdwn                          |  4 +-
 doc/plugins/write.mdwn                             |  4 +-
 doc/templates.mdwn                                 | 91 +++++++++++++++++++---
 doc/tips/comments_feed.mdwn                        |  2 +-
 ...o-create_tag_pages_according_to_a_template.mdwn |  2 +-
 doc/todo/auto_rebuild_on_template_change.mdwn      |  2 +-
 doc/todo/html.mdwn                                 |  2 +-
 doc/todo/multiple_templates.mdwn                   |  2 +-
 doc/usage.mdwn                                     |  5 +-
 doc/wikitemplates.mdwn                             | 52 -------------
 doc/wikitemplates/discussion.mdwn                  | 46 -----------
 22 files changed, 111 insertions(+), 141 deletions(-)
 delete mode 100644 doc/wikitemplates.mdwn
 delete mode 100644 doc/wikitemplates/discussion.mdwn

(limited to 'doc/todo')

diff --git a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
index 5519e45c6..270da86d3 100644
--- a/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
+++ b/doc/bugs/SSI_include_stripped_from_mdwn.mdwn
@@ -10,7 +10,7 @@ If I have a <--#include virtual="foo" --> in some file, it gets stripped,
 > Anyway, it makes sense for the htmlscrubber to strip server-side
 > includes because otherwise your wiki could be attacked
 > by them being added to it. If you want to use both the htmlscrubber and
-> SSI together, I'd suggest you modify the [[wikitemplates]]
+> SSI together, I'd suggest you modify the [[templates]]
 > and put the SSI on there.
 > 
 > Ie, `page.tmpl` has a 
diff --git a/doc/bugs/login_page_non-obvious_with_openid.mdwn b/doc/bugs/login_page_non-obvious_with_openid.mdwn
index 1d087985a..9aa702037 100644
--- a/doc/bugs/login_page_non-obvious_with_openid.mdwn
+++ b/doc/bugs/login_page_non-obvious_with_openid.mdwn
@@ -36,7 +36,7 @@ If you want to keep it as one form, then perhaps using some javascript to disabl
 > that allows modifying that form, but does not allow creating a separate
 > form. The best way to make it obvious how to use it currently is to just
 > disable password auth, then it's nice and simple. :-) Javascript is an
-> interesting idea. It's also possible to write a custom [[signin.tmpl wikitemplates]] that
+> interesting idea. It's also possible to write a custom [[templates]] that
 > is displayed instead of the regular signin form, and it should be
 > possible to use that to manually lay it out better than FormBuilder
 > manages with its automatic layout. --[[Joey]]
@@ -44,4 +44,4 @@ If you want to keep it as one form, then perhaps using some javascript to disabl
 > I've improved the form, I think it's more obvious now that the openid
 > stuff is separate. Good enough to call this [[done]]. I think. --[[Joey]]
 
->> Looks good, thanks!  :-) -- [[AdamShand]]
\ No newline at end of file
+>> Looks good, thanks!  :-) -- [[AdamShand]]
diff --git a/doc/features.mdwn b/doc/features.mdwn
index ab521213d..07ce648ea 100644
--- a/doc/features.mdwn
+++ b/doc/features.mdwn
@@ -72,7 +72,7 @@ you would care to syndicate.
 
 Ikiwiki aims to produce 
 [valid XHTML 1.0](http://validator.w3.org/check?url=referer). Ikiwiki
-generates html using [[templates|wikitemplates]], and uses [[css]], so you
+generates html using [[templates]], and uses [[css]], so you
 can change the look and layout of all pages in any way you would like.
 
 ## [[Plugins]]
diff --git a/doc/freesoftware.mdwn b/doc/freesoftware.mdwn
index 7ac1ac6b4..2243d9b1f 100644
--- a/doc/freesoftware.mdwn
+++ b/doc/freesoftware.mdwn
@@ -4,7 +4,7 @@ ikiwiki, and this documentation wiki, are licensed under the terms of the
 GNU [[GPL]], version 2 or later.
 
 The parts of ikiwiki that become part of your own wiki (the [[basewiki]]
-pages (but not the smilies) and the [[templates|wikitemplates]]) are licensed
+pages (but not the smilies) and the [[templates]]) are licensed
 as follows: 
 
 > Redistribution and use in source and compiled forms, with or without
diff --git a/doc/ikiwiki-calendar.mdwn b/doc/ikiwiki-calendar.mdwn
index c1f4d7267..03cbdd86c 100644
--- a/doc/ikiwiki-calendar.mdwn
+++ b/doc/ikiwiki-calendar.mdwn
@@ -43,7 +43,7 @@ An example crontab:
 
 # TEMPLATES
 
-This command uses two [[template|wikitemplates]] to generate
+This command uses two [[templates]] to generate
 the pages, `calendarmonth.tmpl` and `calendaryear.tmpl`.
 
 # AUTHOR
diff --git a/doc/ikiwiki/directive/edittemplate.mdwn b/doc/ikiwiki/directive/edittemplate.mdwn
index d731bdb47..c486e821b 100644
--- a/doc/ikiwiki/directive/edittemplate.mdwn
+++ b/doc/ikiwiki/directive/edittemplate.mdwn
@@ -21,7 +21,7 @@ something like:
 	Details:
 
 The template page can also contain [[!cpan HTML::Template]] directives,
-similar to other ikiwiki [[templates]]. Currently only one variable is
+like other ikiwiki [[templates]]. Currently only one variable is
 set: `` is replaced with the name of the page being
 created.
 
diff --git a/doc/ikiwiki/directive/pagetemplate.mdwn b/doc/ikiwiki/directive/pagetemplate.mdwn
index 8ad901c1a..401b38099 100644
--- a/doc/ikiwiki/directive/pagetemplate.mdwn
+++ b/doc/ikiwiki/directive/pagetemplate.mdwn
@@ -1,17 +1,13 @@
 The `pagetemplate` directive is supplied by the [[!iki plugins/pagetemplate desc=pagetemplate]] plugin.
 
-This directive allows a page to be displayed using a different template than
-the default `page.tmpl` template.
+This directive allows a page to be displayed using a different
+[[template|templates]] than the default `page.tmpl` template.
 
 The page text is inserted into the template, so the template controls the
 overall look and feel of the wiki page. This is in contrast to the
 [[ikiwiki/directive/template]] directive, which allows inserting templates
 _into_ the body of a page.
 
-This directive can only reference templates that are already installed
-by the system administrator, typically into the
-`/usr/share/ikiwiki/templates` directory. Example:
-
 	\[[!pagetemplate template="my_fancy.tmpl"]]
 
 [[!meta robots="noindex, follow"]]
diff --git a/doc/ikiwiki/directive/template.mdwn b/doc/ikiwiki/directive/template.mdwn
index ae71ba5b5..052ca7873 100644
--- a/doc/ikiwiki/directive/template.mdwn
+++ b/doc/ikiwiki/directive/template.mdwn
@@ -1,7 +1,11 @@
 The `template` directive is supplied by the [[!iki plugins/template desc=template]] plugin.
 
-[[Templates]] are files that can be filled out and inserted into pages in the
-wiki, by using the template directive. The directive has an `id` parameter
+The template directive allows wiki pages to be used as templates.
+These templates can be filled out and inserted into other pages in the
+wiki using the directive. The [[templates]] page lists templates
+that can be used with this directive.
+
+The directive has an `id` parameter
 that identifies the template to use. The remaining parameters are used to
 fill out the template.
 
diff --git a/doc/plugins/autoindex.mdwn b/doc/plugins/autoindex.mdwn
index d1133e4f5..7c4e40419 100644
--- a/doc/plugins/autoindex.mdwn
+++ b/doc/plugins/autoindex.mdwn
@@ -3,5 +3,5 @@
 
 This plugin searches for [[SubPages|ikiwiki/subpage]] with a missing parent
 page, and generates the parent pages. The generated page content is
-controlled by the `autoindex.tmpl` [[template|wikitemplates]], which by
+controlled by the `autoindex.tmpl` [[template|templates]], which by
 default, uses a [[map]] to list the SubPages.
diff --git a/doc/plugins/map/discussion.mdwn b/doc/plugins/map/discussion.mdwn
index 2f7b140d6..54c921b0f 100644
--- a/doc/plugins/map/discussion.mdwn
+++ b/doc/plugins/map/discussion.mdwn
@@ -1,7 +1,7 @@
 I'm wanting a [[map]] (with indentation levels) showing page _titles_
 instead of page 'names'.  As far as I can see, this is not an option with
 existing plugins - I can get a list of pages using [[inline]] and
-appropriate [[wikitemplates]], but that has no indentation and therefore
+appropriate [[templates]], but that has no indentation and therefore
 doesn't show structure well.
 
 The quick way is to modify the map plugin to have a 'titles' option.  The
diff --git a/doc/plugins/pagetemplate.mdwn b/doc/plugins/pagetemplate.mdwn
index 53f069d0d..8254e14c5 100644
--- a/doc/plugins/pagetemplate.mdwn
+++ b/doc/plugins/pagetemplate.mdwn
@@ -3,8 +3,4 @@
 
 This plugin provides the [[ikiwiki/directive/pagetemplate]]
 [[ikiwiki/directive]], which allows a page to be displayed
-using a different [[template|wikitemplates]] than the default.
-
-This plugin can only use templates that are already installed in
-`/usr/share/ikiwiki/templates` (or wherever ikiwiki is configured to look for
-them). You can choose to use any .tmpl files in that directory.
+using a different [[template|templates]] than the default.
diff --git a/doc/plugins/template.mdwn b/doc/plugins/template.mdwn
index da775f232..8d17e2825 100644
--- a/doc/plugins/template.mdwn
+++ b/doc/plugins/template.mdwn
@@ -3,5 +3,5 @@
 
 This plugin provides the [[ikiwiki/directive/template]] [[ikiwiki/directive]].
 With this plugin, you can set up templates, and cause them to be filled out
-and inserted into pages in the wiki. It's documented and existing templates
-are listed in the [[templates]] page.
+and inserted into pages in the wiki. Existing templates are listed in the
+[[templates]] page.
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 00b54bdd3..9128c7f54 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -297,7 +297,7 @@ value is ignored.
 
 	hook(type => "pagetemplate", id => "foo", call => \&pagetemplate);
 
-[[Templates|wikitemplates]] are filled out for many different things in
+[[Templates]] are filled out for many different things in
 ikiwiki, like generating a page, or part of a blog page, or an rss feed, or
 a cgi. This hook allows modifying the variables available on those
 templates. The function is passed named parameters. The "page" and
@@ -313,7 +313,7 @@ a new custom parameter to the template.
 
 	hook(type => "templatefile", id => "foo", call => \&templatefile);
 
-This hook allows plugins to change the [[template|wikitemplates]] that is
+This hook allows plugins to change the [[template|templates]] that is
 used for a page in the wiki. The hook is passed a "page" parameter, and
 should return the name of the template file to use (relative to the
 template directory), or undef if it doesn't want to change the default
diff --git a/doc/templates.mdwn b/doc/templates.mdwn
index f2b581d2f..f7b3adae5 100644
--- a/doc/templates.mdwn
+++ b/doc/templates.mdwn
@@ -1,17 +1,88 @@
-[[!meta robots="noindex, follow"]]
-[[!if test="enabled(template)"
-then="This wiki has templates **enabled**."
-else="This wiki has templates **disabled**."
-]]
+[[Ikiwiki]] uses many templates for many purposes. By editing its templates,
+you can fully customise this site.
 
-Templates are files that can be filled out and inserted into pages in the
-wiki.
+[[!if test="enabled(template)" then="""
+## The template directive
 
+The template directive allows wiki pages to be used as templates.
+These templates can be filled out and inserted into other pages in the
+wiki using the directive.
+"""]]
 [[!if test="enabled(template) and enabled(inline)" then="""
-
-These templates are available for use with the template directive.
-
 [[!inline pages="templates/* and !*/discussion" feeds=no archive=yes
 sort=title template=titlepage
 rootpage=templates postformtext="Add a new template named:"]]
 """]]
+
+[[!if test="enabled(edittemplate)" then="""
+## The edittemplate directive
+
+The edittemplate directive can be used to make new pages default to
+containing text from a template, which can be filled as out the page is
+edited.
+"""]]
+
+## Wiki templates
+
+These templates are used to build the wiki. The aim is to keep almost all
+html out of ikiwiki and in the templates.
+
+* `page.tmpl` - Used for displaying all regular wiki pages.
+* `misc.tmpl` - Generic template used for any page that doesn't
+  have a custom template.
+* `editpage.tmpl` - Create/edit page.
+* `change.tmpl` - Used to create a page describing a change made to the wiki.
+* `passwordmail.tmpl` - Not a html template, this is used to
+  generate a mail with an url the user can use to reset their password.
+* `rsspage.tmpl` - Used for generating rss feeds for [[blogs|blog]].
+* `rssitem.tmpl` - Used for generating individual items on rss feeds.
+* `atompage.tmpl` - Used for generating atom feeds for blogs.
+* `atomitem.tmpl` - Used for generating individual items on atom feeds.
+* `inlinepage.tmpl` - Used for adding a page inline in a blog
+  page.
+* `archivepage.tmpl` - Used for listing a page in a blog archive page.
+* `microblog.tmpl` - Used for showing a microblogging post inline.
+* `blogpost.tmpl` - Used for a form to add a post to a blog (and a rss/atom links)
+* `feedlink.tmpl` - Used to add rss/atom links if blogpost.tmpl is not used.
+* `aggregatepost.tmpl` - Used by the [[plugins/aggregate]] plugin to create
+  a page for a post.
+* `searchform.tmpl` - Used by the [[plugins/search]] plugin to add a search
+  form to wiki pages.
+* `searchquery.tmpl` - This is an omega template, used by the
+  [[plugins/search]] plugin.
+* `comment.tmpl` - This template is used to display a comment
+  by the [[plugins/comments]] plugin.
+* `editcomment.tmpl` - This template is the comment post form for the
+  [[plugins/comments]] plugin.
+* `commentmoderation.tmpl` - This template is used to produce the comment
+  moderation form.
+* `recentchanges.tmpl` - This template is used for listing a change
+  on the RecentChanges page.
+
+[[!if test="enabled(pagetemplate)" then="""
+## The pagetemplate directive
+
+The pagetemplate directive can allow individual pages to use a
+different template than `page.tmpl`.
+"""]]
+
+## Template locations
+
+Templates are located in `/usr/share/ikiwiki/templates` by default;
+the `templatedir` setting can be used to make another directory be
+searched first. Customized templates can also be placed inside the
+"templates/" directory in your wiki's source.
+
+## Template syntax
+
+Ikiwiki uses the HTML::Template module as its template engine. This
+supports things like conditionals and loops in templates and is pretty easy
+to learn. All you really need to know are a few things:
+
+* To insert the value of a template variable, use ``.
+* To make a block of text conditional on a variable being set use
+  `text`.
+* To use one block of text if a variable is set and a second if it's not,
+  use `textother text`
+
+[[!meta robots="noindex, follow"]]
diff --git a/doc/tips/comments_feed.mdwn b/doc/tips/comments_feed.mdwn
index 6f8137256..6d4dbb803 100644
--- a/doc/tips/comments_feed.mdwn
+++ b/doc/tips/comments_feed.mdwn
@@ -6,5 +6,5 @@ add a feed that contains all the comments posted to any page. Here's how:
 	\[[!inline pages="internal(*/comment_*)" template=comment]]
 
 The special [[ikiwiki/PageSpec]] matches all comments. The
-[[template|wikitemplates]] causes the comments to be displayed formatted
+[[template|templates]] causes the comments to be displayed formatted
 nicely.
diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
index f6d444890..7eb404910 100644
--- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
+++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn
@@ -17,7 +17,7 @@ The new tag file is then complied during the change phase.
 
 *see git history of this page if you want the patch --[[smcv]]*
 
-This uses a [[template|wikitemplates]] called `autotagpage.tmpl`, here is my template file:
+This uses a [[template|templates]] called `autotagpage.tmpl`, here is my template file:
 
     \[[!inline pages="link()" archive="yes"]]
 
diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index a112cb9da..838d15c1a 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -6,7 +6,7 @@ This would allow setting:
 
 	templatedir => "$srcdir/templates",
 
-.. and then the [[wikitemplates]] are managed like other wiki files; and
+.. and then the [[templates]] are managed like other wiki files; and
 like other wiki files, a change to them automatically updates dependent
 pages.
 
diff --git a/doc/todo/html.mdwn b/doc/todo/html.mdwn
index 44f20c876..4f4542be2 100644
--- a/doc/todo/html.mdwn
+++ b/doc/todo/html.mdwn
@@ -1,6 +1,6 @@
 Create some nice(r) stylesheets.
 
 Should be doable w/o touching a single line of code, just
-editing the [[wikitemplates]] and/or editing [[style.css]].
+editing the [[templates]] and/or editing [[style.css]].
 
 [[done]] ([[css_market]] ..)
diff --git a/doc/todo/multiple_templates.mdwn b/doc/todo/multiple_templates.mdwn
index 72783c556..30fb8d6ee 100644
--- a/doc/todo/multiple_templates.mdwn
+++ b/doc/todo/multiple_templates.mdwn
@@ -1,4 +1,4 @@
-> Another useful feature might be to be able to choose a different [[template|wikitemplates]]
+> Another useful feature might be to be able to choose a different [[template|templates]]
 > file for some pages; [[blog]] pages would use a template different from the
 > home page, even if both are managed in the same repository, etc.
 
diff --git a/doc/usage.mdwn b/doc/usage.mdwn
index 2e12517ea..9cf61cc6c 100644
--- a/doc/usage.mdwn
+++ b/doc/usage.mdwn
@@ -120,10 +120,11 @@ also be configured using a setup file.
 
 * --templatedir dir
 
-  Specify the directory that the page [[templates|wikitemplates]] are stored in.
+  Specify the directory that [[templates|templates]] are stored in.
   Default is `/usr/share/ikiwiki/templates`, or another location as configured at
   build time. If the templatedir is changed, missing templates will still
-  be searched for in the default location as a fallback.
+  be searched for in the default location as a fallback. Templates can also be
+  placed in the "templates/" subdirectory of the srcdir.
 
   Note that if you choose to copy and modify ikiwiki's templates, you will need
   to be careful to keep them up to date when upgrading to new versions of
diff --git a/doc/wikitemplates.mdwn b/doc/wikitemplates.mdwn
deleted file mode 100644
index 6e5a7261d..000000000
--- a/doc/wikitemplates.mdwn
+++ /dev/null
@@ -1,52 +0,0 @@
-ikiwiki uses the HTML::Template module as its template engine. This
-supports things like conditionals and loops in templates and is pretty easy
-to learn.
-
-The aim is to keep almost all html out of ikiwiki and in the templates.
-
-It ships with some basic templates which can be customised. These are
-located in `/usr/share/ikiwiki/templates` by default; the `templatedir`
-setting can be used to make another directory be searched first.
-
-* `page.tmpl` - Used for displaying all regular wiki pages.
-* `misc.tmpl` - Generic template used for any page that doesn't
-  have a custom template.
-* `editpage.tmpl` - Create/edit page.
-* `change.tmpl` - Used to create a page describing a change made to the wiki.
-* `passwordmail.tmpl` - Not a html template, this is used to
-  generate a mail with an url the user can use to reset their password.
-* `rsspage.tmpl` - Used for generating rss feeds for [[blogs|blog]].
-* `rssitem.tmpl` - Used for generating individual items on rss feeds.
-* `atompage.tmpl` - Used for generating atom feeds for blogs.
-* `atomitem.tmpl` - Used for generating individual items on atom feeds.
-* `inlinepage.tmpl` - Used for adding a page inline in a blog
-  page.
-* `archivepage.tmpl` - Used for listing a page in a blog archive page.
-* `microblog.tmpl` - Used for showing a microblogging post inline.
-* `blogpost.tmpl` - Used for a form to add a post to a blog (and a rss/atom links)
-* `feedlink.tmpl` - Used to add rss/atom links if blogpost.tmpl is not used.
-* `aggregatepost.tmpl` - Used by the [[plugins/aggregate]] plugin to create
-  a page for a post.
-* `searchform.tmpl` - Used by the [[plugins/search]] plugin to add a search
-  form to wiki pages.
-* `searchquery.tmpl` - This is an omega template, used by the
-  [[plugins/search]] plugin.
-* `comment.tmpl` - This template is used to display a comment
-  by the [[plugins/comments]] plugin.
-* `editcomment.tmpl` - This template is the comment post form for the
-  [[plugins/comments]] plugin.
-* `commentmoderation.tmpl` - This template is used to produce the comment
-  moderation form.
-* `recentchanges.tmpl` - This template is used for listing a change
-  on the RecentChanges page.
-
-The [[plugins/pagetemplate]] plugin can allow individual pages to use a
-different template than `page.tmpl`.
-
-The [[plugins/template]] plugin also uses templates, though those
-[[templates]] are typically stored as pages in the wiki, and are inserted
-into pages.
-
-The [[plugins/edittemplate]] plugin is used to make new pages default to
-containing text from a template, which can be filled as out the page is
-edited.
diff --git a/doc/wikitemplates/discussion.mdwn b/doc/wikitemplates/discussion.mdwn
deleted file mode 100644
index f97444e5f..000000000
--- a/doc/wikitemplates/discussion.mdwn
+++ /dev/null
@@ -1,46 +0,0 @@
-## Place for local templates
-Where does one put any locally modified templates for an individual ikiwiki? --Ivan Z.
-
-> You can put them whereever you like; the `templatedir` controls
-> where ikiwiki looks for them. --[[Joey]] 
-
-Thank you for your response! My question arose out of my intention to make
-custom templates for a wiki--specifically suited for the kind of  content
-it will have--so, that would mean I would want to distribute them through
-git together with other content of the wiki. So, for this case the
-separation of conceptually ONE thing (the content, the templates, and the
-config option which orders to use these templates) into THREE separate
-files/repos (the main content repo, the repo with templates, and the config
-file) is not convenient: instead of distributing a single repo, I have to
-tell people to take three things if they want to replicate this wiki. How
-would you solve this inconvenience? Perhaps, a default location of the
-templates *inside* the source repo would do?--Ivan Z.
-
-> I would avoid putting the templates in a subdirectory of the ikiwiki srcdir.
-> (I'd also avoid putting the ikiwiki setup file there.)
-> While it's safe to do either in some cases, there are configurations where
-> it's unsafe. For example, a malicious user could use attachment handling to
-> replace those files with their own, bad versions.
-> 
-> So, two ideas for where to put the templatedir and ikiwiki setup. 
-
-> * The easiest option is to put your wiki content in a subdirectory
->   ("wiki", say) and point `srcdir` at that.
->   then you can have another subdirectory for the wikitemplates,
->   and put the setup file at the top.
-> * Another option if using git would be to have a separate branch,
->   in the same git repository, that holds wikitemplates and the setup file.
->   Then you check out the repository once to make the `srcdir` available,
->   and have a second checkout, of the other branch, to make the other stuff
->   available.
-> 
-> Note that with either of these methods, you have to watch out if
-> giving other direct commit access to the repository. They could
-> still edit the setup file and templates, so only trusted users should
-> be given access. (It is, however, perfectly safe to let people edit
-> the wiki via the web, and is even safe to configure
-> [[tips/untrusted_git_push]] to such a repository.) --[[Joey]]
-
-Thanks, that's a nice and simple idea: to have a subdirectory! I'll try it. --Ivan Z.
-
-A [[!taglink wish|wishlist]]: the ikiwiki program could be improved so that it follows the same logic as git in looking for its config: it could ascend directories until it finds an `.ikiwiki/` directory with `.ikiwiki/setup` and then uses that configuration. Now I'm tired to always type `ikiwiki --setup path/to/the/setup --refresh` when working in my working clone of the sources; I'd like to simply type `ikiwiki` instead, and let it find the setup file. The default location to look for templates could also be made to be a sibling of the setup file: `.ikiwiki/templates/`. --Ivan Z.
-- 
cgit v1.2.3


From d5c5fef363564261ccba236f1d64eaa60567d514 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 23 Apr 2010 16:48:37 -0400
Subject: update

---
 doc/todo/auto_rebuild_on_template_change.mdwn | 12 ++++++++++++
 1 file changed, 12 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 66aa07193..037d0d1db 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -62,3 +62,15 @@ Have started working on this.
 >>>>>> it'd either be necessary to make them be internal pages
 >>>>>> (templates/inlinepage._tmpl) or special-case them in some other way.
 >>>>>> --[[smcv]]
+
+>>>>>>> In my branch, I left in support for the templatedir, and also
+>>>>>>> /usr/share/ikiwiki/templates. So, users do not have to put their
+>>>>>>> custom templates in templates/ in the wiki. If they do, 
+>>>>>>> the templates are copied to the destdir like other non-wiki page files
+>>>>>>> are. The templates are not wiki pages, except those used by a few
+>>>>>>> things like the [[plugins/template]] plugin.
+>>>>>>> 
+>>>>>>> That seems acceptable, since users probably don't need to modify
+>>>>>>> many templates, so the clutter is small. (Especially when
+>>>>>>> compared to the other clutter the basewiki always puts in destdir.)
+>>>>>>> This could be revisted later. --[[Joey]] 
-- 
cgit v1.2.3


From 6c64ce0336240be16eeae81313e53c630cb196bc Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Fri, 23 Apr 2010 17:01:22 -0400
Subject: update news for template change

---
 debian/NEWS                                   | 32 +++++++++++++++++++--------
 doc/todo/auto_rebuild_on_template_change.mdwn |  2 ++
 template-transition-notes                     |  4 ----
 3 files changed, 25 insertions(+), 13 deletions(-)
 delete mode 100644 template-transition-notes

(limited to 'doc/todo')

diff --git a/debian/NEWS b/debian/NEWS
index 3a8705680..69967c84c 100644
--- a/debian/NEWS
+++ b/debian/NEWS
@@ -2,22 +2,36 @@ ikiwiki (3.20100422) unstable; urgency=low
 
   This version of ikiwiki has a lot of changes that you need to know about.
 
+  Now you can include customised versions of templates in the source
+  of your wiki. (For example, templates/page.tmpl.) When these templates
+  are changed, ikiwiki will automatically rebuild pages that use them.
+
   The --getctime switch is renamed to --gettimes, and it also gets the 
   file modification time. And it's a lot faster (when using git). But
   the really important change is, you don't have to remember to use this
   switch. Now ikiwiki will do it when it needs to.
 
-  Starting from this version, the "tagged()" pagespec only matches tags,
-  not regular wikilinks. If your wiki accidentially relied on the old,
-  buggy behavior, you might need to change its pagespecs to use "link()".
+  At last, the "tagged()" pagespec only matches tags, not regular wikilinks.
+  If your wiki accidentially relied on the old, buggy behavior, you might
+  need to change its pagespecs to use "link()".
+
+  Many of your wishes have been answered: Now tag pages can automatically be
+  created when new tags are used. This feature is enabled by default if you
+  have configured a tagbase. It can be turned on or off using the
+  tag_autocreate setting.
+
+  These changes may also affect some users:
+
+  * The title_natural sort method (as used by the inline directive, etc)
+    have been moved to the new sortnaturally plugin, which is not enabled
+    by default since it requires the Sort::Naturally perl module.
 
-  Now tag pages can automatically be created as new tags are used. This
-  feature is enabled by default if you have configured a tagbase. It
-  can be turned on or off using the tag_autocreate setting.
+  * TMPL_INCLUDE is no longer supported in any template used by ikiwiki.
+    It used to be allowed in certian templates, but not in others.
 
-  The title_natural sort method (as used by the inline directive, etc)
-  have been moved to the new sortnaturally plugin, which is not enabled
-  by default since it requires the Sort::Naturally perl module.
+  * The add_templates option has been removed from the underlay plugin.
+    If you used this option, you can instead use templates/ subdirectories
+    inside underlay directories added by the add_underlays option.
 
   Due to the above and other changes, all wikis need to be rebuilt on
   upgrade to this version. If you listed your wiki in /etc/ikiwiki/wikilist
diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn
index 192b22f70..ea990b877 100644
--- a/doc/todo/auto_rebuild_on_template_change.mdwn
+++ b/doc/todo/auto_rebuild_on_template_change.mdwn
@@ -74,3 +74,5 @@ Have started working on this.
 >>>>>>> many templates, so the clutter is small. (Especially when
 >>>>>>> compared to the other clutter the basewiki always puts in destdir.)
 >>>>>>> This could be revisted later. --[[Joey]] 
+
+[[done]]
diff --git a/template-transition-notes b/template-transition-notes
deleted file mode 100644
index a319616f4..000000000
--- a/template-transition-notes
+++ /dev/null
@@ -1,4 +0,0 @@
-* add_templates option removed from underlay plugin
-  (can use add_underlays instead)
-* includes no longer allowed in templates
-* template_params removed (not exported API)
-- 
cgit v1.2.3


From 0a139aba823ece3166d29ff2daee0b5c9507b52f Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Sat, 1 May 2010 18:27:53 -0400
Subject: htmlscrubber: Allow the html5 form attributes: placeholder autofocus,
 min, max, step.

---
 IkiWiki/Plugin/htmlscrubber.pm                     | 5 +++--
 debian/changelog                                   | 3 ++-
 doc/todo/Add_label_to_search_form_input_field.mdwn | 2 +-
 3 files changed, 6 insertions(+), 4 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/htmlscrubber.pm b/IkiWiki/Plugin/htmlscrubber.pm
index b3f659f73..479e10e74 100644
--- a/IkiWiki/Plugin/htmlscrubber.pm
+++ b/IkiWiki/Plugin/htmlscrubber.pm
@@ -101,8 +101,9 @@ sub scrubber {
 				tabindex target title type valign
 				value vspace width
 
-				autoplay preload loopstart loopend end
-				playcount controls pubdate placeholder
+				autofocus autoplay preload loopstart
+				loopend end playcount controls pubdate
+				placeholder min max step
 			} ),
 			"/" => 1, # emit proper 
XHTML href => $safe_url_regexp, diff --git a/debian/changelog b/debian/changelog index 951caab9e..12ef08a91 100644 --- a/debian/changelog +++ b/debian/changelog @@ -10,7 +10,8 @@ ikiwiki (3.20100428) UNRELEASED; urgency=low * htmlscrubber: Also allow html5 canvas tags. * htmlscrubber: Round out html5 video support with the preload attribute and the source tag. - * htmlscrubber: Allow the placeholder attribute. + * htmlscrubber: Allow the html5 form attributes: placeholder autofocus, + min, max, step. -- Joey Hess Tue, 27 Apr 2010 12:10:51 -0400 diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn index 51b34927d..281ab48e2 100644 --- a/doc/todo/Add_label_to_search_form_input_field.mdwn +++ b/doc/todo/Add_label_to_search_form_input_field.mdwn @@ -51,4 +51,4 @@ The patch below adds a label for the field to improve usability: > element. already works in eg, chromium. However, ikiwiki does not use > html5 yet. --[[Joey]] -[[!tag wishlist html5]] +[[!tag wishlist bugs/html5_support]] -- cgit v1.2.3 From b21df5029b94c5680d8a3e5f0c1ed40a660a1594 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 2 May 2010 13:49:56 -0400 Subject: Add placeholder text in search form (in html5 mode only). --- IkiWiki/Plugin/google.pm | 1 + IkiWiki/Plugin/search.pm | 1 + debian/changelog | 1 + doc/bugs/html5_support.mdwn | 3 --- doc/todo/Add_label_to_search_form_input_field.mdwn | 2 ++ templates/googleform.tmpl | 3 ++- templates/searchform.tmpl | 3 ++- 7 files changed, 9 insertions(+), 5 deletions(-) (limited to 'doc/todo') diff --git a/IkiWiki/Plugin/google.pm b/IkiWiki/Plugin/google.pm index 85467fa0b..68cde261c 100644 --- a/IkiWiki/Plugin/google.pm +++ b/IkiWiki/Plugin/google.pm @@ -42,6 +42,7 @@ sub pagetemplate (@) { if (! defined $form) { my $searchform = template("googleform.tmpl", blind_cache => 1); $searchform->param(url => $config{url}); + $searchform->param(html5 => $config{html5}); $form=$searchform->output; } diff --git a/IkiWiki/Plugin/search.pm b/IkiWiki/Plugin/search.pm index be39fdf1e..9e875c79c 100644 --- a/IkiWiki/Plugin/search.pm +++ b/IkiWiki/Plugin/search.pm @@ -58,6 +58,7 @@ sub pagetemplate (@) { if (! defined $form) { my $searchform = template("searchform.tmpl", blind_cache => 1); $searchform->param(searchaction => $config{cgiurl}); + $searchform->param(html5 => $config{html5}); $form=$searchform->output; } diff --git a/debian/changelog b/debian/changelog index 8158429a0..c9fc2e657 100644 --- a/debian/changelog +++ b/debian/changelog @@ -2,6 +2,7 @@ ikiwiki (3.20100502) UNRELEASED; urgency=low * Add parameter to displaytime to specify that it is a pubdate, and in html5 mode, use time tag. + * Add placeholder text in search form (in html5 mode only). -- Joey Hess Sun, 02 May 2010 13:22:50 -0400 diff --git a/doc/bugs/html5_support.mdwn b/doc/bugs/html5_support.mdwn index 386a3094a..5530b29db 100644 --- a/doc/bugs/html5_support.mdwn +++ b/doc/bugs/html5_support.mdwn @@ -64,11 +64,8 @@ HTML5](http://www.w3.org/TR/html5-diff/). > > Other ideas: > -> * Add pubdate attribute to time elements as appropriate. > * Use aside for the sidebar? Or for the [[templates/note]] template? > * Use nav for the actionbar -> * Use placeholder in the search box. Allows closing -> [[this_todo|Add_label_to_search_form_input_field]] > * Use details tag instead of the javascript in the toggle plugin. > (Need to wait on browser support probably.) > diff --git a/doc/todo/Add_label_to_search_form_input_field.mdwn b/doc/todo/Add_label_to_search_form_input_field.mdwn index 281ab48e2..514108fba 100644 --- a/doc/todo/Add_label_to_search_form_input_field.mdwn +++ b/doc/todo/Add_label_to_search_form_input_field.mdwn @@ -51,4 +51,6 @@ The patch below adds a label for the field to improve usability: > element. already works in eg, chromium. However, ikiwiki does not use > html5 yet. --[[Joey]] +>> [[Done]], placeholder added, in html5 mode only. + [[!tag wishlist bugs/html5_support]] diff --git a/templates/googleform.tmpl b/templates/googleform.tmpl index bcf1004a4..f39b46540 100644 --- a/templates/googleform.tmpl +++ b/templates/googleform.tmpl @@ -1,6 +1,7 @@
- + placeholder="search" />
diff --git a/templates/searchform.tmpl b/templates/searchform.tmpl index afae2ebf5..cb65d124c 100644 --- a/templates/searchform.tmpl +++ b/templates/searchform.tmpl @@ -1,5 +1,6 @@
- +placeholder="search" />
-- cgit v1.2.3 From d5928778a89762b73ed6f4ddaec690d14d774537 Mon Sep 17 00:00:00 2001 From: David Riebenbauer Date: Tue, 4 May 2010 02:26:56 +0200 Subject: whishlist about two-way conversion. --- doc/todo/two-way_convert_of_wikis.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/todo/two-way_convert_of_wikis.mdwn (limited to 'doc/todo') diff --git a/doc/todo/two-way_convert_of_wikis.mdwn b/doc/todo/two-way_convert_of_wikis.mdwn new file mode 100644 index 000000000..61f02a30b --- /dev/null +++ b/doc/todo/two-way_convert_of_wikis.mdwn @@ -0,0 +1,15 @@ + +[[!tag wishlist]] + +Ok, the vision is this: Some of you will know git-svn. I want something like +git-svn,, but for wikis. I want to be able to do the following: + +1. Convert a moinmoin (or whatever) wiki to a local ikiwiki on my laptop. +2. Edit my local copy (offline). +3. Preview the changes with my local ikiwki installation + browser. +4. Push the changes back to moinmoin (or whatever) wiki. + +I know, I know, ikiwiki wasn't designed for that, but it would be really cool, +and useful and people ask for that kind of thing too. + +--[[David_Riebenbauer]] -- cgit v1.2.3 From 3f925ac7351bcee9a8cbbcae881681e68087de50 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 6 May 2010 17:28:47 -0400 Subject: new todo --- doc/todo/comment_moderation_feed.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/todo/comment_moderation_feed.mdwn (limited to 'doc/todo') diff --git a/doc/todo/comment_moderation_feed.mdwn b/doc/todo/comment_moderation_feed.mdwn new file mode 100644 index 000000000..267706b1b --- /dev/null +++ b/doc/todo/comment_moderation_feed.mdwn @@ -0,0 +1,9 @@ +There should be a way to generate a feed that is updated whenever a new +comment needs moderation. Otherwise, it can be hard to remember to check +sites, which may rarely get comments. + +The feed should not include the comment subject or body, but could mention +the author. It would be especially handy if it was generated statically. +One way would be to generate internal pages corresponding to each comment +that needs moderation; then the feed could be constructed via a usual +inline. -- cgit v1.2.3 From 4bb245df90965898b3e572d67c4fda25b0be84c5 Mon Sep 17 00:00:00 2001 From: Changaco Date: Mon, 17 May 2010 16:46:28 +0000 Subject: --- doc/todo/multiple_template_directories.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn index c09a9595f..6d1632b4c 100644 --- a/doc/todo/multiple_template_directories.mdwn +++ b/doc/todo/multiple_template_directories.mdwn @@ -11,3 +11,5 @@ ought to do the trick. > global dir when it cannot find a template. For me, this is good enough. > And it is even documented in the man page. Sigh. I guess this could be > considered [[done]]. + +I have a use case for this, a site composed of blogs and wikis, templates divided in three categories : common, blog and wiki. The only solution I found is maintaining hard links, being able to have multiple template dirs would obviously be better. -- Changaco -- cgit v1.2.3 From f864b74859d8b0197f59d7dfe7d45063dc887cd1 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Mon, 17 May 2010 17:34:40 +0000 Subject: an example of somewhere where the old functionality is actually needed --- doc/todo/multiple_template_directories.mdwn | 32 +++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn index 6d1632b4c..0f8f5c880 100644 --- a/doc/todo/multiple_template_directories.mdwn +++ b/doc/todo/multiple_template_directories.mdwn @@ -13,3 +13,35 @@ ought to do the trick. > considered [[done]]. I have a use case for this, a site composed of blogs and wikis, templates divided in three categories : common, blog and wiki. The only solution I found is maintaining hard links, being able to have multiple template dirs would obviously be better. -- Changaco + +> [[plugins/underlay]] used to allow adding extra templatedirs, but Joey +> removed that functionality when he made templates search the wiki's +> own `templates` directory. +> +> You can get a 3-level hierarchy like this: +> +> * instance-specific overrides: $srcdir/templates +> * common to the entire site: a directory that is the value of all +> instances' `templatedir` parameters +> * common to every ikiwiki in the world: /usr/share/ikiwiki/templates +> (implicitly searched) +> +> (by "instance" I mean an instance of ikiwiki - a .setup file, basically.) +> +> For a more complex hierarchy you'd need the old [[plugins/underlay]] +> functionality, i.e. you'd need to (ask Joey to) revert the patch that +> removed it. For instance, if anyone has a hierarchy like this, then +> they need the old functionality back in order to split the template +> search path for the things marked `(???)`: +> +> every ikiwiki in the world (/usr/share/ikiwiki/templates) +> \--- your site (???) +> \--- your blogs (???) +> \--- travel blog ($srcdir/templates) +> \--- code blog ($srcdir/templates) +> \--- your wikis (???) +> \--- travel wiki ($srcdir/templates) +> \--- code wiki ($srcdir/templates) +> +> This looks pretty hypothetical to me, though... +> --[[smcv]] -- cgit v1.2.3 From 5e515605749684f5867857885043b4e25378a374 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 17 May 2010 15:42:20 -0400 Subject: new todo --- doc/todo/anon_push_of_comments.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 doc/todo/anon_push_of_comments.mdwn (limited to 'doc/todo') diff --git a/doc/todo/anon_push_of_comments.mdwn b/doc/todo/anon_push_of_comments.mdwn new file mode 100644 index 000000000..bb5d04670 --- /dev/null +++ b/doc/todo/anon_push_of_comments.mdwn @@ -0,0 +1,6 @@ +It should be possible to use anonymous git push to post comments +(created, say, by a ikiwiki-comment program). Currently, that is not +allowed, because users cannot edit, or create internal page files. +But, comments in allowed locations are an exception to that rule, and +that exception should be communicated somehow to `IkiWiki::Receive`. +--[[Joey]] -- cgit v1.2.3 From 3298902443128f68e21f4ad349a7a3a9e0f03bce Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 17 May 2010 15:46:07 -0400 Subject: response --- doc/todo/multiple_template_directories.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn index 0f8f5c880..fe1951d51 100644 --- a/doc/todo/multiple_template_directories.mdwn +++ b/doc/todo/multiple_template_directories.mdwn @@ -45,3 +45,8 @@ I have a use case for this, a site composed of blogs and wikis, templates divide > > This looks pretty hypothetical to me, though... > --[[smcv]] + +>> The reason I removed it is because the same functionality of having +>> multiple template directories is still present. Just put them in +>> the templates/ subdirectory of multiple underlay directories instead. +>> --[[Joey]] -- cgit v1.2.3 From 533c8e62c5043e8e10dbd6203bb1a5ebe8a0d87e Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 17 May 2010 15:55:17 -0400 Subject: why this is hard.. --- doc/todo/anon_push_of_comments.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/anon_push_of_comments.mdwn b/doc/todo/anon_push_of_comments.mdwn index bb5d04670..b472ea13f 100644 --- a/doc/todo/anon_push_of_comments.mdwn +++ b/doc/todo/anon_push_of_comments.mdwn @@ -4,3 +4,11 @@ allowed, because users cannot edit, or create internal page files. But, comments in allowed locations are an exception to that rule, and that exception should be communicated somehow to `IkiWiki::Receive`. --[[Joey]] + +> Complications include: +> +> * Hard to see a way to prevent users from committing a comment that +> claims to be written by someone else. +> * `checkcontent` hooks need to be run, but can't accept a comment +> for later moderation, since it's coming in as part of a commit. +> Best they could do is reject the commit. -- cgit v1.2.3 From 47bc6105326ce76327f2accb6d6ae34d2cb1429e Mon Sep 17 00:00:00 2001 From: intrigeri Date: Mon, 17 May 2010 22:46:23 +0200 Subject: please pull --- doc/todo/allow_displaying_number_of_comments.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/todo/allow_displaying_number_of_comments.mdwn (limited to 'doc/todo') diff --git a/doc/todo/allow_displaying_number_of_comments.mdwn b/doc/todo/allow_displaying_number_of_comments.mdwn new file mode 100644 index 000000000..8e479bc85 --- /dev/null +++ b/doc/todo/allow_displaying_number_of_comments.mdwn @@ -0,0 +1,9 @@ +My `numcomments` Git branch adds a `NUMCOMMENTS` `TMPL_VAR`, which is +useful to add to the `forumpage.tmpl` template to emulate (the nice +bits of) a more usual webforum. + +Please review... and pull :) + +-- [[intrigeri]] + +[[patch]] -- cgit v1.2.3 From 2b1bc9c7297dc4bf36f4fc91205ad13eaf1513ca Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 17 May 2010 17:13:53 -0400 Subject: review --- doc/todo/allow_displaying_number_of_comments.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_displaying_number_of_comments.mdwn b/doc/todo/allow_displaying_number_of_comments.mdwn index 8e479bc85..7e8802210 100644 --- a/doc/todo/allow_displaying_number_of_comments.mdwn +++ b/doc/todo/allow_displaying_number_of_comments.mdwn @@ -5,5 +5,23 @@ bits of) a more usual webforum. Please review... and pull :) -- [[intrigeri]] + +> How is having this variable for showing a count of the comments +> better (or more forum-ish) than the COMMENTSLINK variable which +> includes a count and a link to the comments, and is already displayed +> in inlinepage.tmpl? +> +> `num_comments` will never return undef. +> +> I see no need to add a second pagetemplate hook. +> The existing one can be added to. Probably inside its `if ($shown)` +> block. +> +> It may also be a good idea to either combine the calls to `num_comments` +> used for this and for the commentslink, +> or to memoize it. I'm thinking generally memoizing it may be a good idea +> since the comments for a page will typically be counted twice when it's +> inlined. +> --[[Joey]] [[patch]] -- cgit v1.2.3 From 1f974b3517b3601e5014fcb0a383f980b4953a8c Mon Sep 17 00:00:00 2001 From: Changaco Date: Mon, 17 May 2010 23:36:16 +0000 Subject: problem solved --- doc/todo/multiple_template_directories.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn index fe1951d51..b8b9651b9 100644 --- a/doc/todo/multiple_template_directories.mdwn +++ b/doc/todo/multiple_template_directories.mdwn @@ -50,3 +50,5 @@ I have a use case for this, a site composed of blogs and wikis, templates divide >> multiple template directories is still present. Just put them in >> the templates/ subdirectory of multiple underlay directories instead. >> --[[Joey]] + +>>>Thanks, I didn't realize this was possible. Problem solved. -- Changaco -- cgit v1.2.3 From 284038fbbf09a55ae23ebeca03f8ff4487ce7ef6 Mon Sep 17 00:00:00 2001 From: "http://smcv.pseudorandom.co.uk/" Date: Tue, 18 May 2010 09:23:23 +0000 Subject: tag as done --- doc/todo/multiple_template_directories.mdwn | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/multiple_template_directories.mdwn b/doc/todo/multiple_template_directories.mdwn index b8b9651b9..6a474b4f3 100644 --- a/doc/todo/multiple_template_directories.mdwn +++ b/doc/todo/multiple_template_directories.mdwn @@ -52,3 +52,22 @@ I have a use case for this, a site composed of blogs and wikis, templates divide >> --[[Joey]] >>>Thanks, I didn't realize this was possible. Problem solved. -- Changaco + +>>>> We can consider this [[done]], then. For reference, the solution +>>>> to the hierarchy I mentioned above would be: +>>>> +>>>> all your sites have $your_underlay as an underlay +>>>> +>>>> the blogs and wikis all have $blog_underlay or $wiki_underlay +>>>> (as appropriate) as a higher priority underlay +>>>> +>>>> every ikiwiki in the world (/usr/share/ikiwiki/templates) +>>>> \--- your site ($your_underlay/templates, or templatedir) +>>>> \--- your blogs ($blog_underlay/templates) +>>>> \--- travel blog ($srcdir/templates) +>>>> \--- code blog ($srcdir/templates) +>>>> \--- your wikis ($wiki_underlay/templates) +>>>> \--- travel wiki ($srcdir/templates) +>>>> \--- code wiki ($srcdir/templates) +>>>> +>>>> --[[smcv]] -- cgit v1.2.3 From 529141779fe8492defbfa3e879c15bc81b3907dd Mon Sep 17 00:00:00 2001 From: intrigeri Date: Tue, 18 May 2010 16:11:45 +0200 Subject: response --- doc/todo/allow_displaying_number_of_comments.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/allow_displaying_number_of_comments.mdwn b/doc/todo/allow_displaying_number_of_comments.mdwn index 7e8802210..02d55fc9b 100644 --- a/doc/todo/allow_displaying_number_of_comments.mdwn +++ b/doc/todo/allow_displaying_number_of_comments.mdwn @@ -25,3 +25,6 @@ Please review... and pull :) > --[[Joey]] [[patch]] + +>> Well, the COMMENTSLINK variable fits my needs. Sorry for +>> the disturbance. [[done]] --[[intrigeri]] -- cgit v1.2.3 From 1bce0656755344977e020a985c4c06479f035f77 Mon Sep 17 00:00:00 2001 From: "http://kerravonsen.dreamwidth.org/" Date: Wed, 19 May 2010 11:36:30 +0000 Subject: new versions which address some of these issues --- doc/todo/Multiple_categorization_namespaces.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index a8ee6755c..3e9f8feaa 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -91,3 +91,13 @@ Where this approach is limiting is on the kind of data that is passed to (templa One possibility could be to have the `queries` configuration allow a hash mapping query names to functions that would transform the data. Lacking that possibility, we might have to leave some predefined fields to have custom Perl-side treatment and leave custom fields to be untransformable. +----- + +I've now updated the [[plugins/contrib/field]] plugin to have: + +* arrays (multi-valued fields) +* the "linkbase" option as mentioned above (called field_tags), where the linktype is the field name. + +I've also updated [[plugins/contrib/ftemplate]] and [[plugins/contrib/report]] to be able to use multi-valued fields, and [[plugins/contrib/ymlfront]] to correctly return multi-valued fields when they are requested. + +--[[KathrynAndersen]] -- cgit v1.2.3 From b6d00070a556e68d8e79eb5d64fe7a5ad2dbda18 Mon Sep 17 00:00:00 2001 From: nil Date: Fri, 11 Jun 2010 02:45:14 +0000 Subject: use the ikiwiki userdb outside of the ikiwiki edition access control --- doc/todo/htpasswd_mirror_of_the_userdb.mdwn | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/todo/htpasswd_mirror_of_the_userdb.mdwn (limited to 'doc/todo') diff --git a/doc/todo/htpasswd_mirror_of_the_userdb.mdwn b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn new file mode 100644 index 000000000..0582a6f7a --- /dev/null +++ b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn @@ -0,0 +1,17 @@ +[[!tag wishlist]] + +Ikiwiki is static, so access control for viewing the wiki must be implemented on the web server side. Managing wiki users and access together, we can currently + +* use [[httpauth|plugins/httpauth/]], but some [[passwordauth|plugins/passwordauth]] functionnality [[is missing|todo/httpauth_feature_parity_with_passwordauth/]]; +* use [[passwordauth|plugins/passwordauth]] plus [[an Apache `mod_perl` authentication mechanism|plugins/passwordauth/discussion/]], but this is Apache-centric and enabling `mod_perl` just for auth seems overkill. + +Moreover, when ikiwiki is just a part of a wider web project, we may want to use the same userdb for the other parts of this project. + +I think an ikiwiki plugin which would (re)generate an htpasswd version of the user/passwd base (better, two htpasswd files, one with only the wiki admins and one with everyone) each time an user is added or modified would solve this problem: + +* access control can be managed from the web server +* user management is handled by the passwordauth plugin +* htpasswd format is understood by various servers (Apache, lighttpd, nginx, ...) and languages commonly used for web development (perl, python, ruby) +* htpasswd files can be mirrored on other machines when the web site is distributed + +-- [[nil]] -- cgit v1.2.3 From f9dc2bf8598033c2bc74229073323d97fe83e50a Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 14 Jun 2010 14:14:43 -0400 Subject: good idea --- doc/todo/htpasswd_mirror_of_the_userdb.mdwn | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) (limited to 'doc/todo') diff --git a/doc/todo/htpasswd_mirror_of_the_userdb.mdwn b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn index 0582a6f7a..e4a411780 100644 --- a/doc/todo/htpasswd_mirror_of_the_userdb.mdwn +++ b/doc/todo/htpasswd_mirror_of_the_userdb.mdwn @@ -1,13 +1,19 @@ [[!tag wishlist]] -Ikiwiki is static, so access control for viewing the wiki must be implemented on the web server side. Managing wiki users and access together, we can currently +Ikiwiki is static, so access control for viewing the wiki must be +implemented on the web server side. Managing wiki users and access +together, we can currently * use [[httpauth|plugins/httpauth/]], but some [[passwordauth|plugins/passwordauth]] functionnality [[is missing|todo/httpauth_feature_parity_with_passwordauth/]]; * use [[passwordauth|plugins/passwordauth]] plus [[an Apache `mod_perl` authentication mechanism|plugins/passwordauth/discussion/]], but this is Apache-centric and enabling `mod_perl` just for auth seems overkill. -Moreover, when ikiwiki is just a part of a wider web project, we may want to use the same userdb for the other parts of this project. +Moreover, when ikiwiki is just a part of a wider web project, we may want +to use the same userdb for the other parts of this project. -I think an ikiwiki plugin which would (re)generate an htpasswd version of the user/passwd base (better, two htpasswd files, one with only the wiki admins and one with everyone) each time an user is added or modified would solve this problem: +I think an ikiwiki plugin which would (re)generate an htpasswd version of +the user/passwd base (better, two htpasswd files, one with only the wiki +admins and one with everyone) each time an user is added or modified would +solve this problem: * access control can be managed from the web server * user management is handled by the passwordauth plugin @@ -15,3 +21,9 @@ I think an ikiwiki plugin which would (re)generate an htpasswd version of the us * htpasswd files can be mirrored on other machines when the web site is distributed -- [[nil]] + +> I think this is a good idea. Although unless the password hashes that +> are stored in the userdb are compatible with htpasswd hashes, +> the htpasswd hashes will need to be stored in the userdb too. Then +> any userdb change can just regenerate the htpasswd file, dumping out +> the right kind of hashes. --[[Joey]] -- cgit v1.2.3 From b3e8115c95c79859c2893ac73e9f0bab0db31594 Mon Sep 17 00:00:00 2001 From: "http://www.openid.albertlash.com/openid/" Date: Fri, 18 Jun 2010 20:47:31 +0000 Subject: --- doc/todo/Google_Sitemap_protocol.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn index 057a88b72..6657c9350 100644 --- a/doc/todo/Google_Sitemap_protocol.mdwn +++ b/doc/todo/Google_Sitemap_protocol.mdwn @@ -45,3 +45,13 @@ On [Google Webmaster tools](https://www.google.com/webmasters/tools) you can sub [Google should grok feeds as sitemaps.](http://www.google.com/support/webmasters/bin/answer.py?answer=34654) Or rather [[plugins/inline]] should be improved to support the [sitemap protocol](http://sitemaps.org/protocol.php) natively. -- [[Hendry]] + + +Took me a minute to figure this out so I figured I'd share the steps I took: + +* Added rss=>1 and allowrss=>1 to my setup file +* Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date: + +
+\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+
-- cgit v1.2.3 From 4833f486b6ca759e1bcd8acc19e13ef4a0a6063f Mon Sep 17 00:00:00 2001 From: "http://www.openid.albertlash.com/openid/" Date: Fri, 18 Jun 2010 20:48:10 +0000 Subject: don't need to escape the inline tag if its in pre tag --- doc/todo/Google_Sitemap_protocol.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn index 6657c9350..12ac8d036 100644 --- a/doc/todo/Google_Sitemap_protocol.mdwn +++ b/doc/todo/Google_Sitemap_protocol.mdwn @@ -53,5 +53,5 @@ Took me a minute to figure this out so I figured I'd share the steps I took: * Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
-\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+[[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
 
-- cgit v1.2.3 From 22478de2cb9d843e3444e0f39bac850d372887f1 Mon Sep 17 00:00:00 2001 From: privat Date: Tue, 22 Jun 2010 13:30:50 +0000 Subject: --- doc/todo/auto_publish_expire.mdwn | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/auto_publish_expire.mdwn (limited to 'doc/todo') diff --git a/doc/todo/auto_publish_expire.mdwn b/doc/todo/auto_publish_expire.mdwn new file mode 100644 index 000000000..6f767a693 --- /dev/null +++ b/doc/todo/auto_publish_expire.mdwn @@ -0,0 +1,10 @@ +It could be nice to mark some page such that: + +* the page is automatically published on some date (i.e. build, linked, syndicated, inlined/mapped, etc.) +* the page is automatically unpublished at some other date (i.e. removed) + +I know that ikiwiki is a wiki compiler so that something has to refresh the wiki periodically to enforce the rules (a cronjob for instance). It seems to me that the calendar plugin rely on something similar. + +The date for publishing and expiring could be set be using some new directives; an alternative could be to expand the [[plugin/meta]] plugin with [[!meta date="auto publish date"]] and [[!meta expires="auto expire date"]]. + +--[[JeanPrivat]] -- cgit v1.2.3 From cfc1c4e933b8ba77bc6c3adb60fcea40721c0a61 Mon Sep 17 00:00:00 2001 From: privat Date: Tue, 22 Jun 2010 15:10:59 +0000 Subject: ping --- doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn index bb4339f88..8c689294a 100644 --- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn +++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn @@ -17,6 +17,8 @@ those contents instead. >>> I made a [[git]] branch for it [[!template id=gitbranch branch="privat/multiple_sidebars" author="[[jeanprivat]]"]] --[[jeanprivat]] +>>>> Ping for [[Joey]]. Do you have any comment? I could improve it if there is things you do not like. I prefer to have such a feature integrated upstream. --[[JeanPrivat]] +
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
-- 
cgit v1.2.3


From bbbbf04f76dc5eb6824e5efd5f0ca128e32430ce Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 13:12:43 -0400
Subject: thoughts

---
 doc/todo/auto_publish_expire.mdwn | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/auto_publish_expire.mdwn b/doc/todo/auto_publish_expire.mdwn
index 6f767a693..7a5a17517 100644
--- a/doc/todo/auto_publish_expire.mdwn
+++ b/doc/todo/auto_publish_expire.mdwn
@@ -8,3 +8,26 @@ I know that ikiwiki is a wiki compiler so that something has to refresh the wiki
 The date for publishing and expiring could be set be using some new directives; an alternative could be to expand the [[plugin/meta]] plugin with [[!meta date="auto publish date"]] and [[!meta expires="auto expire date"]].
 
 --[[JeanPrivat]]
+
+> This is a duplicate, and expansion, of
+> [[todo/tagging_with_a_publication_date]].
+> There, I suggest using a branch to develop
+> prepublication versions of a site, and merge from it
+> when the thing is published. 
+> 
+> Another approach I've seen used is to keep such pages in a pending/
+> directory, and move them via cron job when their publication time comes.
+> But that requires some familiarity with, and access to, cron.
+> 
+> On [[todo/tagging_with_a_publication_date]], I also suggested using meta 
+> date to set a page's date into the future,
+> and adding a pagespec that matches only pages with dates in the past,
+> which would allow filtering out the unpublished ones.
+> Sounds like you are thinking along these lines, but possibly using
+> something other than the page's creation or modification date to do it.
+> 
+> I do think the general problem with that approach is that you have to be
+> careful to prevent the unpublished pages from leaking out in any
+> inlines, maps, etc. --[[Joey]] 
+
+[[!tag wishlist]]
-- 
cgit v1.2.3


From 16ff593ab78409fc3c2482aeb2903e9a3d83b581 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 13:16:31 -0400
Subject: Revert "don't need to escape the inline tag if its in pre tag"

This reverts commit 4833f486b6ca759e1bcd8acc19e13ef4a0a6063f.

Being in a pre does not stop an inline directive from working.
---
 doc/todo/Google_Sitemap_protocol.mdwn | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 12ac8d036..6657c9350 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -53,5 +53,5 @@ Took me a minute to figure this out so I figured I'd share the steps I took:
 * Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
 
 
-[[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
 
-- cgit v1.2.3 From 9b845ea8132f5677c7466b8747333afba54017b9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 23 Jun 2010 13:17:33 -0400 Subject: one slash is enough to escape --- doc/todo/Google_Sitemap_protocol.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn index 6657c9350..2cf7c61e3 100644 --- a/doc/todo/Google_Sitemap_protocol.mdwn +++ b/doc/todo/Google_Sitemap_protocol.mdwn @@ -53,5 +53,5 @@ Took me a minute to figure this out so I figured I'd share the steps I took: * Created a new page where the RSS would be created with this content, replacing "first_page" with the page in my wiki with the earliest date:
-\[\[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
+\[[!inline  pages="* and !*/Discussion and created_after(first_page)" archive="yes" rss="yes" ]]
 
-- cgit v1.2.3 From 6235167962e65733f8a120edba394a77d684278f Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 23 Jun 2010 13:29:46 -0400 Subject: response --- .../beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn index 8c689294a..1f7b48764 100644 --- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn +++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn @@ -19,6 +19,21 @@ those contents instead. >>>> Ping for [[Joey]]. Do you have any comment? I could improve it if there is things you do not like. I prefer to have such a feature integrated upstream. --[[JeanPrivat]] +>>>>> The code is fine. +>>>>> +>>>>> I did think about having it examine +>>>>> the `page.tmpl` for parameters with names like `FOO_SIDEBAR` +>>>>> and automatically enable page `foo` as a sidebar in that case, +>>>>> instead of using the setup file to enable. But I'm not sure about +>>>>> that idea.. +>>>>> +>>>>> The full compliment of sidebars would be a header, a footer, +>>>>> a left, and a right sidebar. It would make sense to go ahead +>>>>> and add the parameters to `page.tmpl` so enabling each just works, +>>>>> and add whatever basic CSS makes sense. Although I don't know +>>>>> if I want to try to get a 3 column CSS going, so perhaps leave the +>>>>> left sidebar out of that. +
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
-- 
cgit v1.2.3


From e32bce464305fd8314d8324169a2079516548faf Mon Sep 17 00:00:00 2001
From: BerndZeimetz 
Date: Wed, 23 Jun 2010 18:44:52 +0000
Subject: It is possible to use google-sitemapgen to create google sitemaps for
 ikiwiki.

---
 doc/todo/Google_Sitemap_protocol.mdwn | 3 +++
 1 file changed, 3 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/Google_Sitemap_protocol.mdwn b/doc/todo/Google_Sitemap_protocol.mdwn
index 2cf7c61e3..ea8ee7f03 100644
--- a/doc/todo/Google_Sitemap_protocol.mdwn
+++ b/doc/todo/Google_Sitemap_protocol.mdwn
@@ -34,6 +34,9 @@ for an example.  You will probably need to strip out the metadata variables I
 >>>[xtermin.us rather than localhost](http://xtermin.us/git/?p=website.git;a=blob;f=plugins/googlesitemap.pm) is 404 now.
 >>> -- weakish
 
+
+Although it is not able to read the meta-data from files, using google-sitemapgen [works well for me](http://bzed.de/posts/2010/06/creating_a_google_sitemap_for_ikiwiki/) to create a sitemap for my ikiwiki installation. -- [[bzed|BerndZeimetz]]
+
 There is a [sitemap XML standard](http://www.sitemaps.org/protocol.php) that ikiwiki needs to generate for. 
 
 # Google Webmaster tools and RSS
-- 
cgit v1.2.3


From a4f381ace837a032bc202cc6b2a98e922d4b7cfc Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 19:44:41 -0400
Subject: git: Record the username from openid in the git author email. (This
 avoids display of ugly google openids.)

---
 IkiWiki/Plugin/git.pm                        |  5 +++++
 debian/changelog                             |  2 ++
 doc/rcs.mdwn                                 | 20 +++++++++++++-------
 doc/todo/Separate_OpenIDs_and_usernames.mdwn |  3 +++
 4 files changed, 23 insertions(+), 7 deletions(-)

(limited to 'doc/todo')

diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm
index 85368606e..3e289e0c3 100644
--- a/IkiWiki/Plugin/git.pm
+++ b/IkiWiki/Plugin/git.pm
@@ -506,6 +506,11 @@ sub rcs_commit_staged (@) {
 		if (defined $u) {
 			$u=encode_utf8($u);
 			$ENV{GIT_AUTHOR_NAME}=$u;
+		}
+		if (defined $params{session}->param("username")) {
+			$u=encode_utf8($params{session}->param("username"));
+		}
+		if (defined $u) {
 			$ENV{GIT_AUTHOR_EMAIL}="$u\@web";
 		}
 	}
diff --git a/debian/changelog b/debian/changelog
index 88ed3a90b..dfa862e5b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -5,6 +5,8 @@ ikiwiki (3.20100624) UNRELEASED; urgency=low
     parameters.
   * Fixed some confusion and bugginess about whether
     rcs_getctime/rcs_getmtime were passed absolute or relative filenames.
+  * git: Record the username from openid in the git author email.
+    (This avoids display of ugly google openids.)
 
  -- Joey Hess   Wed, 23 Jun 2010 15:30:04 -0400
 
diff --git a/doc/rcs.mdwn b/doc/rcs.mdwn
index 248d93024..83c6910d0 100644
--- a/doc/rcs.mdwn
+++ b/doc/rcs.mdwn
@@ -10,13 +10,8 @@ generic that it can be adapted to work with many systems by writing a
 
 While all supported revision control systems work well enough for basic
 use, some advanced or special features are not supported in all of them.
-Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to
-set up a wiki using that revision control system. The `rcs_commit_staged`
-hook is needed to use [[attachments|plugins/attachment]] or
-[[plugins/comments]]. `rcs_getctime` may be implemented in a fast way
-(ie, one log lookup for all files), or very slowly (one lookup per file).
-And so on. The table below summarises this for each revision control
-system and links to more information about each.
+The table below summarises this for each revision control system and
+links to more information about each.
 
 [[!table data="""
 feature             |[[git]]|[[svn]]|[[bzr]]   |[[monotone]]|[[mercurial]]|[[darcs]]|[[tla]]   |[[cvs]]
@@ -30,7 +25,18 @@ auto.setup          |yes    |yes    |incomplete|yes         |incomplete   |yes
 `rcs_getmtime`      |fast   |slow   |slow      |no          |no           |no       |no        |no
 anonymous push      |yes    |no     |no        |no          |no           |no       |no        |no
 conflict handling   |yes    |yes    |yes       |buggy       |yes          |yes      |yes       |yes
+openid username     |yes    |no     |no        |no          |no           |no       |no        |no
 """]]
 
+Notes:
+
+* Lack of support in [[ikiwiki-makerepo]] or auto.setup can make it harder to
+  set up a wiki using that revision control system.
+* The `rcs_commit_staged` hook is needed to use [[attachments|plugins/attachment]]
+  or [[plugins/comments]].
+* `rcs_getctime` and `rcs_getmtime` may be implemented in a fast way (ie, one log
+  lookup for all files), or very slowly (one lookup per file).
+* Openid username support allows avoiding display of Google's ugly openids.
+
 There is a page with [[details]] about how the different systems work with
 ikiwiki, for the curious.
diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index fcdb49f6d..60b7b6c61 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -38,10 +38,13 @@ A slightly more complex next step would be to request sreg from the provider and
 > * Change `rcs_commit` and `rcs_commit_staged` to take a session object,
 >   instead of just a userid. (For back-compat, if the parameter is 
 >   not an object, it's a userid.) Bump ikiwiki plugin interface version.
+>   (done)
 > * Modify all RCS plugins to include the session username somewhere
 >   in the commit, and parse it back out in `rcs_recentchanges`.
+>   (done for git only so far)
 > * Modify recentchanges plugin to display the username instead of the
 >   `openiduser`.
+>   (done)
 > * Modify comment plugin to put the session username in the comment
 >   template instead of the `openiduser`.
 
-- 
cgit v1.2.3


From 9a2c56b748ec9cd9230abada56267bde1840ca39 Mon Sep 17 00:00:00 2001
From: Joey Hess 
Date: Wed, 23 Jun 2010 20:21:44 -0400
Subject: openid nickname support finished; closing

---
 doc/todo/Separate_OpenIDs_and_usernames.mdwn | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/Separate_OpenIDs_and_usernames.mdwn b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
index 60b7b6c61..a4940220a 100644
--- a/doc/todo/Separate_OpenIDs_and_usernames.mdwn
+++ b/doc/todo/Separate_OpenIDs_and_usernames.mdwn
@@ -46,8 +46,8 @@ A slightly more complex next step would be to request sreg from the provider and
 >   `openiduser`.
 >   (done)
 > * Modify comment plugin to put the session username in the comment
->   template instead of the `openiduser`.
+>   template instead of the `openiduser`. (done)
 
 Unfortunately I don't speak Perl, so hopefully someone thinks these suggestions are good enough to code up. I've hacked on openid code in Ruby before, so hopefully these changes aren't all that difficult to implement. Even if you don't get any data via sreg, you're no worse off than where you are now, so I don't think there'd need to be much in the way of error/sanity-checking of returned data. If it's null or not available then no big deal, typing in a username is no sweat.
 
-[[!tag wishlist]]
+[[!tag wishlist done]]
-- 
cgit v1.2.3


From 71950b2ae5ff6fd3b631c5504455cc07699b1c11 Mon Sep 17 00:00:00 2001
From: "http://kerravonsen.dreamwidth.org/"
 
Date: Fri, 25 Jun 2010 02:40:25 +0000
Subject: sidebars defined by pagespec perhaps?

---
 ..._up_sidebar_to_allow_for_multiple_sidebars.mdwn | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

(limited to 'doc/todo')

diff --git a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
index 1f7b48764..fdaa09f26 100644
--- a/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
+++ b/doc/todo/beef_up_sidebar_to_allow_for_multiple_sidebars.mdwn
@@ -34,6 +34,8 @@ those contents instead.
 >>>>> if I want to try to get a 3 column CSS going, so perhaps leave the
 >>>>> left sidebar out of that.
 
+-------------------
+
 
 --- /usr/share/perl5/IkiWiki/Plugin/sidebar.pm	2010-02-11 22:53:17.000000000 -0500
 +++ plugins/IkiWiki/Plugin/sidebar.pm	2010-02-27 09:54:12.524412391 -0500
@@ -85,4 +87,39 @@ those contents instead.
  }
 
+---------------------------------------- +## Further thoughts about this + +(since the indentation level was getting rather high.) + +What about using pagespecs in the config to map pages and sidebar pages together? Something like this: + +
+	sidebar_pagespec => {
+	    "foo/*" => 'sidebars/foo_sidebar',
+	    "bar/* and !bar/*/*' => 'bar/bar_top_sidebar',
+	    "* and !foo/* and !bar/*" => 'sidebars/general_sidebar',
+	},
+
+ +One could do something similar for *pageheader*, *pagefooter* and *rightbar* if desired. + +Another thing which I find compelling - but probably because I am using [[plugins/contrib/field]] - is to be able to treat the included page as if it were *part* of the page it was included into, rather than as an included page. I mean things like \[[!if ...]] would test against the page name of the page it's included into rather than the name of the sidebar/header/footer page. It's even more powerful if one combines this with field/getfield/ftemplate/report, since one could make "generic" headers and footers that could apply to a whole set of pages. + +Header example: +
+#{{$title}}
+\[[!ftemplate id="nice_data_table"]]
+
+ +Footer example: +
+------------
+\[[!report template="footer_trail" trail="trailpage" here_only=1]]
+
+ +(Yes, I am already doing something like this on my own site. It's like the PmWiki concept of GroupHeader/GroupFooter) + +-- [[KathrynAndersen]] + [[!tag wishlist]] -- cgit v1.2.3 From 8f266d4d436be5cbb765ac81424687e764397d05 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Fri, 25 Jun 2010 19:32:46 +0200 Subject: another bugreport with patch --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index 87fa38911..b83d2814a 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -6,3 +6,5 @@ isn't. --[[intrigeri]] Fixed in my po branch. --[[intrigeri]] [[!tag patch]] + +> bump? -- cgit v1.2.3 From 2c1c6ea48835913d53740acc375d7f0c8106b429 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sun, 27 Jun 2010 00:12:40 +0200 Subject: Feature request, patch provided. --- doc/todo/Add_HTML_support_to_po_plugin.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 doc/todo/Add_HTML_support_to_po_plugin.mdwn (limited to 'doc/todo') diff --git a/doc/todo/Add_HTML_support_to_po_plugin.mdwn b/doc/todo/Add_HTML_support_to_po_plugin.mdwn new file mode 100644 index 000000000..ec29e4f61 --- /dev/null +++ b/doc/todo/Add_HTML_support_to_po_plugin.mdwn @@ -0,0 +1,7 @@ +The HTML page type should be fully supported by the PO plugin: po4a's +HTML support is able to extract translatable strings and to disregard +the rest. + +This is implemented in my po branch, please review. --[[intrigeri]] + +[[!tag patch]] -- cgit v1.2.3 From e63ead1c13290f314579f90e8ae2a607f2b69e7a Mon Sep 17 00:00:00 2001 From: intrigeri Date: Tue, 29 Jun 2010 15:50:19 +0200 Subject: please review new po pagespec: needstranlation() --- doc/todo/po_needstranslation_pagespec.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/po_needstranslation_pagespec.mdwn (limited to 'doc/todo') diff --git a/doc/todo/po_needstranslation_pagespec.mdwn b/doc/todo/po_needstranslation_pagespec.mdwn new file mode 100644 index 000000000..acc5641a4 --- /dev/null +++ b/doc/todo/po_needstranslation_pagespec.mdwn @@ -0,0 +1,5 @@ +Commit b225fdc44d4b3d in my po branch adds a `needstranslation()` +PageSpec. It makes it easy to list pages that need translation work. +Please review. --[[intrigeri]] + +[[!tag patch]] -- cgit v1.2.3 From 8a8914151cee44592dfdc3df3bb2c45b19b8c29c Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 4 Jul 2010 14:22:19 -0400 Subject: review of needstranslation() pagespec Minor wording fix; changelog; etc. --- IkiWiki/Plugin/po.pm | 2 +- debian/changelog | 1 + doc/todo/po_needstranslation_pagespec.mdwn | 6 +++++- 3 files changed, 7 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/IkiWiki/Plugin/po.pm b/IkiWiki/Plugin/po.pm index f12c69d5f..0b2251668 100644 --- a/IkiWiki/Plugin/po.pm +++ b/IkiWiki/Plugin/po.pm @@ -1225,7 +1225,7 @@ sub match_needstranslation ($$;@) { my $percenttranslated=IkiWiki::Plugin::po::percenttranslated($page); if ($percenttranslated eq 'N/A') { - return IkiWiki::FailReason->new("file is not a translation page"); + return IkiWiki::FailReason->new("file is not a translatable page"); } elsif ($percenttranslated < 100) { return IkiWiki::SuccessReason->new("file has $percenttranslated translated"); diff --git a/debian/changelog b/debian/changelog index 7d857d9c0..bdcf52884 100644 --- a/debian/changelog +++ b/debian/changelog @@ -20,6 +20,7 @@ ikiwiki (3.20100624) UNRELEASED; urgency=low * git: Added git_wrapper_background_command option. Can be used to eg, make the git wrapper push to github in the background after ikiwiki runs. + * po: Added needstranslation() pagespec. (intrigeri) -- Joey Hess Wed, 23 Jun 2010 15:30:04 -0400 diff --git a/doc/todo/po_needstranslation_pagespec.mdwn b/doc/todo/po_needstranslation_pagespec.mdwn index acc5641a4..77449dc2b 100644 --- a/doc/todo/po_needstranslation_pagespec.mdwn +++ b/doc/todo/po_needstranslation_pagespec.mdwn @@ -2,4 +2,8 @@ Commit b225fdc44d4b3d in my po branch adds a `needstranslation()` PageSpec. It makes it easy to list pages that need translation work. Please review. --[[intrigeri]] -[[!tag patch]] +> Looks good, cherry-picked. The only improvment I can +> think of is that `needstranslation(50)` could match +> only pages less than 50% translated. --[[Joey]] + +[[!tag patch done]] -- cgit v1.2.3 From beabd511e2477b90c409ce63c3b8decb5769ef03 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 4 Jul 2010 15:23:59 -0400 Subject: comment --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index b83d2814a..791c6c055 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -8,3 +8,9 @@ Fixed in my po branch. --[[intrigeri]] [[!tag patch]] > bump? + +>> I know I've looked at 88c6e2891593fd508701d728602515e47284180c +>> before, and something about it just seemed wrong. Maybe it's +>> the triviality of the sub, which it would seem to be easy to +>> decide to refactor back into its one caller (which would reintroduce the +>> bug). --[[Joey]] -- cgit v1.2.3 From 1f4f13ce0b354c0950b5d13d0da32dbfce8880c3 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sun, 11 Jul 2010 11:37:48 +0200 Subject: reply. and now? --- doc/todo/Fix_selflink_in_po_plugin.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index 791c6c055..c4f6662ce 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -14,3 +14,8 @@ Fixed in my po branch. --[[intrigeri]] >> the triviality of the sub, which it would seem to be easy to >> decide to refactor back into its one caller (which would reintroduce the >> bug). --[[Joey]] + +>>> Well, I can hear and understand this. Apart of adding a comment to +>>> the sub, explaining the rationale (which is now done in my po +>>> branch), I don't know what I can do to make it not seem wrong. +>>> --[[intrigeri]] -- cgit v1.2.3 From cfb63bc6385d6fea4db6c91160656389945c385c Mon Sep 17 00:00:00 2001 From: intrigeri Date: Sun, 11 Jul 2010 12:00:00 +0200 Subject: implemented, please merge --- doc/todo/po_needstranslation_pagespec.mdwn | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/po_needstranslation_pagespec.mdwn b/doc/todo/po_needstranslation_pagespec.mdwn index 77449dc2b..9ead4ace6 100644 --- a/doc/todo/po_needstranslation_pagespec.mdwn +++ b/doc/todo/po_needstranslation_pagespec.mdwn @@ -6,4 +6,7 @@ Please review. --[[intrigeri]] > think of is that `needstranslation(50)` could match > only pages less than 50% translated. --[[Joey]] -[[!tag patch done]] +>> This improvement has been implemented as 98cc946 in my po branch. +>> --[[intrigeri]] + +[[!tag patch]] -- cgit v1.2.3 From 40b03990e0d637860872e4cd47e4ee435b23d613 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Mon, 12 Jul 2010 15:43:04 -0400 Subject: merged --- doc/todo/po_needstranslation_pagespec.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/po_needstranslation_pagespec.mdwn b/doc/todo/po_needstranslation_pagespec.mdwn index 9ead4ace6..45b7377ea 100644 --- a/doc/todo/po_needstranslation_pagespec.mdwn +++ b/doc/todo/po_needstranslation_pagespec.mdwn @@ -9,4 +9,4 @@ Please review. --[[intrigeri]] >> This improvement has been implemented as 98cc946 in my po branch. >> --[[intrigeri]] -[[!tag patch]] +[[!tag patch done]] -- cgit v1.2.3 From 709e934a2bae637ee9be48a5c00961bf97e01efc Mon Sep 17 00:00:00 2001 From: bento Date: Sat, 17 Jul 2010 20:29:56 +0000 Subject: support-statement --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn index d0c09796f..189b46507 100644 --- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -29,3 +29,5 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch >>> >>> I do still think combining this with pagetemplate would be good. >>> --[[Joey]] + +>>>> This is exactly what I was looking for and it took me a while to find it. I very much support the idea to provide this as a regular plugin, be it merged with pagetemplate or stand-alone. Thank you for your work and code! --[BenTo]] -- cgit v1.2.3 From 7089c61b673076a4db41eeaa5606b3f6b07d101e Mon Sep 17 00:00:00 2001 From: bento Date: Sat, 17 Jul 2010 20:30:54 +0000 Subject: typo --- doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn index 189b46507..b130f4ec5 100644 --- a/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn +++ b/doc/todo/Set_templates_for_whole_sections_of_the_site.mdwn @@ -30,4 +30,4 @@ I've written a new plugin, sectiontemplate, available in the `page_tmpl` branch >>> I do still think combining this with pagetemplate would be good. >>> --[[Joey]] ->>>> This is exactly what I was looking for and it took me a while to find it. I very much support the idea to provide this as a regular plugin, be it merged with pagetemplate or stand-alone. Thank you for your work and code! --[BenTo]] +>>>> This is exactly what I was looking for and it took me a while to find it. I very much support the idea to provide this as a regular plugin, be it merged with pagetemplate or stand-alone. Thank you for your work and code! --BenTo -- cgit v1.2.3 From def97ec7fe5f84c0d1931ff2c0f8b33b78fed114 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 18 Jul 2010 19:43:25 -0400 Subject: merge fix for selflink po problem --- debian/changelog | 1 + doc/todo/Fix_selflink_in_po_plugin.mdwn | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/debian/changelog b/debian/changelog index b7387a050..db828f580 100644 --- a/debian/changelog +++ b/debian/changelog @@ -21,6 +21,7 @@ ikiwiki (3.20100705) UNRELEASED; urgency=low * Made much more robust in cases where multiple source files produce conflicting files/directories in the destdir. * Updated French program translation from Philippe Batailler. Closes: #589423 + * po: Fix selflink display on tranlsated pages. (intrigeri) -- Joey Hess Mon, 05 Jul 2010 13:59:42 -0400 diff --git a/doc/todo/Fix_selflink_in_po_plugin.mdwn b/doc/todo/Fix_selflink_in_po_plugin.mdwn index c4f6662ce..b276c075d 100644 --- a/doc/todo/Fix_selflink_in_po_plugin.mdwn +++ b/doc/todo/Fix_selflink_in_po_plugin.mdwn @@ -5,7 +5,7 @@ isn't. --[[intrigeri]] Fixed in my po branch. --[[intrigeri]] -[[!tag patch]] +[[!tag patch done]] > bump? -- cgit v1.2.3 From 6c4caf8211d09c144a0e22321e5bf8c0d3cd4cc1 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Thu, 29 Jul 2010 16:32:56 +0200 Subject: Move po todo/bugs to dedicated pages. --- doc/bugs/po:_double_commits_of_po_files.mdwn | 14 +++ doc/bugs/po:_new_pages_not_translatable.mdwn | 10 ++ doc/bugs/po:_ugly_messages_with_empty_files.mdwn | 4 + doc/plugins/po.mdwn | 101 ++------------------- doc/todo/po:_better_documentation.mdwn | 3 + doc/todo/po:_better_links.mdwn | 12 +++ .../po:_remove_po_files_when_disabling_plugin.mdwn | 2 + doc/todo/po:_rethink_pagespecs.mdwn | 11 +++ doc/todo/po:_translation_of_directives.mdwn | 8 ++ 9 files changed, 72 insertions(+), 93 deletions(-) create mode 100644 doc/bugs/po:_double_commits_of_po_files.mdwn create mode 100644 doc/bugs/po:_new_pages_not_translatable.mdwn create mode 100644 doc/bugs/po:_ugly_messages_with_empty_files.mdwn create mode 100644 doc/todo/po:_better_documentation.mdwn create mode 100644 doc/todo/po:_better_links.mdwn create mode 100644 doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn create mode 100644 doc/todo/po:_rethink_pagespecs.mdwn create mode 100644 doc/todo/po:_translation_of_directives.mdwn (limited to 'doc/todo') diff --git a/doc/bugs/po:_double_commits_of_po_files.mdwn b/doc/bugs/po:_double_commits_of_po_files.mdwn new file mode 100644 index 000000000..008df68c3 --- /dev/null +++ b/doc/bugs/po:_double_commits_of_po_files.mdwn @@ -0,0 +1,14 @@ +When adding a new english page, the po files are created, committed, +and then committed again. The second commit makes this change: + + -"Content-Type: text/plain; charset=utf-8\n" + -"Content-Transfer-Encoding: ENCODING" + +"Content-Type: text/plain; charset=UTF-8\n" + +"Content-Transfer-Encoding: ENCODING\n" + +Same thing happens when a change to an existing page triggers a po file +update. --[[Joey]] + +> * The s/utf-8/UTF-8 part has been fixed. +> * The ENCODING\n part is due to an inconsistency in po4a, which +> I've just send a patch for. --[[intrigeri]] diff --git a/doc/bugs/po:_new_pages_not_translatable.mdwn b/doc/bugs/po:_new_pages_not_translatable.mdwn new file mode 100644 index 000000000..84156bacc --- /dev/null +++ b/doc/bugs/po:_new_pages_not_translatable.mdwn @@ -0,0 +1,10 @@ +Today I added a new English page to l10n.ikiwiki.info. When I saved, +the page did not have the translation links at the top. I waited until +the po plugin had, in the background, created the po files, and refreshed; +still did not see the translation links. Only when I touched the page +source and refreshed did it finally add the translation links. +I can reproduce this bug in a test site. --[[Joey]] + +> I could reproduce this bug at some point during the merge of a buggy +> version of my ordered slave languages patch, but I cannot anymore. +> Could you please try again? --[[intrigeri]] diff --git a/doc/bugs/po:_ugly_messages_with_empty_files.mdwn b/doc/bugs/po:_ugly_messages_with_empty_files.mdwn new file mode 100644 index 000000000..4e782605b --- /dev/null +++ b/doc/bugs/po:_ugly_messages_with_empty_files.mdwn @@ -0,0 +1,4 @@ +If there are empty .mdwn files, the po plugin displays some ugly messages. + +> This is due to a bug in po4a (not checking definedness of a +> variable). One-liner patch sent. --[[intrigeri]] diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index ab096b2ac..1a3917454 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -235,39 +235,19 @@ When using po4a older than 0.35, it is recommended to uninstall `Text::WrapI18N` (Debian package `libtext-wrapi18n-perl`), in order to avoid a potential denial of service. -TODO +BUGS ==== -Better links ------------- - -Once the fix to -[[bugs/pagetitle_function_does_not_respect_meta_titles]] from -[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the -generated links' text will be optionally based on the page titles set -with the [[meta|plugins/meta]] plugin, and will thus be translatable. -It will also allow displaying the translation status in links to slave -pages. Both were implemented, and reverted in commit -ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted -once [[intrigeri]]'s `meta` branch is merged. +[[!map pages="bugs/po:*"]] -An integration branch, called `meta-po`, merges [[intrigeri]]'s `po` -and `meta` branches, and thus has this additional features. - -Pagespecs ---------- +[[!inline pages="bugs/po:* and !bugs/done and !link(bugs/done) and !bugs/*/*" +feeds=no actions=no archive=yes show=0]] -I was suprised that, when using the map directive, a pagespec of "*" -listed all the translated pages as well as regular pages. That can -make a big difference to an existing wiki when po is turned on, -and seems generally not wanted. -(OTOH, you do want to match translated pages by -default when locking pages.) --[[Joey]] +TODO +==== -> Seems hard to me to sort apart the pagespec whose matching pages -> list must be restricted to pages in the master (or current?) -> language, and the ones that should not. The only solution I can see -> to this surprising behaviour is: documentation. --[[intrigeri]] +[[!inline pages="todo/po:* and !todo/done and !link(todo/done) and !todo/*/*" +feeds=no actions=no archive=yes show=0]] l10n wiki misconfiguration -------------------------- @@ -324,68 +304,3 @@ underlay, and the underlays lack translation to a given language. >>>> this could be solved by adding `SRCDIR/basewiki` as an underlay >>>> to your l10n wiki configuration, possibly using the >>>> `add_underlays` configuration directive. --[[intrigeri]] - -Double commits of po files --------------------------- - -When adding a new english page, the po files are created, committed, -and then committed again. The second commit makes this change: - - -"Content-Type: text/plain; charset=utf-8\n" - -"Content-Transfer-Encoding: ENCODING" - +"Content-Type: text/plain; charset=UTF-8\n" - +"Content-Transfer-Encoding: ENCODING\n" - -Same thing happens when a change to an existing page triggers a po file -update. --[[Joey]] - -> * The s/utf-8/UTF-8 part has been fixed. -> * The ENCODING\n part is due to an inconsistency in po4a, which -> I've just send a patch for. --[[intrigeri]] - -New pages not translatable --------------------------- - -Today I added a new English page to l10n.ikiwiki.info. When I saved, -the page did not have the translation links at the top. I waited until -the po plugin had, in the background, created the po files, and refreshed; -still did not see the translation links. Only when I touched the page -source and refreshed did it finally add the translation links. -I can reproduce this bug in a test site. --[[Joey]] - -> I could reproduce this bug at some point during the merge of a buggy -> version of my ordered slave languages patch, but I cannot anymore. -> Could you please try again? --[[intrigeri]] - -Ugly messages with empty files ------------------------------- - -If there are empty .mdwn files, the po plugin displays some ugly messages. - -> This is due to a bug in po4a (not checking definedness of a -> variable). One-liner patch sent. --[[intrigeri]] - -Remove po/pot files when disabling the po plugin? -------------------------------------------------- - -ikiwiki now has a `disable` hook. Should the po plugin remove the po -files from the source repository when it has been disabled? - -Translation of directives -------------------------- - -If a translated page contains a directive, it may expand to some english -text, or text in whatever single language ikiwiki is configured to "speak". - -Maybe there could be a way to switch ikiwiki to speaking another language -when building a non-english page? Then the directives would get translated. - -(We also will need this in order to use translated templates, when they are -available.) - -Documentation -------------- - -Maybe write separate documentation depending on the people it targets: -translators, wiki administrators, hackers. This plugin may be complex -enough to deserve this. diff --git a/doc/todo/po:_better_documentation.mdwn b/doc/todo/po:_better_documentation.mdwn new file mode 100644 index 000000000..6e9804df4 --- /dev/null +++ b/doc/todo/po:_better_documentation.mdwn @@ -0,0 +1,3 @@ +Maybe write separate documentation for the po plugin, depending on the +people it targets: translators, wiki administrators, hackers. This +plugin may be complex enough to deserve this. diff --git a/doc/todo/po:_better_links.mdwn b/doc/todo/po:_better_links.mdwn new file mode 100644 index 000000000..af879a56a --- /dev/null +++ b/doc/todo/po:_better_links.mdwn @@ -0,0 +1,12 @@ +Once the fix to +[[bugs/pagetitle_function_does_not_respect_meta_titles]] from +[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the +generated links' text will be optionally based on the page titles set +with the [[meta|plugins/meta]] plugin, and will thus be translatable. +It will also allow displaying the translation status in links to slave +pages. Both were implemented, and reverted in commit +ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted +once [[intrigeri]]'s `meta` branch is merged. + +An integration branch, called `meta-po`, merges [[intrigeri]]'s `po` +and `meta` branches, and thus has this additional features. diff --git a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn new file mode 100644 index 000000000..4ddd0fa1e --- /dev/null +++ b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn @@ -0,0 +1,2 @@ +ikiwiki now has a `disable` hook. Should the po plugin remove the po +files from the source repository when it has been disabled? diff --git a/doc/todo/po:_rethink_pagespecs.mdwn b/doc/todo/po:_rethink_pagespecs.mdwn new file mode 100644 index 000000000..50c10c5db --- /dev/null +++ b/doc/todo/po:_rethink_pagespecs.mdwn @@ -0,0 +1,11 @@ +I was suprised that, when using the map directive, a pagespec of "*" +listed all the translated pages as well as regular pages. That can +make a big difference to an existing wiki when po is turned on, +and seems generally not wanted. +(OTOH, you do want to match translated pages by +default when locking pages.) --[[Joey]] + +> Seems hard to me to sort apart the pagespec whose matching pages +> list must be restricted to pages in the master (or current?) +> language, and the ones that should not. The only solution I can see +> to this surprising behaviour is: documentation. --[[intrigeri]] diff --git a/doc/todo/po:_translation_of_directives.mdwn b/doc/todo/po:_translation_of_directives.mdwn new file mode 100644 index 000000000..89fc93620 --- /dev/null +++ b/doc/todo/po:_translation_of_directives.mdwn @@ -0,0 +1,8 @@ +If a translated page contains a directive, it may expand to some english +text, or text in whatever single language ikiwiki is configured to "speak". + +Maybe there could be a way to switch ikiwiki to speaking another language +when building a non-english page? Then the directives would get translated. + +(We also will need this in order to use translated templates, when they are +available.) -- cgit v1.2.3 From b298fdd78c2eb01cd89979c886e1284e957705fe Mon Sep 17 00:00:00 2001 From: intrigeri Date: Thu, 29 Jul 2010 16:37:17 +0200 Subject: todo++ --- doc/todo/po:_better_translation_interface.mdwn | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 doc/todo/po:_better_translation_interface.mdwn (limited to 'doc/todo') diff --git a/doc/todo/po:_better_translation_interface.mdwn b/doc/todo/po:_better_translation_interface.mdwn new file mode 100644 index 000000000..e66a77b85 --- /dev/null +++ b/doc/todo/po:_better_translation_interface.mdwn @@ -0,0 +1,2 @@ +Add a message-by-message translation interface to the PO plugin, +with automatic escaping of special chars. -- cgit v1.2.3 From 543bc7af8be315e44ccca575b788e566bc122db2 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Fri, 30 Jul 2010 16:19:50 +0200 Subject: eventually got rid of the double rebuild issue. please have a look. --- doc/plugins/po/discussion.mdwn | 22 --------------- .../po:_avoid_rebuilding_to_fix_meta_titles.mdwn | 32 ++++++++++++++++++++++ 2 files changed, 32 insertions(+), 22 deletions(-) create mode 100644 doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn (limited to 'doc/todo') diff --git a/doc/plugins/po/discussion.mdwn b/doc/plugins/po/discussion.mdwn index 73858c818..50998e822 100644 --- a/doc/plugins/po/discussion.mdwn +++ b/doc/plugins/po/discussion.mdwn @@ -644,28 +644,6 @@ daring a timid "please pull"... or rather, please review again :) >>> need improvements to the deletion UI to de-confuse that. It's fine to >>> put that off until needed --[[Joey]] >> -> * Re the meta title escaping issue worked around by `change`. -> I suppose this does not only affect meta, but other things -> at scan time too. Also, handling it only on rebuild feels -> suspicious -- a refresh could involve changes to multiple -> pages and trigger the same problem, I think. Also, exposing -> this rebuild to the user seems really ugly, not confidence inducing. -> -> So I wonder if there's a better way. Such as making po, at scan time, -> re-run the scan hooks, passing them modified content (either converted -> from po to mdwn or with the escaped stuff cheaply de-escaped). (Of -> course the scan hook would need to avoid calling itself!) -> -> (This doesn't need to block the merge, but I hope it can be addressed -> eventually..) -> -> --[[Joey]] ->> ->> I'll think about it soon. ->> ->> --[[intrigeri]] ->> ->>> Did you get a chance to? --[[Joey]] * As discussed at [[todo/l10n]] the templates needs to be translatable too. They should be treated properly by po4a using the markdown option - at least with my diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn new file mode 100644 index 000000000..78e8e3ade --- /dev/null +++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn @@ -0,0 +1,32 @@ +Re the meta title escaping issue worked around by `change`. + +> I suppose this does not only affect meta, but other things +> at scan time too. Also, handling it only on rebuild feels +> suspicious -- a refresh could involve changes to multiple +> pages and trigger the same problem, I think. Also, exposing +> this rebuild to the user seems really ugly, not confidence inducing. +> +> So I wonder if there's a better way. Such as making po, at scan time, +> re-run the scan hooks, passing them modified content (either converted +> from po to mdwn or with the escaped stuff cheaply de-escaped). (Of +> course the scan hook would need to avoid calling itself!) +> +> (This doesn't need to block the merge, but I hope it can be addressed +> eventually..) +> +> --[[Joey]] +>> +>> I'll think about it soon. +>> +>> --[[intrigeri]] +>> +>>> Did you get a chance to? --[[Joey]] + +>>>> I eventually did, and got rid of the ugly double rebuild of pages +>>>> at build time. This involved adding a `rescan` hook. Rationale +>>>> and details are in my po branch commit messages. I believe this +>>>> new way of handling meta title escaping to be far more robust. +>>>> Moreover this new implementation is more generic, feels more +>>>> logical to me, and probably fixes other similar bugs outside the +>>>> meta plugin scope. Please have a look when you can. +>>>> --[[intrigeri]] -- cgit v1.2.3 From 9d62c6382a9947f4c7b13d1598b5d7436405e6ea Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 1 Aug 2010 12:22:27 -0400 Subject: pot files maybe.. --- doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn index 4ddd0fa1e..26b1964ba 100644 --- a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn +++ b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn @@ -1,2 +1,4 @@ ikiwiki now has a `disable` hook. Should the po plugin remove the po files from the source repository when it has been disabled? + +> pot files, possibly, but the po files contain work, so no. --[[Joey]] -- cgit v1.2.3 From 7a1d5632b8c762ad7b00e1e834b5678ec9299bda Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 1 Aug 2010 12:36:44 -0400 Subject: comment --- doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn index 78e8e3ade..86b0ccd72 100644 --- a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn +++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn @@ -30,3 +30,11 @@ Re the meta title escaping issue worked around by `change`. >>>> logical to me, and probably fixes other similar bugs outside the >>>> meta plugin scope. Please have a look when you can. >>>> --[[intrigeri]] + +>>>>> Glad you have tackled this. Looking at +>>>>> 25447bccae0439ea56da7a788482a4807c7c459d, +>>>>> I wonder how this rescan hook is different from a scan hook +>>>>> with `last => 1` ? Ah, it comes *after* the preprocess hook +>>>>> in scan mode. Hmm, I wonder if there's any reason to have +>>>>> the scan hook called before those as it does now. Reordering +>>>>> those 2 lines could avoid adding a new hook. --[[Joey]] -- cgit v1.2.3 From e083e4caa8175c4ccc45dd06e9b9cd784dcbbc94 Mon Sep 17 00:00:00 2001 From: intrigeri Date: Mon, 2 Aug 2010 03:23:30 +0200 Subject: ack² MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/plugins/po.mdwn | 13 +++++++++++-- doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn | 3 +++ 2 files changed, 14 insertions(+), 2 deletions(-) (limited to 'doc/todo') diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index 154c4cbde..0f1d66d32 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -247,8 +247,8 @@ TODO [[!inline pages="todo/po:* and !todo/done and !link(todo/done) and !todo/*/*" feeds=no actions=no archive=yes show=0]] -l10n wiki misconfiguration --------------------------- +broken links to translatable basewiki pages that lack po files +-------------------------------------------------------------- If a page is not translated yet, the "translated" version of it displays wikilinks to other, existing (but not yet translated?) @@ -306,3 +306,12 @@ underlay, and the underlays lack translation to a given language. >>>>> There is no complete Swedish underlay translation yet, so it is not >>>>> shipped in ikiwiki. I don't think it's a misconfiguration to use >>>>> a language that doesn't have translated underlays. --[[Joey]] + +>>>>>> Ok. The problem is triggered when using a language that doesn't +>>>>>> have translated underlays, *and* defining +>>>>>> `po_translatable_pages` in a way that renders the base wiki +>>>>>> pages translatable in po's view of things, which in turns makes +>>>>>> the po plugin act as if the translation pages did exist, +>>>>>> although they do not in this case. I still need to have a deep +>>>>>> look at the underlays-related code you added to `po.pm` a while +>>>>>> ago. Stay tuned. --[[intrigeri]] diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn index 86b0ccd72..d4e1f743c 100644 --- a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn +++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn @@ -38,3 +38,6 @@ Re the meta title escaping issue worked around by `change`. >>>>> in scan mode. Hmm, I wonder if there's any reason to have >>>>> the scan hook called before those as it does now. Reordering >>>>> those 2 lines could avoid adding a new hook. --[[Joey]] + +>>>>>> Sure. I was fearing to break other plugins if I did so, so I +>>>>>> did not dare to. I'll try this. --[[intrigeri]] -- cgit v1.2.3 From 97a706f73ce2cedc8fd8a9bbeea6d25783260b2e Mon Sep 17 00:00:00 2001 From: intrigeri Date: Mon, 2 Aug 2010 15:14:33 +0200 Subject: both are now fixed in my po branch. --- doc/plugins/po.mdwn | 3 +++ doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn | 2 ++ 2 files changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/plugins/po.mdwn b/doc/plugins/po.mdwn index 0f1d66d32..91273ba98 100644 --- a/doc/plugins/po.mdwn +++ b/doc/plugins/po.mdwn @@ -315,3 +315,6 @@ underlay, and the underlays lack translation to a given language. >>>>>> although they do not in this case. I still need to have a deep >>>>>> look at the underlays-related code you added to `po.pm` a while >>>>>> ago. Stay tuned. --[[intrigeri]] + +>>>>>>> Fixed in my po branch, along with other related small bugs that +>>>>>>> happen in the very same situation only. --[[intrigeri]] diff --git a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn index d4e1f743c..402f70b79 100644 --- a/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn +++ b/doc/todo/po:_avoid_rebuilding_to_fix_meta_titles.mdwn @@ -41,3 +41,5 @@ Re the meta title escaping issue worked around by `change`. >>>>>> Sure. I was fearing to break other plugins if I did so, so I >>>>>> did not dare to. I'll try this. --[[intrigeri]] + +>>>>>>> Done in my po branch, please have a look. --[[intrigeri]] -- cgit v1.2.3 From c5b052cbbda14c5c33127890d4a9842b8dee826a Mon Sep 17 00:00:00 2001 From: intrigeri Date: Mon, 2 Aug 2010 16:00:37 +0200 Subject: explored possible ways to do it, got trapped. --- doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn index 26b1964ba..0801f7fcd 100644 --- a/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn +++ b/doc/todo/po:_remove_po_files_when_disabling_plugin.mdwn @@ -2,3 +2,10 @@ ikiwiki now has a `disable` hook. Should the po plugin remove the po files from the source repository when it has been disabled? > pot files, possibly, but the po files contain work, so no. --[[Joey]] + +>> I tried to implement this in my `po-disable` branch, but AFAIK, the +>> current rcs plugins interface provides no way to tell whether a +>> given file (e.g. a POT file in my case) is under version control; +>> in most cases, it is not, thanks to .gitignore or similar, but we +>> can't be sure. So I just can't decide it is needed to call +>> `rcs_remove` rather than a good old `unlink`. --[[intrigeri]] -- cgit v1.2.3 From 9943e270f8646fe01fa3d9feb49620f65467879c Mon Sep 17 00:00:00 2001 From: Perry Date: Thu, 5 Aug 2010 00:38:44 +0000 Subject: Note that the problem is not only for Brian May.... --- ...avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn index 65b7cd96a..5f17e3ae0 100644 --- a/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn +++ b/doc/todo/want_to_avoid_ikiwiki_using_http_or_https_in_urls_to_allow_serving_both.mdwn @@ -26,4 +26,6 @@ which seems to do the right thing in page.tmpl, but not for change.tmpl. Where i > The use of an absolute baseurl in change.tmpl is a special case. --[[Joey]] +So I'm facing this same issue. I have a wiki which needs to be accessed on three different URLs(!) and the hard coding of the URL from the setup file is becoming a problem for me. Is there anything I can do here? --[[Perry]] + [[wishlist]] -- cgit v1.2.3 From 8853e4e79c725cc5a58bfc96c75785ae2f16b068 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnbe6oB_ecFtNYII1JN3zSggwUPUdOb8jI" Date: Thu, 12 Aug 2010 14:13:05 +0000 Subject: Note about jsMath --- doc/todo/Add_nicer_math_formatting.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/todo/Add_nicer_math_formatting.mdwn (limited to 'doc/todo') diff --git a/doc/todo/Add_nicer_math_formatting.mdwn b/doc/todo/Add_nicer_math_formatting.mdwn new file mode 100644 index 000000000..041eaee11 --- /dev/null +++ b/doc/todo/Add_nicer_math_formatting.mdwn @@ -0,0 +1,5 @@ +It would be nice to add nicer math formatting. I currently use the [[plugins/teximg]] plugin, but I wonder if [jsMath](http://www.math.union.edu/~dpvc/jsMath/) wouldn't be a better option. + +[[Will]] + +[[!tag wishlist]] -- cgit v1.2.3 From 07e27bd082cf8ecd55908f6486a344bb74503de6 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 12 Aug 2010 20:55:59 -0400 Subject: add a link to libravatar --- doc/todo/avatar.mdwn | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/avatar.mdwn b/doc/todo/avatar.mdwn index f0599e4ed..91f924fa1 100644 --- a/doc/todo/avatar.mdwn +++ b/doc/todo/avatar.mdwn @@ -58,3 +58,8 @@ The hash is calculated from the user's email address. If the user's email is not known, skip it. End. :P + +--- + +[libravatar](https://launchpad.net/libravatar) is a federated avatar +system. Young but might be the right way to get avatars eventually. -- cgit v1.2.3 From 52e3f698bc8fafdab4d911d925d214981ebd8d25 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 14 Aug 2010 20:17:12 -0400 Subject: respond, open wishlist todo item with design --- doc/plugins/filecheck/discussion.mdwn | 49 ++++++++++++++++++++++++++++++----- doc/todo/generic_insert_links | 24 +++++++++++++++++ 2 files changed, 67 insertions(+), 6 deletions(-) create mode 100644 doc/todo/generic_insert_links (limited to 'doc/todo') diff --git a/doc/plugins/filecheck/discussion.mdwn b/doc/plugins/filecheck/discussion.mdwn index 9a3bcddfc..6ef780772 100644 --- a/doc/plugins/filecheck/discussion.mdwn +++ b/doc/plugins/filecheck/discussion.mdwn @@ -18,17 +18,54 @@ if ::magic() returns undef? --[[DavidBremner]] --- -At first I need to thank you for ikiwiki - it is what I was always looking for - coming from a whole bunch of wiki engines, this is the most intelligent and least bloated one. +At first I need to thank you for ikiwiki - it is what I was always looking +for - coming from a whole bunch of wiki engines, this is the most +intelligent and least bloated one. -My question is about the [[plugins/attachment]] plugin in conjunction with [[plugins/filecheck]]: I am using soundmanger2 js-library for having attached media files of all sorts played inline a page. +My question is about the [[plugins/attachment]] plugin in conjunction with +[[plugins/filecheck]]: I am using soundmanger2 js-library for having +attached media files of all sorts played inline a page. -To achieve this soundmanager2 asks for an id inside a ul-tag surrounding the a-tag. I was wondering if the Insert Link button could be provided with a more elegant solution than to have this code snippet to be filled in by hand every time you use it to insert links for attached media files. And in fact there apparently is a way in attachment.pm. +To achieve this soundmanager2 asks for an id inside a ul-tag surrounding +the a-tag. I was wondering if the Insert Link button could be provided with +a more elegant solution than to have this code snippet to be filled in by +hand every time you use it to insert links for attached media files. And in +fact there apparently is a way in attachment.pm. -While I can see that it is not needed for everyone inserting links to attached media files to have ul- and li-tags surrounding the link itself as well as being supplied with an id fill in, for me it would be the most straight forward solution. Pitty is I don't have the time to wrap my head around perl to write a patch myself. Is there any way to have this made an option which can be called via templates? +While I can see that it is not needed for everyone inserting links to +attached media files to have ul- and li-tags surrounding the link itself as +well as being supplied with an id fill in, for me it would be the most +straight forward solution. Pitty is I don't have the time to wrap my head +around perl to write a patch myself. Is there any way to have this made an +option which can be called via templates? -For sure I would like to donate for such a patch as well as I will do it for ikiwiki anyway, because it is such a fine application. +For sure I would like to donate for such a patch as well as I will do it +for ikiwiki anyway, because it is such a fine application. -If you are not familiar with soundmanager2: It is a very straight forward solution to inline mediafiles, using the usual flash as well as html5 solutions (used by soundcloud.com, freesound.org and the like). Worth a look anyway [schillmania.com](http://www.schillmania.com/) +If you are not familiar with soundmanager2: It is a very straight forward +solution to inline mediafiles, using the usual flash as well as html5 +solutions (used by soundcloud.com, freesound.org and the like). Worth a +look anyway [schillmania.com](http://www.schillmania.com/) Boris +> The behavior of "Insert Links" is currently hardcoded to support images +> and has a fallback for other files. What you want is a +> [[todo/generic_insert_links]] that can insert a template directive. +> Then you could make a template that generates the html needed for +> soundmanager2. I've written down a design at +> [[todo/generic_insert_links]]; I am currently very busy and not sure +> when I will get around to writing it, but with it on the todo list +> I shouldn't forget. --[[Joey]] +> +> You could make a [[ikiwiki/directive/template]] for soundmanager2 +> now, and manually insert the template directive for now +> when you want to embed a sound file. Something like this: + + \[[!template id=embed_mp3 file=your.mp3]] + +> Then in templates/embed_mp3.mdwn, something vaguely like this: + + diff --git a/doc/todo/generic_insert_links b/doc/todo/generic_insert_links new file mode 100644 index 000000000..050f32ee7 --- /dev/null +++ b/doc/todo/generic_insert_links @@ -0,0 +1,24 @@ +The attachment plugin's Insert Links button currently only knows +how to insert plain wikilinks and img directives (for images). + +[[wishlist]]: Generalize this, so a plugin can cause arbitrary text +to be inserted for a particular file. --[[Joey]] + +Design: + +Add an insertlinks hook. Each plugin using the hook would be called, +and passed the filename of the attachment. If it knows how to handle +the file type, it returns a the text that should be inserted on the page. +If not, it returns undef, and the next plugin is tried. + +This would mean writing plugins in order to handle links for +special kinds of attachments. To avoid that for simple stuff, +a fallback plugin could run last and look for a template +named like `templates/embed_$extension`, and insert a directive like: + + \[[!template id=embed_vp8 file=my_movie.vp8]] + +Then to handle a new file type, a user could just make a template +that expands to some relevant html. In the example above, +`templates/embed_vp8` could make a html5 video tag, possibly with some +flash fallback code even. -- cgit v1.2.3 From e9133cb2e605e4197856cb844cd7ed2272df43fd Mon Sep 17 00:00:00 2001 From: "http://jblevins.org/" Date: Tue, 17 Aug 2010 12:56:46 +0000 Subject: Update URL --- doc/todo/Option_to_make_title_an_h1__63__.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc/todo') diff --git a/doc/todo/Option_to_make_title_an_h1__63__.mdwn b/doc/todo/Option_to_make_title_an_h1__63__.mdwn index f4023d6dd..8345cd010 100644 --- a/doc/todo/Option_to_make_title_an_h1__63__.mdwn +++ b/doc/todo/Option_to_make_title_an_h1__63__.mdwn @@ -11,4 +11,4 @@ Currently, the page title (either the name of the page or the title specified wi > latter, making `#` (only when on the first line) set the page title, removing it from > the page body. --[[JasonBlevins]], October 22, 2008 - [h1title]: http://code.jblevins.org/ikiwiki/plugins.git/plain/h1title.pm + [h1title]: http://jblevins.org/git/ikiwiki/plugins.git/plain/h1title.pm -- cgit v1.2.3 From e65ab83d292c62f01740b68f4acdb5bf2d6d1f93 Mon Sep 17 00:00:00 2001 From: "http://oblomov.myopenid.com/" Date: Fri, 20 Aug 2010 08:19:27 +0000 Subject: --- doc/todo/support_link__40__.__41___in_pagespec.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/support_link__40__.__41___in_pagespec.mdwn b/doc/todo/support_link__40__.__41___in_pagespec.mdwn index da55bce67..79809662a 100644 --- a/doc/todo/support_link__40__.__41___in_pagespec.mdwn +++ b/doc/todo/support_link__40__.__41___in_pagespec.mdwn @@ -8,3 +8,6 @@ which uses !inline to list all posts with the tag. Joey said on IRC that "probably changing the derel() function in IkiWiki.pm is the best way to do it". +> I implemented this suggestion in the simplest possible way, [[!taglink patch]] available [[here|http://git.oblomov.eu/ikiwiki/patch/f4a52de556436fdee00fd92ca9a3b46e876450fa]]. +> An alternative approach, very similar, would be to make the empty page parameter mean current page (e.g. `link()` would mean pages linking here). The patch would be very similar. +> -- GB -- cgit v1.2.3 From 87acb9ad1c009c3a6570fad09b5286b5399d86bc Mon Sep 17 00:00:00 2001 From: "http://kostix.myopenid.com/" Date: Fri, 20 Aug 2010 16:00:24 +0000 Subject: Add a comment about adding of per-wiki or per-user setting for the edit box size --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 0c45f0c90..577c3dad8 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -38,3 +38,5 @@ have a small resize handle in a corner, that can be dragged around. No nasty javascript needed. IMHO, this is the right solution, and I hope other browsers emulate it. [[done]] --[[Joey]] + +Wouldn't it be possible to just implement an integer-valued setting for this, accessible via the "Setup" wiki page? This would require a wiki regen, but such a setting would not be changed frequently I suppose. Also, Mediawiki has this implemented as a per-user setting (two settings, actually, -- number of rows and columns of the edit area); such a per-user setting would be the best possible implementation, but I'm not sure if ikiwiki already supports per-user settings. Please consider implementing this as the current 20 rows is a great PITA for any non-trivial page. -- cgit v1.2.3 From d44733d3bd80d4c5dd8cf60b7107a0004c5c3fa8 Mon Sep 17 00:00:00 2001 From: "http://jmtd.livejournal.com/" Date: Sun, 22 Aug 2010 09:42:20 +0000 Subject: no need for rebuild --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 577c3dad8..8721277aa 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -40,3 +40,5 @@ browsers emulate it. [[done]] --[[Joey]] Wouldn't it be possible to just implement an integer-valued setting for this, accessible via the "Setup" wiki page? This would require a wiki regen, but such a setting would not be changed frequently I suppose. Also, Mediawiki has this implemented as a per-user setting (two settings, actually, -- number of rows and columns of the edit area); such a per-user setting would be the best possible implementation, but I'm not sure if ikiwiki already supports per-user settings. Please consider implementing this as the current 20 rows is a great PITA for any non-trivial page. + +> I don't think it would need a wiki rebuild, as the textarea is generated dynamically by the CGI when you perform a CGI action, and (as far as I know) is not cooked into any static content. -- [[Jon]] -- cgit v1.2.3 From 37f62dde2d9b752ba559b796cf6c1b3bc3dee9bd Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Wed, 25 Aug 2010 14:57:45 -0400 Subject: response --- doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'doc/todo') diff --git a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn index 8721277aa..77e46049f 100644 --- a/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn +++ b/doc/todo/edit_form:_no_fixed_size_for_textarea.mdwn @@ -42,3 +42,11 @@ browsers emulate it. [[done]] Wouldn't it be possible to just implement an integer-valued setting for this, accessible via the "Setup" wiki page? This would require a wiki regen, but such a setting would not be changed frequently I suppose. Also, Mediawiki has this implemented as a per-user setting (two settings, actually, -- number of rows and columns of the edit area); such a per-user setting would be the best possible implementation, but I'm not sure if ikiwiki already supports per-user settings. Please consider implementing this as the current 20 rows is a great PITA for any non-trivial page. > I don't think it would need a wiki rebuild, as the textarea is generated dynamically by the CGI when you perform a CGI action, and (as far as I know) is not cooked into any static content. -- [[Jon]] + +>> There is no need for a configuration setting for this -- to change +>> the default height from 20 rows to something else, you can just put +>> something like this in your `local.css`: --[[Joey]] + + #editcontent { + height: 50em; + } -- cgit v1.2.3