Merge branch 'prv/po' into pub/po

15 files changed, 264 insertions, 11 deletions

diff --git a/doc/todo/Feature_parity_with_Trac.mdwn b/doc/todo/Feature_parity_with_Trac.mdwn
index 8693da5e3..b2d9d43ed 100644
--- a/doc/todo/Feature_parity_with_Trac.mdwn
+++ b/doc/todo/Feature_parity_with_Trac.mdwn
@@ -5,11 +5,12 @@ Features needed:
 
  * Wiki, duh.
  * Source code viewing: This can be handled quite well with a [[shortcut|shortcuts]] to an external source viewer, or by putting
-    the source in the wiki itself (see the [[todo/automatic_use_of_syntax_plugin_on_source_code_files]] wishlist item) and using the
-    [[plugins/contrib/highlightcode]] or [[plugins/contrib/sourcehighlight]] plugins.
+    the source in the wiki itself (see the [[todo/automatic_use_of_syntax_plugin_on_source_code_files]] wishlist item and [[todo/syntax_highlighting]] todo item).
     * This could be improved with [[todo/source_link]].
     * Currently the source highlighting is a little problematic, as there can be two source files with the same wikiname.
        e.g. a `hello-world.c` and `hello-world.h`.  See [[bugs/multiple_pages_with_same_name]]
+       > That bug was fixed before you linked to the page. :-)
+       >> I was the one that fixed it... :) -- [[Will]]
  * Trac 'Timeline' feature: view history of the RCS - the `recentchanges` button.
  * Trac 'Roadmap' feature: Which TODOs/bugs are needed for which milestones.  Use the [[plugins/progress]] directive to show percentage complete for each milestone.
  * Bug tracking: see [[tips/integrated_issue_tracking_with_ikiwiki]] and [[todo/Updated_bug_tracking_example]].
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 efa07ad79..8676bec48 100644
--- a/doc/todo/Option_to_make_title_an_h1__63__.mdwn
+++ b/doc/todo/Option_to_make_title_an_h1__63__.mdwn
@@ -6,3 +6,9 @@ Currently, the page title (either the name of the page or the title specified wi
 > way, # is reserved for h1 if you choose to use headers in your page. --[[Joey]]
 
 [[done]]
+
+> For anyone interested, I've written a small plugin called [h1title][] that does the
+> 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/h1title.pm
diff --git a/doc/todo/Untrusted_push_in_Monotone.mdwn b/doc/todo/Untrusted_push_in_Monotone.mdwn
new file mode 100644
index 000000000..a8b1cd7c4
--- /dev/null
+++ b/doc/todo/Untrusted_push_in_Monotone.mdwn
@@ -0,0 +1,28 @@
+As noted in [[tips/untrusted_git_push]] an untrusted push capability was added recently, but only implemented in git.
+(See also [[todo/rcs_updates_needed]])
+
+This note describes (but does not implement) an approach for this with the [[rcs/monotone]] rcs backend.
+
+----
+
+Monotone behaves a little differently to git in its networking.  Git allows anyone to try to push, and then
+check whether it is ok before finally accepting it.  Monotone has no way to accept or reject revisions
+in this way.  However, monotone does have the ability to mark revisions, and to ignore unmarked revisions.
+
+This marking capability can be used to achieve a somewhat similar effect to what happens with git.  The
+problem with this is that anyone could put anything into the monotone database, and while this wouldn't
+affect ikiwiki, it seems bad to leave open, untrusted storage on the web.
+
+The Plan
+=====
+
+In the `note_netsync_revision_received` hook in the monotone server, have the server check to make sure
+that either a) the revision is signed by someone trusted or, b) the revision is checked using the same
+hook that git uses in `pre-receive`.  If the revision passes the ikiwiki `pre-receive` check then the
+monotone hook signs the revision.  This gives that revision the 'ikiwiki seal of approval'.
+
+You'll also want to update the monotone trust hooks to only trust revisions signed by trusted people, or
+ikiwiki.
+
+Now anyone can upload a revision, but only those signed by a trusted person, or which pass the ikiwiki
+check and so get signed by the ikiwiki key, will be seen by ikiwiki.
diff --git a/doc/todo/applydiff_plugin.mdwn b/doc/todo/applydiff_plugin.mdwn
index d3eb9793b..d26b0dfe9 100644
--- a/doc/todo/applydiff_plugin.mdwn
+++ b/doc/todo/applydiff_plugin.mdwn
@@ -1,4 +1,4 @@
-[[!tag wishlist]]
+[[!tag wishlist done]]
 
 [[!toc ]]
 
@@ -54,3 +54,57 @@ modify only *one* page may be easier.
 
 Implementation
 ==============
+
+Also see [[joey]]'s idea on [[users/xma/discussion]], to allow (filtered) anonymous push to this wiki's repository.
+
+> Ideally the filtering should apply the same constraints on what's pushed
+> as are applied to web edits. So locked pages can't be changed, etc.
+> 
+> That could be accomplished by making the git pre-receive hook be a
+> ikiwiki wrapper. A new `git_receive_wrapper` config setting could cause
+> the wrapper to be generated, with `$config{receive}` set to true.
+> 
+> When run that way, ikiwiki would call `rcs_receive`. In the case of git,
+> that would look at the received changes as fed into the hook on stdin,
+> and use `parse_diff_tree` to get a list of the files changed. Then it
+> could determine if the changes were allowed.
+> 
+> To do that, it should first look at what unix user received the
+> commit.  That could be mapped directly to an ikiwiki user. This would
+> typically be an unprivelidged user (that was set up just to allow
+> anonymous pushes), but you might also want to set up
+> separate users who have fewer limits on what they can push. And, of
+> course, pushes from the main user, who owns the wiki, would not be
+> checked at all. So, let's say `$config{usermap}` is a hash, something
+> like `{usera => "wikiusera", userb => "wikiuserb"}`, and pushes from
+> users not in the hash are not checked.
+> 
+> Then it seems like it would want to call `check_canedit` to test if an
+> edit to each changed page is allowed. Might also want to call
+> `check_canattach` and `check_canremove` if the attach and remove plugins
+> are enabled. All three expect to be passed a CGI and a CGI::Session
+> object, which is a bit problimatic here. So dummy the objects up? (To call
+> `check_canattach` the changed attachment would need to be extracted to a
+> temp file for it to check..)
+> 
+> If a change is disallowed, it would print out what was disallowed, and
+> exit nonzero. I think that git then discards the pushed objects (or maybe
+> they remain in the database until `git-gc` .. if so, that could be used
+> to DOS by uploading junk, so need to check this point).
+> 
+> Also, I've not verified that the objects have been recieved already when
+> whe pre-receive hook is called. Although the docs seem to say that is the
+> case. --[[Joey]]
+
+>> Update: The git pre-receive hook stuff is written, and seems to work.
+>> I think it makes more sense than using diffs, and so think this todo
+>> could probably be closed.
+>> --[[Joey]]
+
+>>> I agree, closing this. I really prefer this solution to the one I was
+>>> initially proposing.
+>>> Is this pre-receive hook already enabled on ikiwiki.info?
+>>> If not, do you plan to enable it at some point?
+>>> --[[intrigeri]]
+
+>>>> [[news/git_push_to_this_wiki]] gave me the answer. Well done! --[[intrigeri]]
diff --git a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn
index 2fad9f19a..467ec350e 100644
--- a/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn
+++ b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn
@@ -1,6 +1,6 @@
 Here is another [[patch]] for this.  It is more up to date than either of the patches linked on the previous page.  It is most similar to [[plugins/contrib/sourcehighlight]].
 
-Note that if this is being used with `c` or `c++` then you'll probably want to wait until [[bugs/multiple_pages_with_same_name]] is fixed.
+Updated to use fix noted in [[bugs/multiple_pages_with_same_name]].
 
 -- [[Will]]
 
@@ -92,7 +92,7 @@ Note that if this is being used with `c` or `c++` then you'll probably want to w
     	
     	foreach my $lang (split(/[, ]+/, $config{sourcecode_lang})) {
     		if ($langs{$lang}) {
-    			hook(type => "htmlize", id => $lang, call => \&htmlize);
+    			hook(type => "htmlize", id => $lang, call => \&htmlize, keepextension => 1);
     		} else {
     			error("Your installation of source-highlight cannot handle sourcecode language $lang!");
     		}
diff --git a/doc/todo/clear_page_to_delete.mdwn b/doc/todo/clear_page_to_delete.mdwn
index ccb7634e5..50ae246bb 100644
--- a/doc/todo/clear_page_to_delete.mdwn
+++ b/doc/todo/clear_page_to_delete.mdwn
@@ -24,3 +24,10 @@ the page.  That's what the user intended to do in this case.  The information
 content of an empty vs. a deleted page is essentially the same, I'd say.  But
 having ikiwiki remove those stale pages would save some (minimal, admittedly)
 time needed for manual clean-up.  --[[tschwinge]]
+
+On EmacsWiki, a page is marked for deletion when it contains just the DeletedPage 
+keyword and if there were no page editions since XX days. Here, I use pages that
+can be empty everyday and filled all day long. It does not make sense to me to 
+delete these pages :). --[[xma]]
+
+I was not aware of [[plugins/remove]]. I don't think another method is necessary -- [[JonDowland]]
diff --git a/doc/todo/dynamic_rootpage.mdwn b/doc/todo/dynamic_rootpage.mdwn
index fa0e23254..5cf80b0a8 100644
--- a/doc/todo/dynamic_rootpage.mdwn
+++ b/doc/todo/dynamic_rootpage.mdwn
@@ -23,3 +23,10 @@ What's your opinion, Joey? I hope it's also useful for another ikiwiki lovers :)
 >>> Seems like a job for good ol' string interpolation.  rootpage="post/$current_year/$current_month/$current_day"
 >>> Ikiwiki could provide some vars, and it would be nice to write plugins to also provide vars.  Sort of like templates.
 >>> Does that feel OK? --[[sabr]]
+
+> I want the exact same thing.  My compromise was to create a `datedblog` module which overrides `inline`'s `sessioncgi` hook
+> with something that sets the new page name to `%Y-%m-%d.$page` and sets up a meta directive at the beginning of
+> the content, with the title you wanted.  Now if you use the `datedblog` module, you get dated blog entries.  But I'd
+> like to have traditional `inline` functionality too.  This would work great if there were a way to change the `do`
+> parameter in the `blogpost` template's form; if I could change it to `datedblog` instead of `blog` then I could hook
+> my datedblog module in nicely, without having to override anything.  What would be the right way to do that? --[[neale]]
diff --git a/doc/todo/firm_up_plugin_interface.mdwn b/doc/todo/firm_up_plugin_interface.mdwn
index b0e92e65c..c2e190884 100644
--- a/doc/todo/firm_up_plugin_interface.mdwn
+++ b/doc/todo/firm_up_plugin_interface.mdwn
@@ -41,7 +41,7 @@ Another problimatic thing is plugins often define functions named 'preprocess',
       6 IkiWiki::titlepage
 
 These go together; linkpage is needed by all link plugins, and the others are used widely.
-All should be exported.
+All should be exported. (Done)
 
       7 IkiWiki::saveindex
       5 IkiWiki::loadindex
diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn
index 132de4480..b3e3a7889 100644
--- a/doc/todo/plugin.mdwn
+++ b/doc/todo/plugin.mdwn
@@ -70,10 +70,6 @@ Suggestions of ideas for plugins:
 > web-server-specific code to list all users, and openid can't feasibly do so
 > at all. --[[JoshTriplett]]
 
-* It would be nice to be able to have a button to show "Differences" (or 
-  "Show Diff") when editing a page. Is that an option that can be enabled?
-  Using a plugin?
-
 * For PlaceWiki I want to be able to do some custom plugins, including one
   that links together subpages about the same place created by different
   users. This seems to call for a plugin that applies to every page w/o any
diff --git a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn
index 7724576f5..39a35d0c6 100644
--- a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn
+++ b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn
@@ -1,3 +1,8 @@
 It would rock if I could view diffs from the web without going via feeds. I envision toggle-style buttons on the recentchanges page, or just links to the CGI, which then displays the diff... --[[madduck]]
 
+> The diffs are actually there, enabled by the `recentchangesdiff`
+> plugin, but they are hidden in the XHTML version by the stylesheet.
+> You might try a user stylesheet with `div.diff { display: block }`.
+> --[[JasonBlevins]]
+
 [[!tag wishlist]]
diff --git a/doc/todo/provide_sha1_for_git_diffurl.mdwn b/doc/todo/provide_sha1_for_git_diffurl.mdwn
new file mode 100644
index 000000000..9c8b340de
--- /dev/null
+++ b/doc/todo/provide_sha1_for_git_diffurl.mdwn
@@ -0,0 +1,26 @@
+This [[patch]] allows for `\[[sha1]]` substitution in the `diffurl`
+for git repositories.  This is useful for use with [cgit][] which has
+diffurls of the following form:
+
+    /project.git/diff/\[[file]]?id=\[[sha1_commit]]
+
+ [cgit]: http://hjemli.net/git/cgit/
+
+    diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm
+    index 5bef928..164210d 100644
+    --- a/IkiWiki/Plugin/git.pm
+    +++ b/IkiWiki/Plugin/git.pm
+    @@ -518,6 +518,7 @@ sub rcs_recentchanges ($) { #{{{
+     
+     			my $diffurl = defined $config{'diffurl'} ? $config{'diffurl'} : "";
+     			$diffurl =~ s/\[\[file\]\]/$file/go;
+    +			$diffurl =~ s/\[\[sha1\]\]/$sha1/go;
+     			$diffurl =~ s/\[\[sha1_parent\]\]/$ci->{'parent'}/go;
+     			$diffurl =~ s/\[\[sha1_from\]\]/$detail->{'sha1_from'}/go;
+     			$diffurl =~ s/\[\[sha1_to\]\]/$detail->{'sha1_to'}/go;
+
+> [[done]], but I called it `sha1_commit` since I think that's what it's
+> actually a sha1 of. --[[Joey]]
+
+>> I was at a loss for something more descriptive...I like that much
+>> better :) Thanks! --[[JasonBlevins]]
diff --git a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn b/doc/todo/rcs_updates_needed.mdwn
index 2af659c3b..472a5800f 100644
--- a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn
+++ b/doc/todo/rcs_updates_needed.mdwn
@@ -3,3 +3,8 @@ renaming and removing files using the web interface. The mercurial and
 tla [[rcs]] backends need implementions of these functions.
 
 (The maintainers of these backends have been mailed. --[[Joey]])
+
+Also, currently git is the only VCS to have support for
+[[untrusted_push|tips/untrusted_git_push]]. It _may_ be possible to
+implement it for other DVCS, if they offer a hook that can be used to check
+incoming pushes early.
diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn
new file mode 100644
index 000000000..bb1c84f02
--- /dev/null
+++ b/doc/todo/syntax_highlighting.mdwn
@@ -0,0 +1,89 @@
+There's been a lot of work on contrib syntax highlighting plugins. One should be
+picked and added to ikiwiki core.
+
+Ideally, it should support both converting whole source files into wiki
+pages, as well as doing syntax highlighting as a preprocessor directive 
+(which is either passed the text, or reads it from a file).
+
+## The big list of possibilities
+
+* [[plugins/contrib/highlightcode]] uses [[cpan Syntax::Highlight::Engine::Kate]],
+  operates on whole source files only, has a few bugs (see
+  [here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to
+  support [[bugs/multiple_pages_with_same_name]].
+* [[cpan IkiWiki-Plugin-syntax]] only operates as a directive.
+  Interestingly, it supports multiple highlighting backends, including Kate
+  and Vim.
+* [[plugins/contrib/syntax]] only operates as a directive
+  ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]),
+  and uses [[cpan Text::VimColor]].
+* [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on
+  whole source files only. Needs to be updated to
+  support [[bugs/multiple_pages_with_same_name]].
+* [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]
+  also uses src-highlight, and operates on whole source files.
+  Updated to work with the fix for [[bugs/multiple_pages_with_same_name]].  Untested with files with no extension, e.g. `Makefile`.
+
+## General problems
+
+* Using non-perl syntax highlighting backends is slow. I'd prefer either
+  using a perl module, or a multiple-backend solution that can use a perl
+  module as one option. (Or, if there's a great highlighter python module,
+  we could use an external plugin..)
+* Currently no single plugin supports both modes of operation (directive
+  and whole source file to page).
+* Nothing seems to support 
+  [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
+  inside source files. Doing this probably means post-processing the 
+  results of the highlighting engine, to find places where it's highlighted
+  comments, and then running them through the ikiwiki rendering pipeline.
+  This seems fairly doable with [[cpan Syntax::Highlight::Engine::Kate]],
+  at least.
+* The whole-file plugins tend to have a problem that things that look like
+  wikilinks in the source code get munged into links by ikiwiki, which can
+  have confusing results. Similar problem with preprocessor directives.
+  One approach that's also been requested for eg,
+  [[plugins/contrib/mediawiki]] is to allow controlling which linkification
+  types a page type can have on it.
+* The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
+  This is trivially fixable now by passing the keepextension option when
+  registering the htmlize hooks, though.
+* Whole-file plugins register a bunch of htmlize hooks. The wacky thing
+  about it is that, when creating a new page, you can then pick "c" or
+  "h" or "pl" etc from the dropdown that normally has "mdwn" etc in it.
+  Is this a bug, or a feature? (Even if a feature, plugins with many
+  extensions make the dropdown unusable.. One way to deal with that is have
+  a config setting that lists what extensions to offer highlighting for.
+  Most people won't need/want the dozens some engines support.)
+* The per page highlighters can't handle creating wiki pages from 
+  "Makefile", or other files without a significant extension.
+  Not clear how to fix this, as ikiwiki is very oriented toward file
+  extensions. The workaround is to use a directive on a wiki page, pulling
+  in the Makefile.
+
+## format directive
+
+Rather than making syntax highlight plugins have to provide a preprocessor
+directive as well as handling whole source files, perhaps a generic format
+directive could be used:
+
+	\[[!format pl """..."""]]
+
+That would run the text through the pl htmlizer, from the syntax hightligh
+plugin. OTOH, if "rst" were given, it would run the text through the rst
+htmlizer. So, more generic, allows mixing different types of markup on one
+page, as well as syntax highlighting. Does require specifying the type of
+format, instead of allowing it to be guessed (which some syntax highlighters
+can do). (This directive is now implemented..)
+
+Hmm, this would also allow comments inside source files to have mdwn
+embedded in them, without making the use of mdwn a special case, or needing
+to postprocess the syntax highlighter output to find comments.
+
+	/* \[[!format mdwn """
+
+	This is a comment in my C file. You can use mdwn in here.
+
+	"""]] */
+
+Note that this assumes that directives are expanded in source files.
diff --git a/doc/todo/syntax_highlighting/discussion.mdwn b/doc/todo/syntax_highlighting/discussion.mdwn
new file mode 100644
index 000000000..7a4095c65
--- /dev/null
+++ b/doc/todo/syntax_highlighting/discussion.mdwn
@@ -0,0 +1,26 @@
+sourcehighlight is annoyingly slow, but it does support wiki directives 
+in comments. See [here](http://www.cs.unb.ca/~bremner/teaching/java_examples/snippet/ListMerge/)
+for an example (tags).
+
+> I think that is just a result of it expanding directives, and wikilinks,
+> everywhere in the file, which is generally a possible problem..
+> --[[Joey]]
+
+* * * * *
+
+I think having the option to choose source code page types from the
+dropdown list is definitely a feature.  This gives users an easy way
+to contribute programs (say `.pl` files) or code snippets (like, for
+example, the Elisp area of the EmacsWiki).  Actually, would there any
+other way to create a `.pl` file without write access to the
+repository?  --[[JasonBlevins]]
+
+> Well, you can upload them as an attachment if the wiki is configured to
+> allow it. Having them in the drop down becomes a problem when there are
+> so many wacky extensions in there that you can't find anything.
+> --[[Joey]]
+
+>> I should just note that the
+>> [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]
+>> plugin only adds the file extensions listed in the config.  This shouldn't cause
+>> massive drop-down menu pollution.  -- [[Will]]
diff --git a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
index 08ca61b0c..a5244c9ef 100644
--- a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
+++ b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
@@ -1 +1,4 @@
-[[Wishlist]] item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin.  This would allow the use of links and formatting in comments.
+[[Wishlist]] item: I'd love to see the ability to optionally switch back to
+wiki syntax within the comments of code pretty-printed with the
+[[plugins/contrib/syntax]] plugin.  This would allow the use of links and
+formatting in comments.