From 82c3f6d7f4c8dd00589ba3c039856d6620ec2456 Mon Sep 17 00:00:00 2001
From: chrysn <chrysn@fsfe.org>
Date: Sun, 29 Mar 2009 20:33:00 +0200
Subject: clarification on autotitle (todo title seems unclear in retrospect)

---
 doc/todo/inline_autotitles.mdwn          | 51 -------------------------------
 doc/todo/inline_postform_autotitles.mdwn | 52 ++++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+), 51 deletions(-)
 delete mode 100644 doc/todo/inline_autotitles.mdwn
 create mode 100644 doc/todo/inline_postform_autotitles.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/inline_autotitles.mdwn b/doc/todo/inline_autotitles.mdwn
deleted file mode 100644
index 8bf71deae..000000000
--- a/doc/todo/inline_autotitles.mdwn
+++ /dev/null
@@ -1,51 +0,0 @@
-[[!tag wishlist]]
-[[!tag patch]]
-
-for inlines of pages which follow a certain scheme, it might not be required to
-set the title for each individual post, but to automatically set the title.
-this can either be based on timestamp formatting, or use the already existing
-munging mechanism, which appends numbers to page titles in case that page
-already exists.
-
-two patches ([1], [2]) set inline up for that, adding an additional `autotitle`
-parameter. if that is given, the regular input of the inline postform will be
-replaced with a hidden input of that text. in addition, the empty title is
-permitted (both for autotitle and regular titles, as they go in the same GET
-parameter, `title`). as the empty page title is illegal, munging is used,
-resulting in ascending numeric page titles to be created.
-
-the second patch is actually a one-liner, filtering the title through strftime.
-
-### potential user interaction issues
-
-this has two side effects which have to be considered: first, the empty page
-title is accepted also in normal postforms (previously, this resulted in a "bad
-page name" error); second, entering a percent sign in that field might result
-in unexpexted strftime substitution (strftime might not even substitute for
-common uses of percent as in "reach 10% market share", but might in others as
-in "the 10%-rule").
-
-both can be circumvented by using another GET parameter for autotexts, as
-implemented in [3].
-> this patch still does not work perfectly; especially, it should make a
-> distinction between "autotitle is set but equal ''" (in which case it
-> should create a page named `1.mdwn`, and "autotitle is not set, and title is
-> equal ''" (in which case it should display the old error message) --[[chrysn]]
-
-### potential security issues
-
-* the autotitle's value is directly output through the template (but that's
-  done in other places as well, so i assume it's safe)
-* i don't know if anything bad can happen if unfiltered content is passed to
-  POSIX::strftime.
-
-### further extension
-
-having a pre-filled input field instead of an unchangable hidden input might be
-cool (eg for creating an entry with yesterday's date), but would be a bit of a
-problem with static pages. javascript could help with the date part, but name
-munging would be yet another thing.
-
-[1]: http://github.com/github076986099/ikiwiki/commit/b568eb257a3ef5ff49a84ac00a3a7465b643c1e1
-[2]: http://github.com/github076986099/ikiwiki/commit/34bc82f232be141edf036d35e8ef5aa289415072
-[3]: http://github.com/github076986099/ikiwiki/commit/40dc10a4ec7809e401b4497c2abccfba30f7a2af
diff --git a/doc/todo/inline_postform_autotitles.mdwn b/doc/todo/inline_postform_autotitles.mdwn
new file mode 100644
index 000000000..5005208be
--- /dev/null
+++ b/doc/todo/inline_postform_autotitles.mdwn
@@ -0,0 +1,52 @@
+[[!tag wishlist]]
+[[!tag patch]]
+
+for postforms in inlines of pages which follow a certain scheme, it might not
+be required to set the title for each individual post, but to automatically set
+the title and show no input box prompting for it.
+this can either be based on timestamp formatting, or use the already existing
+munging mechanism, which appends numbers to page titles in case that page
+already exists.
+
+two patches ([1], [2]) set inline up for that, adding an additional `autotitle`
+parameter. if that is given, the regular input of the inline postform will be
+replaced with a hidden input of that text. in addition, the empty title is
+permitted (both for autotitle and regular titles, as they go in the same GET
+parameter, `title`). as the empty page title is illegal, munging is used,
+resulting in ascending numeric page titles to be created.
+
+the second patch is actually a one-liner, filtering the title through strftime.
+
+### potential user interaction issues
+
+this has two side effects which have to be considered: first, the empty page
+title is accepted also in normal postforms (previously, this resulted in a "bad
+page name" error); second, entering a percent sign in that field might result
+in unexpexted strftime substitution (strftime might not even substitute for
+common uses of percent as in "reach 10% market share", but might in others as
+in "the 10%-rule").
+
+both can be circumvented by using another GET parameter for autotexts, as
+implemented in [3].
+> this patch still does not work perfectly; especially, it should make a
+> distinction between "autotitle is set but equal ''" (in which case it
+> should create a page named `1.mdwn`, and "autotitle is not set, and title is
+> equal ''" (in which case it should display the old error message) --[[chrysn]]
+
+### potential security issues
+
+* the autotitle's value is directly output through the template (but that's
+  done in other places as well, so i assume it's safe)
+* i don't know if anything bad can happen if unfiltered content is passed to
+  POSIX::strftime.
+
+### further extension
+
+having a pre-filled input field instead of an unchangable hidden input might be
+cool (eg for creating an entry with yesterday's date), but would be a bit of a
+problem with static pages. javascript could help with the date part, but name
+munging would be yet another thing.
+
+[1]: http://github.com/github076986099/ikiwiki/commit/b568eb257a3ef5ff49a84ac00a3a7465b643c1e1
+[2]: http://github.com/github076986099/ikiwiki/commit/34bc82f232be141edf036d35e8ef5aa289415072
+[3]: http://github.com/github076986099/ikiwiki/commit/40dc10a4ec7809e401b4497c2abccfba30f7a2af
-- 
cgit v1.2.3


From 3496eac54b05afd2c45c225e788a928bf4289704 Mon Sep 17 00:00:00 2001
From: Jon Dowland <jon@ncl.ac.uk>
Date: Wed, 1 Apr 2009 12:33:33 +0100
Subject: move managing todo lists to 'todo' section

---
 doc/forum/managing_todo_lists.mdwn | 44 ------------------------------
 doc/todo/managing_todo_lists.mdwn  | 55 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 44 deletions(-)
 delete mode 100644 doc/forum/managing_todo_lists.mdwn
 create mode 100644 doc/todo/managing_todo_lists.mdwn

(limited to 'doc/todo')

diff --git a/doc/forum/managing_todo_lists.mdwn b/doc/forum/managing_todo_lists.mdwn
deleted file mode 100644
index 0a69af805..000000000
--- a/doc/forum/managing_todo_lists.mdwn
+++ /dev/null
@@ -1,44 +0,0 @@
-I keep some TODO lists on ikiwiki pages. I'm half-tempted to write a plugin
-to make ticking items off and adding items easier via the web interface. I'm
-aware though that this is not really what ikiwiki is designed for. Would
-anyone else find this useful? -- [[users/jon]]
-
-----
-
-My subsequent thoughts about how to approach this are two-fold.
-
-Firstly, a filetype for todo lists, probably OPML, but I haven't looked to see
-if there is something more suitable. A plugin that converts this source into a
-traditional page output, i.e. a DOM tree of ul or ol and li elements.
-
-Secondly, some magic javascript to make editing the list via the web page 
-more interactive: add items, strike items out, reorder items etc., without
-round-tripping to the cgi for each operation.
-
-Finally, a mechanism whereby the changes made to the page live can be
-committed back to the repository:
-
- * ...perhaps the input → output conversion is reversible, and the HTML DOM
-   representing the list can be transformed back into the source and submitted
-   to the cgi like a regular edit: issues include the result of other
-   postprocessing: templates, wikilinks, etc.
- * perhaps an embedded copy of the source is included in the output and the
-   javascript operates on that in tandem with the static copy
-   * perhaps the "output" is generated live by the JS at view time (with maybe
-     a plugin-generated rendered output for non JS environments)
-
-I envisage a button called "commit changes" appearing once some changes are
-made that submits the changes to the CGI, perhaps via a back channel. I'm not
-sure how to handle embeds or challenges from the CGI such as a login challenge
-(maybe the back channel would not be necessary in the first cut).
-
-> You might look at the [[plugins/hnb]] plugin. HNB supports checklists.
-> There's not a fancy web interface, but the hnb command-line program can
-> be used to edit them. --[[Joey]] 
-
->> thanks - I'll give it a look. I spent a few hours writing some javascript to manipulate a ul/li DOM tree in an outliner-fashion the other day. I might be able to join the puzzle pieces together sometime. [[Jon]]
-
-a solution for this could be similar to a solution for [[todo/structured page data]], as todo lists are definitely a form of structured data. (in both cases, the page's current content is rendered into a html form, whose result is then saved as the page's new contents) --[[chrysn]]
-
-> Thanks for the link: yup, there's definitely some common ground there.
-> -- [[Jon]]
diff --git a/doc/todo/managing_todo_lists.mdwn b/doc/todo/managing_todo_lists.mdwn
new file mode 100644
index 000000000..846f2a4af
--- /dev/null
+++ b/doc/todo/managing_todo_lists.mdwn
@@ -0,0 +1,55 @@
+I keep some TODO lists on ikiwiki pages. I'm half-tempted to write a plugin
+to make ticking items off and adding items easier via the web interface. I'm
+aware though that this is not really what ikiwiki is designed for. Would
+anyone else find this useful? -- [[users/jon]]
+
+----
+
+My subsequent thoughts about how to approach this are two-fold.
+
+Firstly, a filetype for todo lists, probably OPML, but I haven't looked to see
+if there is something more suitable. A plugin that converts this source into a
+traditional page output, i.e. a DOM tree of ul or ol and li elements.
+
+Secondly, some magic javascript to make editing the list via the web page 
+more interactive: add items, strike items out, reorder items etc., without
+round-tripping to the cgi for each operation.
+
+Finally, a mechanism whereby the changes made to the page live can be
+committed back to the repository:
+
+ * ...perhaps the input → output conversion is reversible, and the HTML DOM
+   representing the list can be transformed back into the source and submitted
+   to the cgi like a regular edit: issues include the result of other
+   postprocessing: templates, wikilinks, etc.
+ * perhaps an embedded copy of the source is included in the output and the
+   javascript operates on that in tandem with the static copy
+   * perhaps the "output" is generated live by the JS at view time (with maybe
+     a plugin-generated rendered output for non JS environments)
+
+I envisage a button called "commit changes" appearing once some changes are
+made that submits the changes to the CGI, perhaps via a back channel. I'm not
+sure how to handle embeds or challenges from the CGI such as a login challenge
+(maybe the back channel would not be necessary in the first cut).
+
+> You might look at the [[plugins/hnb]] plugin. HNB supports checklists.
+> There's not a fancy web interface, but the hnb command-line program can
+> be used to edit them. --[[Joey]] 
+
+>> thanks - I'll give it a look. I spent a few hours writing some javascript to manipulate a ul/li DOM tree in an outliner-fashion the other day. I might be able to join the puzzle pieces together sometime. [[Jon]]
+
+a solution for this could be similar to a solution for [[todo/structured page data]], as todo lists are definitely a form of structured data. (in both cases, the page's current content is rendered into a html form, whose result is then saved as the page's new contents) --[[chrysn]]
+
+> Thanks for the link: yup, there's definitely some common ground there.
+> -- [[Jon]]
+
+----
+
+I had a little spare time in a conference recently so I hacked on this. I
+managed to get something working with anonok, a "markup format" that was
+essentially just UL and LI elements and some javascript.  I'll try and get an
+example up of that soon (and publish the code). There's still quite a lot of
+work necessary, but it's more than an idle thought at least!
+
+I've moved this page under the [[todo]] heirarchy as I'm actually working on
+this now. -- [[Jon]]
-- 
cgit v1.2.3


From 9a7e8096c09efdb7d36656ad6e4aae4dec49a39b Mon Sep 17 00:00:00 2001
From: Jon Dowland <jon@ncl.ac.uk>
Date: Wed, 1 Apr 2009 13:30:20 +0100
Subject: Revert "move managing todo lists to 'todo' section"

This reverts commit 3496eac54b05afd2c45c225e788a928bf4289704.

Rather than move the existing forum topic (and confuse anyone who expected to
find it there) I will create a new TODO item, structured more traditionally.
---
 doc/forum/managing_todo_lists.mdwn | 44 ++++++++++++++++++++++++++++++
 doc/todo/managing_todo_lists.mdwn  | 55 --------------------------------------
 2 files changed, 44 insertions(+), 55 deletions(-)
 create mode 100644 doc/forum/managing_todo_lists.mdwn
 delete mode 100644 doc/todo/managing_todo_lists.mdwn

(limited to 'doc/todo')

diff --git a/doc/forum/managing_todo_lists.mdwn b/doc/forum/managing_todo_lists.mdwn
new file mode 100644
index 000000000..0a69af805
--- /dev/null
+++ b/doc/forum/managing_todo_lists.mdwn
@@ -0,0 +1,44 @@
+I keep some TODO lists on ikiwiki pages. I'm half-tempted to write a plugin
+to make ticking items off and adding items easier via the web interface. I'm
+aware though that this is not really what ikiwiki is designed for. Would
+anyone else find this useful? -- [[users/jon]]
+
+----
+
+My subsequent thoughts about how to approach this are two-fold.
+
+Firstly, a filetype for todo lists, probably OPML, but I haven't looked to see
+if there is something more suitable. A plugin that converts this source into a
+traditional page output, i.e. a DOM tree of ul or ol and li elements.
+
+Secondly, some magic javascript to make editing the list via the web page 
+more interactive: add items, strike items out, reorder items etc., without
+round-tripping to the cgi for each operation.
+
+Finally, a mechanism whereby the changes made to the page live can be
+committed back to the repository:
+
+ * ...perhaps the input → output conversion is reversible, and the HTML DOM
+   representing the list can be transformed back into the source and submitted
+   to the cgi like a regular edit: issues include the result of other
+   postprocessing: templates, wikilinks, etc.
+ * perhaps an embedded copy of the source is included in the output and the
+   javascript operates on that in tandem with the static copy
+   * perhaps the "output" is generated live by the JS at view time (with maybe
+     a plugin-generated rendered output for non JS environments)
+
+I envisage a button called "commit changes" appearing once some changes are
+made that submits the changes to the CGI, perhaps via a back channel. I'm not
+sure how to handle embeds or challenges from the CGI such as a login challenge
+(maybe the back channel would not be necessary in the first cut).
+
+> You might look at the [[plugins/hnb]] plugin. HNB supports checklists.
+> There's not a fancy web interface, but the hnb command-line program can
+> be used to edit them. --[[Joey]] 
+
+>> thanks - I'll give it a look. I spent a few hours writing some javascript to manipulate a ul/li DOM tree in an outliner-fashion the other day. I might be able to join the puzzle pieces together sometime. [[Jon]]
+
+a solution for this could be similar to a solution for [[todo/structured page data]], as todo lists are definitely a form of structured data. (in both cases, the page's current content is rendered into a html form, whose result is then saved as the page's new contents) --[[chrysn]]
+
+> Thanks for the link: yup, there's definitely some common ground there.
+> -- [[Jon]]
diff --git a/doc/todo/managing_todo_lists.mdwn b/doc/todo/managing_todo_lists.mdwn
deleted file mode 100644
index 846f2a4af..000000000
--- a/doc/todo/managing_todo_lists.mdwn
+++ /dev/null
@@ -1,55 +0,0 @@
-I keep some TODO lists on ikiwiki pages. I'm half-tempted to write a plugin
-to make ticking items off and adding items easier via the web interface. I'm
-aware though that this is not really what ikiwiki is designed for. Would
-anyone else find this useful? -- [[users/jon]]
-
-----
-
-My subsequent thoughts about how to approach this are two-fold.
-
-Firstly, a filetype for todo lists, probably OPML, but I haven't looked to see
-if there is something more suitable. A plugin that converts this source into a
-traditional page output, i.e. a DOM tree of ul or ol and li elements.
-
-Secondly, some magic javascript to make editing the list via the web page 
-more interactive: add items, strike items out, reorder items etc., without
-round-tripping to the cgi for each operation.
-
-Finally, a mechanism whereby the changes made to the page live can be
-committed back to the repository:
-
- * ...perhaps the input → output conversion is reversible, and the HTML DOM
-   representing the list can be transformed back into the source and submitted
-   to the cgi like a regular edit: issues include the result of other
-   postprocessing: templates, wikilinks, etc.
- * perhaps an embedded copy of the source is included in the output and the
-   javascript operates on that in tandem with the static copy
-   * perhaps the "output" is generated live by the JS at view time (with maybe
-     a plugin-generated rendered output for non JS environments)
-
-I envisage a button called "commit changes" appearing once some changes are
-made that submits the changes to the CGI, perhaps via a back channel. I'm not
-sure how to handle embeds or challenges from the CGI such as a login challenge
-(maybe the back channel would not be necessary in the first cut).
-
-> You might look at the [[plugins/hnb]] plugin. HNB supports checklists.
-> There's not a fancy web interface, but the hnb command-line program can
-> be used to edit them. --[[Joey]] 
-
->> thanks - I'll give it a look. I spent a few hours writing some javascript to manipulate a ul/li DOM tree in an outliner-fashion the other day. I might be able to join the puzzle pieces together sometime. [[Jon]]
-
-a solution for this could be similar to a solution for [[todo/structured page data]], as todo lists are definitely a form of structured data. (in both cases, the page's current content is rendered into a html form, whose result is then saved as the page's new contents) --[[chrysn]]
-
-> Thanks for the link: yup, there's definitely some common ground there.
-> -- [[Jon]]
-
-----
-
-I had a little spare time in a conference recently so I hacked on this. I
-managed to get something working with anonok, a "markup format" that was
-essentially just UL and LI elements and some javascript.  I'll try and get an
-example up of that soon (and publish the code). There's still quite a lot of
-work necessary, but it's more than an idle thought at least!
-
-I've moved this page under the [[todo]] heirarchy as I'm actually working on
-this now. -- [[Jon]]
-- 
cgit v1.2.3


From f7037f4870c4a34becf32f4bd953d7d6ddcf556b Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@gnu.kitenet.net>
Date: Wed, 1 Apr 2009 13:47:41 -0400
Subject: happy Make Big Confusing Proposal Day

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

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
new file mode 100644
index 000000000..204c48cd7
--- /dev/null
+++ b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
@@ -0,0 +1,68 @@
+[[!tag wishlist blue-sky]]
+
+In the long term, I have been considering rewriting ikiwiki in haskell.
+It's appealing for a lot of reasons, including:
+
+* No need to depend on a C compiler and have wrappers. Instead, ikiwiki
+  binaries could be built on demand to do the things wrappers are used for
+  now (cgi, post-commit, etc).
+* Potentially much faster. One problem with the now very modular ikiwiki is
+  that it has to load up dozens of perl modules each time it runs, which
+  means both opening lots of files and evaluating them. A haskell version
+  could run from one pre-compiled file. Other speed efficienies are also
+  likely with haskell. For example, pandoc is apparently an order of
+  magnitude faster than perl markdown implementations.
+* Many plugins could be written in pure functional code, with no side
+  effects. Not all of them, of course.
+* It should be much easier to get ikiwiki to support parallel compilation
+  on multi-core systems using haskell.
+* A rewrite would be an opportunity to utterly break compatability and
+  redo things based on experience. Since the haskell libraries used for
+  markdown, templates, etc, are unlikely to be very compatable with the perl
+  versions, and since perl plugins obviously wouldn't work, and perl setup
+  files wouldn't be practical to keep, a lot of things would unavoidably
+  change, and at that point changinge everything else I can think of
+  probably wouldn't hurt (much).
+
+  - Re templates, it would be nice to have a template library that
+    doesn't use html-ish templating tags, since those are hard for users to
+    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).
+  - 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
+    general-purpose `--set var=value` flag.
+  - Sometimes the current behavior of `--setup` seems confusing; it might
+    only cause a setup file to be read, and not force rebuild mode.
+  - Hard to say how the very high level plugin interface design would change,
+    but at the least some of the names of hooks could stand a rename, and
+    their parameter passing cleaned up.
+
+We know that a big, break-the-world rewrite like this can be a very
+bad thing for a project to attempt. It would be possible to support
+external plugins written in haskell today, without any rewrite; and a few
+of the benefits could be obtained by, eg, making the mdwn plugin be a
+haskell program that uses pandoc. I doubt that wouod be a good first step
+to converting ikiwiki to haskell, because such a program would have very
+different data structures and intercommuniucation than a pure haskell
+version.
+
+Some other things to be scared about:
+
+* By picking perl, I made a lot of people annoyed (and probably turned
+  several people away from using ikiwiki). But over time there turned out
+  to be a lot of folks who knew perl already (even if rustily), and made
+  some *very* useful contributions. I doubt there's as large a pool of haskell
+  programmers, and it's probably harder for a python user to learn haskell
+  than perl if they want to contribute to ikiwiki.
+* It might be harder for users of hosting services to install a haskell based
+  ikiwiki than the perl version. Such systems probably don't have ghc and
+  a bunch of haskell libraries. OTOH, it might be possible to build a
+  static binary at home and upload it, thus avoiding a messy installation
+  procedure entirely.
+* I can barely code in haskell yet. I'm probably about 100x faster at
+  programming in perl. I need to get some more practical experience before
+  I´m fast and seasoned enough in haskell to attempt such a project.
+  (And so far, progress at learning has been slow and I have not managed
+  to write anything serious in haskell.) --[[Joey]] 
-- 
cgit v1.2.3


From 9b234fa7a58d0662368714e777eb7b6e818eeaa6 Mon Sep 17 00:00:00 2001
From: Jon Dowland <jondowland@alcopop.org>
Date: Wed, 1 Apr 2009 23:04:18 +0100
Subject: ncevy sbbyf?

---
 doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn | 3 +++
 1 file changed, 3 insertions(+)
 create mode 100644 doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
new file mode 100644
index 000000000..badd28a6d
--- /dev/null
+++ b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
@@ -0,0 +1,3 @@
+Ok, I have to admit, I have no idea if this is an April fool's joke or not.  
+Congratulations for demonstrating that April fools jokes can still be subtle
+(whether intentionally or not!) -- [[Jon]]
-- 
cgit v1.2.3


From e81e06641641f60629f24da93f1e2d64b3288f2a Mon Sep 17 00:00:00 2001
From: Jon Dowland <jon@alcopop.org>
Date: Wed, 1 Apr 2009 23:13:28 +0100
Subject: erlang/couchdb

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

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
index badd28a6d..a12a5fe27 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
@@ -1,3 +1,6 @@
 Ok, I have to admit, I have no idea if this is an April fool's joke or not.  
 Congratulations for demonstrating that April fools jokes can still be subtle
 (whether intentionally or not!) -- [[Jon]]
+
+> Having said all that, have you looked at erlang? Have you heard of couchdb?
+> I'd strongly recommend looking at that. -- [[Jon]]
-- 
cgit v1.2.3


From 0c67efb90e5965de5149902a402c74a58aaa7525 Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@gnu.kitenet.net>
Date: Wed, 1 Apr 2009 19:16:53 -0400
Subject: response

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

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
index a12a5fe27..5f33d0ae7 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
@@ -4,3 +4,6 @@ Congratulations for demonstrating that April fools jokes can still be subtle
 
 > Having said all that, have you looked at erlang? Have you heard of couchdb?
 > I'd strongly recommend looking at that. -- [[Jon]]
+
+>> I've glanced at couchdb, but don't see how it would tie in with ikiwiki.
+>> --[[Joey]] 
-- 
cgit v1.2.3


From 524827c3cf85e5aceb87a7a84fac196d07550e9f Mon Sep 17 00:00:00 2001
From: Jon Dowland <jon@ncl.ac.uk>
Date: Thu, 2 Apr 2009 09:31:50 +0100
Subject: response

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

(limited to 'doc/todo')

diff --git a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
index 5f33d0ae7..1edebe4e8 100644
--- a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
+++ b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
@@ -7,3 +7,8 @@ Congratulations for demonstrating that April fools jokes can still be subtle
 
 >> I've glanced at couchdb, but don't see how it would tie in with ikiwiki.
 >> --[[Joey]] 
+
+
+>>> It doesn't really. I recently (re-)read about couchdb and thought that
+>>> what it was trying to do had some comparisons with the thinking going on
+>>> in [[todo/structured_page_data]]. -- [[Jon]]
-- 
cgit v1.2.3


From ca5704936d1d57fdd11ea850608e6fa9d574d9dd Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@gnu.kitenet.net>
Date: Sat, 4 Apr 2009 18:04:20 -0400
Subject: update docs for darcs

Deleted all the old incomplete implementations.

Moved explanation of the two-repo system currently implemented for darcs
into rcs/details, and removed discussion from there about other methods
(including one-repo).

Wrote a rcs/darcs page, which I hope is accurate.
---
 doc/rcs/darcs.mdwn   |  15 ++
 doc/rcs/details.mdwn |  98 +---------
 doc/todo/darcs.mdwn  | 510 +--------------------------------------------------
 3 files changed, 29 insertions(+), 594 deletions(-)
 create mode 100644 doc/rcs/darcs.mdwn

(limited to 'doc/todo')

diff --git a/doc/rcs/darcs.mdwn b/doc/rcs/darcs.mdwn
new file mode 100644
index 000000000..7f66d0808
--- /dev/null
+++ b/doc/rcs/darcs.mdwn
@@ -0,0 +1,15 @@
+[Darcs](http://darcs.new) is a distributed revison control
+system. Ikiwiki supports storing a wiki in a
+Darcs repository.
+
+An Ikiwiki wrapper is run by the `posthook` to update a wiki whenever commits
+or remote pushes come in. When running as a [[cgi]] with Darcs, ikiwiki
+automatically commits edited pages, and uses the Darcs history to generate the
+[[RecentChanges]] page.
+
+Example for a `_darcs/prefs/defaults` file in `$SRCDIR`:
+
+	apply posthook /path/to/repository/_darcs/ikiwrapper
+	apply run-posthook
+
+See also [[todo/darcs|todo/darcs]]
diff --git a/doc/rcs/details.mdwn b/doc/rcs/details.mdwn
index 089221cab..00559a4dd 100644
--- a/doc/rcs/details.mdwn
+++ b/doc/rcs/details.mdwn
@@ -32,98 +32,20 @@ You browse and web-edit the wiki on W.
 W "belongs" to ikiwiki and should not be edited directly.
 
 
-## [darcs](http://darcs.net/) (not yet included)
+## [[darcs]]
 
-Support for using darcs as a backend is being worked on by [Thomas
-Schwinge](mailto:tschwinge@gnu.org), although development is on hold curretly.
-There is a patch in [[todo/darcs]].
+Regarding the repository layout: There are two darcs repositories. One is the `srcdir`, the other we'll call `master`.
 
-### How will it work internally?
+*  HTML is generated from `srcdir`.
+*  CGI edits happen in `srcdir`.
+*  The backend pulls updates from `master` into `srcdir`, i.e. darcs commits should happen to `master`.
+*  `master` calls ikiwiki (through a wrapper) in its apply posthook, i.e. `master/_darcs/prefs/defaults` should look like this:
 
-``Master'' repository R1.
-
-RCS commits from the outside are installed into R1.
-
-HTML is generated from R1.  HTML is automatically generated (by using a
-``post-hook'') each time a new change is installed into R1.  It follows
-that rcs_update() is not needed.
-
-There is a working copy of R1: R2.
-
-CGI operates on R2.  rcs_commit() will push from R2 to R1.
-
-You browse the wiki on R1 and web-edit it on R2.  This means for example
-that R2 needs to be updated from R1 if you are going to web-edit a page,
-as the user otherwise might be irritated otherwise...
-
-How do changes get from R1 to R2?  Currently only internally in
-rcs\_commit().  Is rcs\_prepedit() suitable?
-
-It follows that the HTML rendering and the CGI handling can be completely
-separated parts in ikiwiki.
-
-What repository should [[RecentChanges]] and History work on?  R1?
-
-#### Rationale for doing it differently than in the Subversion case
-
-darcs is a distributed RCS, which means that every checkout of a
-repository is equal to the repository it was checked-out from.  There is
-no forced hierarchy.
-
-R1 is nevertheless called the master repository.  It's used for
-collecting all the changes and publishing them: on the one hand via the
-rendered HTML and on the other via the standard darcs RCS interface.
-
-R2, the repository the CGI operates on, is just a checkout of R1 and
-doesn't really differ from the other checkouts that people will branch
-off from R1.
-
-(To be continued.)
-
-#### Another possible approach
-
-Here's what I (tuomov) think, would be a “cleaner” approach:
-
- 1. Upon starting to edit, Ikiwiki gets a copy of the page, and `darcs changes --context`.
-     This context _and_ the present version of the page are stored in as the “version” of the
-     page in a hidden control of the HTML.
-     Thus the HTML includes all that is needed to generate a patch wrt. to the state of the
-     repository at the time the edit was started. This is of course all that darcs needs.
- 2. Once the user is done with editing, _Ikiwiki generates a patch bundle_ for darcs.
-     This should be easy with existing `Text::Diff` or somesuch modules, as the Web edits
-     only concern single files. The reason why the old version of the page is stored in
-     the HTML (possibly compressed) is that the diff can be generated.
- 3. Now this patch bundle is applied with `darcs apply`, or sent by email for moderation…
-     there are many possibilities.
-
-This approach avoids some of the problems of concurrent edits that the previous one may have,
-although there may be conflicts, which may or may not propagate to the displayed web page.
-(Unfortunately there is not an option to `darcs apply` to generate some sort of ‘confliction resolution
-bundle’.) Also, only one repository is needed, as it is never directly modified
-by Ikiwiki. 
-
-This approach might be applicable to other distributed VCSs as well, although they're not as oriented
-towards transmitting changes with standalone patch bundles (often by email) as darcs is.
-
-> The mercurial plugin seems to just use one repo and edit it directly - is
-> there some reason that's okay there but not for darcs? I agree with tuomov
-> that having just the one repo would be preferable; the point of a dvcs is
-> that there's no difference between one repo and another. I've got a
-> darcs.pm based on mercurial.pm, that's almost usable... --bma
-
->> IMHO it comes down to whatever works well for a given RCS. Seems like
->> the darcs approach _could_ be done with most any distributed system, but
->> it might be overkill for some (or all?) While there is the incomplete darcs
->> plugin in [[todo/darcs]], if you submit one that's complete, I will
->> probably accept it into ikiwiki.. --[[Joey]]
-
->>> I'd like to help make a robust darcs (2) backend. I also think ikiwiki should use 
->>> exactly one darcs repo. I think we can simplify and say conflicting web
->>> edits are not allowed, like most current wiki engines. I don't see that 
->>> saving (so much) context in the html is necessary, then. 
->>> bma, I would like to see your code. --[[Simon_Michael]]
->>> PS ah, there it is. Let's continue on the [[todo/darcs]] page.
+	apply posthook ikiwrap
+	apply run-posthook
 
+*  The backend pushes CGI edits from `srcdir` back into `master` (triggering the apply hook).
+*  The working copies in `srcdir` and `master` should *not* be touched by the user, only by the CGI or darcs, respectively.
 
 ## [[Git]]
 
diff --git a/doc/todo/darcs.mdwn b/doc/todo/darcs.mdwn
index 882a41379..f721e15c5 100644
--- a/doc/todo/darcs.mdwn
+++ b/doc/todo/darcs.mdwn
@@ -1,513 +1,9 @@
-Here's Thomas Schwinge unfinished darcs support for ikiwiki.
-
-(Finishing this has been suggested as a [[soc]] project.)
-
-> I haven't been working on this for months and also won't in the near
-> future.  Feel free to use what I have done so
-> far and bring it into an usable state!  Also, feel free to contact me
->  if there are questions.
-
--- [Thomas Schwinge](mailto:tschwinge@gnu.org)
-
-[[!toggle text="show"]]
-[[!toggleable text="""
-	# Support for the darcs rcs, <URL:http://darcs.net/>.
-	# Copyright (C) 2006  Thomas Schwinge <tschwinge@gnu.org>
-	#
-	# This program is free software; you can redistribute it and/or modify it
-	# under the terms of the GNU General Public License as published by the
-	# Free Software Foundation; either version 2 of the License, or (at your
-	# option) any later version.
-	#
-	# This program is distributed in the hope that it will be useful, but
-	# WITHOUT ANY WARRANTY; without even the implied warranty of
-	# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-	# General Public License for more details.
-	#
-	# You should have received a copy of the GNU General Public License along
-	# with this program; if not, write to the Free Software Foundation, Inc.,
-	# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
-	
-	
-	# We're guaranteed to be the only instance of ikiwiki running at a given
-	# time.  It is essential that only ikiwiki is working on a particular
-	# repository.  That means one instance of ikiwiki and it also means that
-	# you must not `darcs push' into this repository, as this might create
-	# race conditions, as I understand it.
-	
-	
-	use warnings;
-	use strict;
-	use IkiWiki;
-	
-	package IkiWiki;
-	
-	
-	# Which darcs executable to use.
-	my $darcs = ($ENV{DARCS} or 'darcs');
-	
-	
-	# Internal functions.
-	
-	sub darcs_info ($$$) {
-	    my $field = shift;
-	    my $repodir = shift;
-	    my $file = shift; # Relative to the repodir.
-	
-	    my $child = open(DARCS_CHANGES, "-|");
-	    if (! $child) {
-		exec($darcs, 'changes', '--repo=' . $repodir, '--xml-output', $file) or
-		    error('failed to run `darcs changes\'');
-	    }
-	
-	    # Brute force for now.  :-/
-	    while (<DARCS_CHANGES>) {
-		last if /^<\/created_as>$/;
-	    }
-	    ($_) = <DARCS_CHANGES> =~ /$field=\'([^\']+)/;
-	    $field eq 'hash' and s/\.gz//; # Strip away the `.gz' from `hash'es.
-	
-	    close(DARCS_CHANGES) or error('`darcs changes\' exited ' . $?);
-	
-	    return $_;
-	}
-	
-	
-	# Exported functions.
-	
-	sub rcs_update () {
-	    # Not needed.
-	}
-	
-	sub rcs_prepedit ($) {
-	    # Prepares to edit a file under revision control.  Returns a token that
-	    # must be passed to rcs_commit() when the file is to be commited.  For us,
-	    # this token the hash value of the latest patch that modifies the file,
-	    # i.e. something like its current revision.  If the file is not yet added
-	    # to the repository, we return TODO: the empty string.
-	
-	    my $file = shift; # Relative to the repodir.
-	
-	    my $hash = darcs_info('hash', $config{srcdir}, $file);
-	    return defined $hash ? $hash : "";
-	}
-	
-	sub rcs_commit ($$$) {
-	    # Commit the page.  Returns `undef' on success and a version of the page
-	    # with conflict markers on failure.
-	
-	    my $file = shift; # Relative to the repodir.
-	    my $message = shift;
-	    my $rcstoken = shift;
-	
-	    # Compute if the ``revision'' of $file changed.
-	    my $changed = darcs_info('hash', $config{srcdir}, $file) ne $rcstoken;
-	
-	    # Yes, the following is a bit convoluted.
-	    if ($changed) {
-		# TODO.  Invent a better, non-conflicting name.
-		rename("$config{srcdir}/$file", "$config{srcdir}/$file.save") or
-		    error("failed to rename $file to $file.save: $!");
-	
-		# Roll the repository back to $rcstoken.
-	
-		# TODO.  Can we be sure that no changes are lost?  I think that
-		# we can, if we make sure that the `darcs push' below will always
-		# succeed.
-	
-		# We need to revert everything as `darcs obliterate' might choke
-		# otherwise.
-	        # TODO: `yes | ...' needed?  Doesn't seem so.
-		system($darcs, "revert", "--repodir=" . $config{srcdir}, "--all") and
-		    error("`darcs revert' failed");
-		# Remove all patches starting at $rcstoken.
-		# TODO.  Something like `yes | darcs obliterate ...' seems to be needed.
-		system($darcs, "obliterate", "--quiet", "--repodir" . $config{srcdir},
-		       "--match", "hash " . $rcstoken) and
-			   error("`darcs obliterate' failed");
-		# Restore the $rcstoken one.
-		system($darcs, "pull", "--quiet", "--repodir=" . $config{srcdir},
-		       "--match", "hash " . $rcstoken, "--all") and
-			   error("`darcs pull' failed");
-	
-		# We're back at $rcstoken.  Re-install the modified file.
-		rename("$config{srcdir}/$file.save", "$config{srcdir}/$file") or
-		    error("failed to rename $file.save to $file: $!");
-	    }
-	
-	    # Record the changes.
-	    # TODO: What if $message is empty?
-	    writefile("$file.log", $config{srcdir}, $message);
-	    system($darcs, 'record', '--repodir=' . $config{srcdir}, '--all',
-		   '--logfile=' . "$config{srcdir}/$file.log",
-		   '--author=' . 'web commit <web-hurd@gnu.org>', $file) and
-		       error('`darcs record\' failed');
-	
-	    # Update the repository by pulling from the default repository, which is
-	    # master repository.
-	    system($darcs, "pull", "--quiet", "--repodir=" . $config{srcdir},
-		   "--all") and error("`darcs pull' failed\n");
-	
-	    # If this updating yields any conflicts, we'll record them now to resolve
-	    # them.  If nothing is recorded, there are no conflicts.
-	    $rcstoken = darcs_info('hash', $config{srcdir}, $file);
-	    # TODO: Use only the first line here, i.e. only the patch name?
-	    writefile("$file.log", $config{srcdir}, 'resolve conflicts: ' . $message);
-	    system($darcs, 'record', '--repodir=' . $config{srcdir}, '--all',
-		   '--logfile=' . "$config{srcdir}/$file.log",
-		   '--author=' . 'web commit <web-hurd@gnu.org>', $file) and
-		       error('`darcs record\' failed');
-	    my $conflicts = darcs_info('hash', $config{srcdir}, $file) ne $rcstoken;
-	    unlink("$config{srcdir}/$file.log") or
-		error("failed to remove `$file.log'");
-	
-	    # Push the changes to the main repository.
-	    system($darcs, 'push', '--quiet', '--repodir=' . $config{srcdir}, '--all')
-		and error('`darcs push\' failed');
-	    # TODO: darcs send?
-	
-	    if ($conflicts) {
-		my $document = readfile("$config{srcdir}/$file");
-		# Try to leave everything in a consistent state.
-	        # TODO: `yes | ...' needed?  Doesn't seem so.
-		system($darcs, "revert", "--repodir=" . $config{srcdir}, "--all") and
-		    warn("`darcs revert' failed.\n");
-		return $document;
-	    } else {
-		return undef;
-	    }
-	}
-	
-	sub rcs_add ($) {
-	    my $file = shift; # Relative to the repodir.
-	
-	    # Intermediate directories will be added automagically.
-	    system($darcs, 'add', '--quiet', '--repodir=' . $config{srcdir},
-		   '--boring', $file) and error('`darcs add\' failed');
-	}
-	
-	sub rcs_recentchanges ($) {
-	    warn('rcs_recentchanges() is not implemented');
-	    return 'rcs_recentchanges() is not implemented';
-	}
-	
-	sub rcs_notify () {
-	    warn('rcs_notify() is not implemented');
-	}
-	
-	sub rcs_getctime () {
-	    warn('rcs_getctime() is not implemented');
-	}
-	
-	1
-"""]]
-
-This is my ([bma](bma@bmalee.eu)) darcs.pm - it's messy (my Perl isn't up to much) but seems to work. It uses just one repo, like the mercurial plugin (unlike the above version, which AIUI uses two).
-
-`rcs_commit()` uses backticks instead of `system()`, to prevent darcs' output being sent to the browser and mucking with the HTTP headers (`darcs record` has no --quiet option). And `rcs_recentchanges()` uses regexes rather than parsing darcs' XML output.
-
-[[!toggle text="show" id="bma"]]
-[[!toggleable id="bma" text="""
-
-	#!/usr/bin/perl
-	
-	use warnings;
-	use strict;
-	use IkiWiki;
-	use Date::Parse;
-	use open qw{:utf8 :std};
-	
-	package IkiWiki;
-	
-	sub rcs_update () {
-		# Do nothing - there's nowhere to update *from*.
-	}
-	
-	sub rcs_prepedit ($) {
-	}
-	
-	sub rcs_commit ($$$;$$) {
-		my ($file, $message, $rcstoken, $user, $ipaddr) = @_;
-	
-		# $user should probably be a name and an email address, by darcs
-		# convention.
-		if (defined $user) {
-			$user = possibly_foolish_untaint($user);
-		}
-		elsif (defined $ipaddr) {
-			$user = "Anonymous from $ipaddr";
-		}
-		else {
-			$user = "Anonymous";
-		}
-	
-		$message = possibly_foolish_untaint($message);
-		
-		# BUG: this outputs one line of text, and there's not a -q or --quiet
-		# option. Redirecting output to /dev/null works, but I still get the
-		# HTTP status and location headers displayed in the browser - is that
-		# darcs' fault or ikiwiki's?
-		# Doing it in backticks *works*, but I'm sure it could be done better.
-		my @cmdline = ("darcs", "record", "--repodir", "$config{srcdir}",
-		               "-a", "-m", "$message", "--author", "$user", $file);
-		`darcs record --repodir "$config{srcdir}" -a -m "$message" --author "$user" $file`; # Return value? Output? Who needs 'em?
-		#if (system(@cmdline) != 0) {
-		#	warn "'@cmdline' failed: $!";
-		#}
-	
-		return undef; # success
-		
-	sub rcs_add ($) {
-		my ($file) = @_;
-	
-		my @cmdline = ("darcs", "add", "--repodir", "$config{srcdir}", "-a", "-q", "$file");
-		if (system(@cmdline) != 0) {
-			warn "'@cmdline' failed: $!";
-		}
-	}
-	
-	sub rcs_recentchanges ($) {
-		# TODO: This is horrible code. It doesn't work perfectly, and uses regexes
-		# rather than parsing Darcs' XML output.
-		my $num=shift;
-		my @ret;
-		
-		return unless -d "$config{srcdir}/_darcs";
-	
-		my $changelog = `darcs changes --xml --summary --repodir "$config{srcdir}"`;
-		$changelog = join("", split(/\s*\n\s*/, $changelog));
-		my @changes = split(/<\/patch>.*?<patch/m, $changelog);
-	
-	
-		foreach my $change (@changes) {
-			$change =~ m/hash='(.*?)'/;
-			my $rev = $1;
-			$change =~ m/author='(.*?)'/;
-			my $user = $1."\n";
-			my $committype = "web";
-			if($user =~ m/&lt;/) {
-				# Author fields generated by darcs include an email address: look for the "<".
-				$committype = "darcs";
-				use HTML::Entities;
-				$user = decode_entities $user;
-			}
-			$change =~ m/local_date='(.*?)'/;
-			my $when = $1;
-			$when=time - str2time($when, 'UTC');
-			$change =~ m/<name>(.*?)<\/name>/g;
-			my @message = {line => $1};
-			foreach my $match ($change =~ m/<comment>(.*?)<\/comment>/gm) {
-				push @message, {line => $1};
-			}
-
-			my @pages;
-			foreach my $match ($change =~ m/<.*?_(file|directory)>(.*?)(<(added|removed)_lines.*\/>)*<\/.*?_(file|directory)>/g) {
-				# My perl-fu is weak. I'm probably going about this all wrong, anyway.
-				push @pages, {page => pagename($match)} if ( -f $config{srcdir}."/".$match || -d $config{srcdir}."/".$match) and not $match =~ m/^$/;
-			}
-			push @ret, { rev => $rev,
-					user => $user,
-					committype => $committype,
-					when => $when,
-					message => [@message],
-					pages => [@pages],
-				}
-		}
-		return @ret;
-	}
-	
-	sub rcs_notify () {
-		# TODO
-	}
-	
-	sub rcs_getctime ($) {
-		error gettext("getctime not implemented");
-	}
-	
-	1
-
-
-
-"""]]
-
----
-
-Well, here's my version too. It only does getctime -- using a real XML parser, instead of regexp ugliness -- and maybe recentchanges, but that may be bitrotted, or maybe I never finished it, as I only need the getctime. As for actual commits, I have previously voiced my opinion, that this should be done by the plugin generating a patch bundle, and forwarding it to darcs in some way (`darcs apply` or even email to another host, possibly moderated), instead of the hacky direct modification of a working copy. It could also be faster to getctime in a batch. Just reading in all the changes the first time they're needed, might not be a big improvement in many cases, but if we got a batch request from ikiwiki, we could keep reaing the changes until all the files in this batch request have been met.  --[[tuomov]]
-
-[[!toggle text="show" id="tuomov"]]
-[[!toggleable id="tuomov" text="""
-<pre>
-#!/usr/bin/perl
-# Stubs for no revision control.
-
-use warnings;
-use strict;
-use IkiWiki;
-
-package IkiWiki;
-
-sub rcs_update () {
-}
-
-sub rcs_prepedit ($) {
-	return ""
-}
-
-sub rcs_commit ($$$) {
-	return undef # success
-}
-
-sub rcs_add ($) {
-}
-
-sub rcs_recentchanges ($) {
-	my $num=shift;
-	my @ret;
-	
-	eval q{use Date::Parse};
-	eval q{use XML::Simple};
-	
-	my $repodir=$config{srcdir};
-	
-	if (-d "$config{srcdir}/_darcs") {
-		my $child = open(LOG, "-|");
-		if (! $child) {
-			exec("darcs", "changes", "--xml", 
-			     "--repodir", "$repodir",
-			     "--last", "$num")
-			|| error("darcs changes failed to run");
-		}
-		my $data=<LOG>;
-		close LOG;
-		
-		my $log = XMLin($data, ForceArray => 1);
-		
-		foreach my $patch ($log->{patch}) {
-			my $date=$patch->{local_date};
-			my $hash=$patch->{hash};
-			my $when=concise(ago(time - str2time($date)));
-			my @pages;
-			
-			my $child = open(SUMMARY, "-|");
-			if (! $child) {
-				exec("darcs", "annotate", "-s", "--xml", 
-				     "--match", "hash: $hash",
-				     "--repodir", "$repodir")
-				|| error("darcs annotate failed to run");
-			}
-			my $data=<SUMMARY>;
-			close SUMMARY;
-		
-			my $summary = XMLin("<lame>$data</lame>", ForceArray => 1);
-
-			# TODO: find @pages
-			
-			push @ret, {
-				#rev => $rev,
-				user => $patch->{author},
-				#committype => $committype,
-				when => $when, 
-				#message => [@message],
-				pages => [@pages],
-			}; # if @pages;
-			return @ret if @ret >= $num;
-		}
-	}
-	
-	return @ret;
-}
-
-sub rcs_notify () {
-}
-
-sub rcs_getctime ($) {
-	my $file=shift;
-	
-	eval q{use Date::Parse};
-	eval q{use XML::Simple};
-	local $/=undef;
-	
-	# Sigh... doing things the hard way again
-	my $repodir=$config{srcdir};
-	
-	my $filer=substr($file, length($repodir));
-	$filer =~ s:^[/]+::;
-	
-	my $child = open(LOG, "-|");
-	if (! $child) {
-		exec("darcs", "changes", "--xml", "--reverse",
-		     "--repodir", "$repodir", "$filer")
-		|| error("darcs changes $filer failed to run");
-	}
-	
-	my $data=<LOG>;
-	close LOG;
-	
-	my $log = XMLin($data, ForceArray => 1);
-	
-	my $datestr=$log->{patch}[0]->{local_date};
-	
-	if (! defined $datestr) {
-		warn "failed to get ctime for $filer";
-		return 0;
-	}
-	
-	my $date=str2time($datestr);
-	
-	debug("found ctime ".localtime($date)." for $file");
-	
-	return $date;
-}
-
-1
-</pre>
-"""]]
-
----
-
-I merged the two versions above and made some fixes; it is recording my web edits in darcs and showing a recent changes page.
-It is in a [darcs repository](http://joyful.com/darcsweb/darcsweb.cgi?r=ikiwiki-darcs), please send patches. --[[Simon_Michael]]
-
-> I'd like to see at least the following fixed before I commit this: --[[Joey]]
-> * Running `darcs record $filename` in backticks is not good (security)
->   The thing to do is to open stdout to /dev/null before execing darcs.
-> * Get `rcs_recentchanges_xml` working, parsing xml with regexps does
->   not seem like a maintenance win.
-> * `rcs_notify` should be removed, it's no longer used.
-> * Some form of conflict handling. Using darcs to attempt to merge
->   the changes is I gusss optional (although every other rcs backend,
->   including svn manages to do this), but it needs to at *least* detect
->   conflicts and return a page with conflict markers for the user to fix
->   the conflict.
-
-I have addressed the recentchanges bit, you can find my hacked up darcs.pm at <http://web.mornfall.net/stuff/web-root/IkiWiki/Rcs/darcs.pm>.
-
-It's got couple of FIXMEs, and a very site-specific filter for recentchanges. Not sure how to do that better though. I will eventually add web commits, probably of my own (and mention it here).
-
----
-
-And here's yet another one, including an updated `ikiwiki-makerepo`. :)
-
 <http://khjk.org/~pesco/ikiwiki-darcs/> (now a darcs repo)
 
 > Note that there's a 'darcs' branch in git that I'm keeping a copy of your
 > code in. Just in case. :-)
 
-I've taken all the good stuff from the above and added the missing hooks. The code hasn't seen a lot of testing, so some bugs are likely yet to surface. Also, I'm not experienced with perl and don't know where I should have used the function `possibly_foolish_untaint`.
-
-Regarding the repository layout: There are two darcs repositories. One is the `srcdir`, the other we'll call `master`.
-
- *  HTML is generated from `srcdir`.
- *  CGI edits happen in `srcdir`.
- *  The backend pulls updates from `master` into `srcdir`, i.e. darcs commits should happen to `master`.
- *  `master` calls ikiwiki (through a wrapper) in its apply posthook, i.e. `master/_darcs/prefs/defaults` should look like this:
-
-        apply posthook ikiwrap
-        apply run-posthook
-
-    (I'm not sure, should/could it be `ikiwrap --refresh` above?)
- *  The backend pushes CGI edits from `srcdir` back into `master` (triggering the apply hook).
- *  The working copies in `srcdir` and `master` should *not* be touched by the user, only by the CGI or darcs, respectively.
+I've taken all the good stuff from the above (now deleted --[[Joey]]) and added the missing hooks. The code hasn't seen a lot of testing, so some bugs are likely yet to surface. Also, I'm not experienced with perl and don't know where I should have used the function `possibly_foolish_untaint`.
 
 > Review of this one:
 > 
@@ -523,7 +19,7 @@ Regarding the repository layout: There are two darcs repositories. One is the `s
 > * `rcs_remove` just calls "rm"? Does darcs record notice the file was removed
 >    and automatically commit the removal? (And why `system("rm")` and not
 >    `unlink`?)
-> * Is the the darcs info in [[details]] still up-to-date re this version?
+> * Is the the darcs info in [[rcs/details]] still up-to-date re this version?
 > --[[Joey]]
 
 > Update:
@@ -537,6 +33,8 @@ Regarding the repository layout: There are two darcs repositories. One is the `s
 > this version works. It's similar, but the details differ slightly.
 > You could copy my description above to replace it.
 >
+>> done --[[Joey]] 
+> 
 > There is still some ironing to do, for instance the current version doesn't allow for
 > modifying attachments by re-uploading them via CGI ("darcs add failed"). Am I assuming
 > correctly that "adding" a file that's already in the repo should just be a no-op?
-- 
cgit v1.2.3


From 3c17adea550608cde14f54dae5964d55fa3fe79d Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@gnu.kitenet.net>
Date: Sat, 4 Apr 2009 18:11:28 -0400
Subject: update

---
 doc/todo/darcs.mdwn | 26 +++++++++++++++-----------
 1 file changed, 15 insertions(+), 11 deletions(-)

(limited to 'doc/todo')

diff --git a/doc/todo/darcs.mdwn b/doc/todo/darcs.mdwn
index f721e15c5..985ae5f8b 100644
--- a/doc/todo/darcs.mdwn
+++ b/doc/todo/darcs.mdwn
@@ -1,25 +1,21 @@
 <http://khjk.org/~pesco/ikiwiki-darcs/> (now a darcs repo)
 
-> Note that there's a 'darcs' branch in git that I'm keeping a copy of your
-> code in. Just in case. :-)
-
 I've taken all the good stuff from the above (now deleted --[[Joey]]) and added the missing hooks. The code hasn't seen a lot of testing, so some bugs are likely yet to surface. Also, I'm not experienced with perl and don't know where I should have used the function `possibly_foolish_untaint`.
 
 > Review of this one:
 > 
-> * Should use tab indentation.
+> * Should use tab indentation. (fixed)
 > * `rcs_getctime` should not need to use a ctime cache (such a cache should 
 >   also not be named `.ikiwiki.ctimes`). `rcs_getctime` is run exactly
->   once per page, ever, and the data is cached in ikiwiki's index.
+>   once per page, ever, and the data is cached in ikiwiki's index. (fixed)
 > * I doubt that ENV{DARCS} will be available, since the wrapper clobbers> the entire
->   environment. I'd say remove that.
+>   environment. I'd say remove that. (fixed)
 > * I don't understand what `darcs_info` is doing, but it seems to be
 >   parsing xml with a regexp?
 > * Looks like `rcs_commit` needs a few improvements, as marked TODO
-> * `rcs_remove` just calls "rm"? Does darcs record notice the file was removed
->    and automatically commit the removal? (And why `system("rm")` and not
->    `unlink`?)
-> * Is the the darcs info in [[rcs/details]] still up-to-date re this version?
+> * `rcs_remove` just calls unlink? Does darcs record notice the file was removed
+>    and automatically commit the removal?
+> * Is the the darcs info in [[rcs/details]] still up-to-date re this version? (fixed)
 > --[[Joey]]
 
 > Update:
@@ -46,4 +42,12 @@ I've taken all the good stuff from the above (now deleted --[[Joey]]) and added
 
 >>> Done. --pesco
 
-[[!tag patch]]
+----
+
+I've finally merged this into ikiwiki master. The plugin looks quite
+complete, with only the new `rcs_receive` hook missing, and I
+hope it works as good as it looks. :) If anyone wants to work on improving
+it, there are some TODOs as mentioned above that could still be improved.
+--[[Joey]] 
+
+[[!tag patch done]]
-- 
cgit v1.2.3


From 495113cf54659a82bdb57bc0c5c965440ee420dc Mon Sep 17 00:00:00 2001
From: Enno <Enno@web>
Date: Sat, 4 Apr 2009 21:53:37 -0400
Subject:

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

(limited to 'doc/todo')

diff --git a/doc/todo/hidden_links__47__tags.mdwn b/doc/todo/hidden_links__47__tags.mdwn
new file mode 100644
index 000000000..8e24cefba
--- /dev/null
+++ b/doc/todo/hidden_links__47__tags.mdwn
@@ -0,0 +1,6 @@
+[[!tag wishlist]]
+
+I would like to have the possibility for hidden tags or links.
+Using the tag functionality I could group some news items for including them into other subpages. But I don't want the links or tags to show (and I don't want Tag lists like "Tags: ?mytag").
+The tagged items should not differ from the items, that are not tagged.  
+I didn't find any way to hide the tag list or links and I don't want to have to create a "hidden" page containing links to the pages and then using the backlink functionality, because this is more prone to errors. It's easier to forget adding a link on a second page than forgetting to add a needed tag to a new newsitem.
-- 
cgit v1.2.3


From 917210430ad3a90c22b2780eed18b4da4ea22d24 Mon Sep 17 00:00:00 2001
From: Enno <Enno@web>
Date: Sun, 5 Apr 2009 18:29:09 -0400
Subject:

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

(limited to 'doc/todo')

diff --git a/doc/todo/hidden_links__47__tags.mdwn b/doc/todo/hidden_links__47__tags.mdwn
index 8e24cefba..608cb3e6b 100644
--- a/doc/todo/hidden_links__47__tags.mdwn
+++ b/doc/todo/hidden_links__47__tags.mdwn
@@ -3,4 +3,7 @@
 I would like to have the possibility for hidden tags or links.
 Using the tag functionality I could group some news items for including them into other subpages. But I don't want the links or tags to show (and I don't want Tag lists like "Tags: ?mytag").
 The tagged items should not differ from the items, that are not tagged.  
-I didn't find any way to hide the tag list or links and I don't want to have to create a "hidden" page containing links to the pages and then using the backlink functionality, because this is more prone to errors. It's easier to forget adding a link on a second page than forgetting to add a needed tag to a new newsitem.
+I didn't find any way to hide the tag list or links and I don't want to have to create a "hidden" page containing links to the pages and then using the backlink functionality, because this is more prone to errors. It's easier to forget adding a link on a second page than forgetting to add a needed tag to a new newsitem.  
+
+> I found out, that using the meta plugin it is possible to create the hidden link, that I wanted.  
+-- [[users/Enno]]
-- 
cgit v1.2.3


From 51887c0733535a57d3959f20f36e99139a579350 Mon Sep 17 00:00:00 2001
From: Joey Hess <joey@gnu.kitenet.net>
Date: Thu, 9 Apr 2009 15:11:23 -0400
Subject: close

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

(limited to 'doc/todo')

diff --git a/doc/todo/hidden_links__47__tags.mdwn b/doc/todo/hidden_links__47__tags.mdwn
index 608cb3e6b..43d7a8797 100644
--- a/doc/todo/hidden_links__47__tags.mdwn
+++ b/doc/todo/hidden_links__47__tags.mdwn
@@ -7,3 +7,7 @@ I didn't find any way to hide the tag list or links and I don't want to have to
 
 > I found out, that using the meta plugin it is possible to create the hidden link, that I wanted.  
 -- [[users/Enno]]
+
+>> Yes, meta link will not show up as a visible link on the page, while
+>> also not showing up in the list of tags of a page, so it seems what you
+>> want. [[done]] --[[Joey]] 
-- 
cgit v1.2.3