summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/Allow_edittemplate_to_set_file_type.mdwn4
-rw-r--r--doc/todo/Better_bug_tracking_support.mdwn13
-rw-r--r--doc/todo/Feature_parity_with_Trac.mdwn3
-rw-r--r--doc/todo/Location_of_pages_starting_with___36__tagbase_should_be_in__by_default.mdwn2
-rw-r--r--doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn159
-rw-r--r--doc/todo/inline:_numerical_ordering_by_title.mdwn178
-rw-r--r--doc/todo/source_link.mdwn101
-rw-r--r--doc/todo/structured_page_data.mdwn83
-rw-r--r--doc/todo/supporting_comments_via_disussion_pages.mdwn31
-rw-r--r--doc/todo/tracking_bugs_with_dependencies.mdwn58
-rw-r--r--doc/todo/turn_edittemplate_verbosity_off_by_default.mdwn4
-rw-r--r--doc/todo/wikitrails.mdwn41
-rw-r--r--doc/todo/wikitrails/discussion.mdwn24
13 files changed, 671 insertions, 30 deletions
diff --git a/doc/todo/Allow_edittemplate_to_set_file_type.mdwn b/doc/todo/Allow_edittemplate_to_set_file_type.mdwn
index 9981c530b..b49968c18 100644
--- a/doc/todo/Allow_edittemplate_to_set_file_type.mdwn
+++ b/doc/todo/Allow_edittemplate_to_set_file_type.mdwn
@@ -5,6 +5,9 @@ Below is a [[patch]] to [[plugins/edittemplate]] that does a few things:
* It makes the description of what was registered link to the template page (which gives feedback for typos or allows template creation)
* It adds a colon to the standard string correcting the syntax.
+[[done]] except for the colon change; it's referring to the template as an
+edittemplate there. --[[Joey]]
+
----
diff --git a/IkiWiki/Plugin/edittemplate.pm b/IkiWiki/Plugin/edittemplate.pm
@@ -38,3 +41,4 @@ Below is a [[patch]] to [[plugins/edittemplate]] that does a few things:
return;
}
}
+
diff --git a/doc/todo/Better_bug_tracking_support.mdwn b/doc/todo/Better_bug_tracking_support.mdwn
index 628a67fc8..1a810ad55 100644
--- a/doc/todo/Better_bug_tracking_support.mdwn
+++ b/doc/todo/Better_bug_tracking_support.mdwn
@@ -44,7 +44,18 @@ be embedded to the source code repository commit messages.
>> look like a wikipage anymore, but rather something like the Debian
>> BTS web-interface, but it would still benefit from wikilinks to the
>> documentation in the wiki etc.
->>
+
+>>> I think it is useful to look at these things separately:
+>>>
+>>> * Bug numbers: See above.
+>>> * Automatic timestamps on comments: this already exists with the inline directive.
+>>> * Email interface: You can certainly get an rss feed of what changes in the wiki.
+>>> * You didn't mention [[todo/structured_page_data]] but that is, I think, part
+>>> of what you seem to be saying.
+>>> * [[todo/tracking_bugs_with_dependencies]] is also important.
+>>>
+>>> -- [[Will]]
+
>> About the commit message interface: I was thinking about a project
>> architecture where the code is kept in a separate revision control
>> system branch than the metadata (blog, wiki, BTS). This would IMHO
diff --git a/doc/todo/Feature_parity_with_Trac.mdwn b/doc/todo/Feature_parity_with_Trac.mdwn
index dab151d81..8693da5e3 100644
--- a/doc/todo/Feature_parity_with_Trac.mdwn
+++ b/doc/todo/Feature_parity_with_Trac.mdwn
@@ -7,6 +7,9 @@ Features needed:
* 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.
+ * 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]]
* 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/Location_of_pages_starting_with___36__tagbase_should_be_in__by_default.mdwn b/doc/todo/Location_of_pages_starting_with___36__tagbase_should_be_in__by_default.mdwn
index d264bd209..98a92dddc 100644
--- a/doc/todo/Location_of_pages_starting_with___36__tagbase_should_be_in__by_default.mdwn
+++ b/doc/todo/Location_of_pages_starting_with___36__tagbase_should_be_in__by_default.mdwn
@@ -11,3 +11,5 @@ subpage: `<current>/$tagbase/<tagname>`.
See also: [[bugs/tags_base_dir_not_used_when_creating_new_tags]]
[[!tag wishlist]]
+
+[[done]]
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
new file mode 100644
index 000000000..2fad9f19a
--- /dev/null
+++ b/doc/todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion.mdwn
@@ -0,0 +1,159 @@
+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.
+
+-- [[Will]]
+
+----
+
+ #!/usr/bin/perl
+ # markup source files
+ package IkiWiki::Plugin::sourcecode;
+
+ use warnings;
+ use strict;
+ use IkiWiki 2.00;
+ use open qw{:utf8 :std};
+
+ my %metaheaders;
+
+ sub import { #{{{
+ hook(type => "getsetup", id => "sourcecode", call => \&getsetup);
+ hook(type => "checkconfig", id => "sourcecode", call => \&checkconfig);
+ hook(type => "pagetemplate", id => "sourcecode", call => \&pagetemplate);
+ } # }}}
+
+ sub getsetup () { #{{{
+ return
+ plugin => {
+ safe => 1,
+ rebuild => 1, # format plugin
+ },
+ sourcecode_command => {
+ type => "string",
+ example => "/usr/bin/source-highlight",
+ description => "The command to execute to run source-highlight",
+ safe => 0,
+ rebuild => 1,
+ },
+ sourcecode_lang => {
+ type => "string",
+ example => "c,cpp,h,java",
+ description => "Comma separated list of suffixes to recognise as source code",
+ safe => 1,
+ rebuild => 1,
+ },
+ sourcecode_linenumbers => {
+ type => "boolean",
+ example => 1,
+ description => "Should we add line numbers to the source code",
+ safe => 1,
+ rebuild => 1,
+ },
+ sourcecode_css => {
+ type => "string",
+ example => "sourcecode_style",
+ description => "page to use as css file for source",
+ safe => 1,
+ rebuild => 1,
+ },
+ } #}}}
+
+ sub checkconfig () { #{{{
+ if (! $config{sourcecode_lang}) {
+ error("The sourcecode plugin requires a list of suffixes in the 'sourcecode_lang' config option");
+ }
+
+ if (! $config{sourcecode_command}) {
+ $config{sourcecode_command} = "source-highlight";
+ }
+
+ if (! length `which $config{sourcecode_command} 2>/dev/null`) {
+ error("The sourcecode plugin is unable to find the $config{sourcecode_command} command");
+ }
+
+ if (! $config{sourcecode_css}) {
+ $config{sourcecode_css} = "sourcecode_style";
+ }
+
+ if (! defined $config{sourcecode_linenumbers}) {
+ $config{sourcecode_linenumbers} = 1;
+ }
+
+ my %langs = ();
+
+ open(LANGS, "$config{sourcecode_command} --lang-list|");
+ while (<LANGS>) {
+ if ($_ =~ /(\w+) = .+\.lang/) {
+ $langs{$1} = 1;
+ }
+ }
+ close(LANGS);
+
+ foreach my $lang (split(/[, ]+/, $config{sourcecode_lang})) {
+ if ($langs{$lang}) {
+ hook(type => "htmlize", id => $lang, call => \&htmlize);
+ } else {
+ error("Your installation of source-highlight cannot handle sourcecode language $lang!");
+ }
+ }
+ } #}}}
+
+ sub htmlize (@) { #{{{
+ my %params=@_;
+
+ my $page = $params{page};
+
+ eval q{use FileHandle};
+ error($@) if $@;
+ eval q{use IPC::Open2};
+ error($@) if $@;
+
+ local(*SPS_IN, *SPS_OUT); # Create local handles
+
+ my @args;
+
+ if ($config{sourcecode_linenumbers}) {
+ push @args, '--line-number= ';
+ }
+
+ my $pid = open2(*SPS_IN, *SPS_OUT, $config{sourcecode_command},
+ '-s', IkiWiki::pagetype($pagesources{$page}),
+ '-c', $config{sourcecode_css}, '--no-doc',
+ '-f', 'xhtml',
+ @args);
+
+ error("Unable to open $config{sourcecode_command}") unless $pid;
+
+ print SPS_OUT $params{content};
+ close SPS_OUT;
+
+ my @html = <SPS_IN>;
+ close SPS_IN;
+
+ waitpid $pid, 0;
+
+ my $stylesheet=bestlink($page, $config{sourcecode_css}.".css");
+ if (length $stylesheet) {
+ push @{$metaheaders{$page}}, '<link href="'.urlto($stylesheet, $page).'"'.
+ ' rel="stylesheet"'.
+ ' type="text/css" />';
+ }
+
+ return '<div id="sourcecode">'."\r\n".join("\r\n",@html)."\r\n</div>\n";
+ } # }}}
+
+ sub pagetemplate (@) { #{{{
+ my %params=@_;
+
+ my $page=$params{page};
+ my $template=$params{template};
+
+ if (exists $metaheaders{$page} && $template->query(name => "meta")) {
+ # avoid duplicate meta lines
+ my %seen;
+ $template->param(meta => join("\n", grep { (! $seen{$_}) && ($seen{$_}=1) } @{$metaheaders{$page}}));
+ }
+ } # }}}
+
+ 1
diff --git a/doc/todo/inline:_numerical_ordering_by_title.mdwn b/doc/todo/inline:_numerical_ordering_by_title.mdwn
index ecad4f9db..95511d998 100644
--- a/doc/todo/inline:_numerical_ordering_by_title.mdwn
+++ b/doc/todo/inline:_numerical_ordering_by_title.mdwn
@@ -20,6 +20,13 @@ anymore.
Do you have any idea how to workaround that issue? --[[Paweł|ptecza]]
+> Delete all files. Add files back one at a time, committing after adding
+> each file. Sort by date. --[[Joey]]
+
+>> The simplest solutions are the best :D Thanks for the hint! I didn't
+>> want to do it before, because I was affaid that my Subversion keeps
+>> old date of creation of file. --[[Paweł|ptecza]]
+
> Maybe you can rename `9.mdwn` to `09.mdwn`? See `rename(1)`, it renames multiple files
> in one go. --[[buo]]
@@ -30,6 +37,17 @@ Do you have any idea how to workaround that issue? --[[Paweł|ptecza]]
>> I don't want to rename all previous files to add `0` prefix. --[[Paweł|ptecza]]
+>>> Rather than adding 0's or or a 'sorttype' parameter, I'd just fix the sort order.
+>>> Both MacOS and Windows use a smarter sort order than just lexical in their
+>>> file browsers (e.g. <http://support.microsoft.com/default.aspx?kbid=319827>,
+>>> <http://docs.info.apple.com/article.html?artnum=300989>).
+>>>
+>>> The [Unicode Collation algorithm](http://en.wikipedia.org/wiki/Unicode_collation_algorithm)
+>>> would seem to be a reasonable sort order. (See also <http://www.unicode.org/unicode/reports/tr10/>.)
+>>> Unfortunately the standard perl implementation, [Unicode::Collate](http://perldoc.perl.org/Unicode/Collate.html)
+>>> doesn't handle the optional [numbers](http://www.unicode.org/unicode/reports/tr10/#Customization)
+>>> extension which is what you want. --[[Will]]
+
---
Below is my simple patch. Feel free to use it or comment!
@@ -38,10 +56,18 @@ I have also 2 considerations for inline sorting:
1. Maybe changing name of `sort` parameter to `sortby` or `sortkey` will
be good idea?
+
+ > No, that would break existing wikis. --[[Joey]]
+ >> It's no problem. You just have `ikiwiki-transition` utility :D --[[Paweł|ptecza]]
+
1. Maybe you should use `title` sort key for title from meta plugin and `name`,
`filename`, `page` or `pagename` for page names? In the future you can also
sort by meta author, license or another key.
+ > There are many places in ikiwiki that do not use meta title info and
+ > could. I'd prefer to deal with that issue as a whole, not here,
+ > --[[Joey]]
+
--[[Paweł|ptecza]]
--- inline.pm-orig 2008-09-02 09:53:20.000000000 +0200
@@ -72,3 +98,155 @@ I have also 2 considerations for inline sorting:
}
if (yesno($params{reverse})) {
+
+> To users, "sort" already determines the type of sort. It can be by title,
+> or by date, etc. Adding a separate "sorttype" value is thus fairly
+> confusing. --[[Joey]]
+
+>> OK. I will be more careful when I play with inline plugin :) --[[Paweł|ptecza]]
+
+---
+
+Joey, have you forgotten about that request? ;) --[[Paweł|ptecza]]
+
+> Okie. Here is a different [[patch]] based on my comment above. It doesn't introduce
+> a new key, but rather changes the title sorting order. Two caveats:
+
+ * I've only tested this in `inline`, not the other places I changed the sort order.
+ * I'm unsure if the regexp used in the split should be `/(-?\d+)/` instead of `/(\d+)/`.
+ As written, '-' is interpreted as a hyphen rather than a minus sign.
+
+> --[[Will]]
+
+>> I"m not comfortable with tossing out perl's default collator and trying
+>> to maintain some other one going forward. Especially not for such an
+>> edge case. --[[Joey]]
+
+>> Hi Will! Your idea looks interesting for me, but I'm affraid that it's too big
+>> change in Ikiwiki... Maybe I'm wrong? ;) What do you think, Joey? --[[Paweł|ptecza]]
+
+>>> It isn't that big a change. It is just supplying a sort order to the sort. The
+>>> patch is a little larger because I then went through and made that sort
+>>> order available in other places where it makes sense. (Looking at the
+>>> patch again briefly, I should have also used it in the `map` plugin.)
+>>>
+>>> If you wanted a simple patch, you could just move the `titlecmp` function
+>>> into the inline plugin and only use it there. The problem with that is that
+>>> it only fixes the inline plugin. -- [[Will]]
+
+>>>> Will, I agree with you that it's improved way of sort order. But on the other
+>>>> hand I prefer to be careful when I change something in a several places,
+>>>> because I don't want to break any working things when I fix one thing.
+>>>> I hope that Joey agree with us too and all Ikiwiki users will be happy
+>>>> after applying your patch ;) --[[Paweł|ptecza]]
+
+----
+
+ diff --git a/IkiWiki.pm b/IkiWiki.pm
+ index c0f5dea..d001f8d 100644
+ --- a/IkiWiki.pm
+ +++ b/IkiWiki.pm
+ @@ -20,7 +20,7 @@ use Exporter q{import};
+ our @EXPORT = qw(hook debug error template htmlpage add_depends pagespec_match
+ bestlink htmllink readfile writefile pagetype srcfile pagename
+ displaytime will_render gettext urlto targetpage
+ - add_underlay
+ + add_underlay titlecmp
+ %config %links %pagestate %renderedfiles
+ %pagesources %destsources);
+ our $VERSION = 2.00; # plugin interface version, next is ikiwiki version
+ @@ -835,6 +835,42 @@ sub titlepage ($) { #{{{
+ return $title;
+ } #}}}
+
+ +sub titlecmp ($$) { #{{{
+ + my $titleA=shift;
+ + my $titleB=shift;
+ +
+ + my @listA=split(/(\d+)/,$titleA);
+ + my @listB=split(/(\d+)/,$titleB);
+ +
+ + while (@listA && @listB) {
+ + # compare bits of text
+ + my $a = shift @listA;
+ + my $b = shift @listB;
+ + my $c = ($a cmp $b);
+ + return $c if ($c);
+ +
+ + if (@listA && @listB) {
+ + # compare numbers
+ + $a = shift @listA;
+ + $b = shift @listB;
+ + $c = $a <=> $b;
+ + return $c if ($c);
+ +
+ + # 01 is different to 1
+ + $c = (length($a) <=> length($b));
+ + return $c if ($c);
+ +
+ + $c = ($a cmp $b);
+ + return $c if ($c);
+ + }
+ + }
+ +
+ + return 1 if (@listA);
+ + return -1 if (@listB);
+ +
+ + return 0;
+ +} #}}}
+ +
+ sub linkpage ($) { #{{{
+ my $link=shift;
+ my $chars = defined $config{wiki_file_chars} ? $config{wiki_file_chars} : "-[:alnum:]+/.:_";
+ diff --git a/IkiWiki/Plugin/brokenlinks.pm b/IkiWiki/Plugin/brokenlinks.pm
+ index 37752dd..ccaa399 100644
+ --- a/IkiWiki/Plugin/brokenlinks.pm
+ +++ b/IkiWiki/Plugin/brokenlinks.pm
+ @@ -59,7 +59,7 @@ sub preprocess (@) { #{{{
+ map {
+ "<li>$_</li>"
+ }
+ - sort @broken)
+ + sort titlecmp @broken)
+ ."</ul>\n";
+ } # }}}
+
+ diff --git a/IkiWiki/Plugin/inline.pm b/IkiWiki/Plugin/inline.pm
+ index 8efef3f..263e7a6 100644
+ --- a/IkiWiki/Plugin/inline.pm
+ +++ b/IkiWiki/Plugin/inline.pm
+ @@ -192,7 +192,7 @@ sub preprocess_inline (@) { #{{{
+ }
+
+ if (exists $params{sort} && $params{sort} eq 'title') {
+ - @list=sort { pagetitle(basename($a)) cmp pagetitle(basename($b)) } @list;
+ + @list=sort { titlecmp(pagetitle(basename($a)),pagetitle(basename($b))) } @list;
+ }
+ elsif (exists $params{sort} && $params{sort} eq 'mtime') {
+ @list=sort { $pagemtime{$b} <=> $pagemtime{$a} } @list;
+ diff --git a/IkiWiki/Plugin/orphans.pm b/IkiWiki/Plugin/orphans.pm
+ index b910758..10a1d87 100644
+ --- a/IkiWiki/Plugin/orphans.pm
+ +++ b/IkiWiki/Plugin/orphans.pm
+ @@ -56,7 +56,7 @@ sub preprocess (@) { #{{{
+ htmllink($params{page}, $params{destpage}, $_,
+ noimageinline => 1).
+ "</li>"
+ - } sort @orphans).
+ + } sort titlecmp @orphans).
+ "</ul>\n";
+ } # }}}
+
+ diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm
+ index ceb7c84..00798e1 100644
+ --- a/IkiWiki/Render.pm
+ +++ b/IkiWiki/Render.pm
+ @@ -89,7 +89,7 @@ sub genpage ($$) { #{{{
+ $template->param(have_actions => 1);
+ }
+
+ - my @backlinks=sort { $a->{page} cmp $b->{page} } backlinks($page);
+ + my @backlinks=sort { titlecmp($a->{page}, $b->{page}) } backlinks($page);
+ my ($backlinks, $more_backlinks);
+ if (@backlinks <= $config{numbacklinks} || ! $config{numbacklinks}) {
+ $backlinks=\@backlinks;
diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn
index 40886be55..93791c81a 100644
--- a/doc/todo/source_link.mdwn
+++ b/doc/todo/source_link.mdwn
@@ -1,3 +1,104 @@
How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
I'd like this too (and might try to implement it). -- [[jondowland]]
+
+I just implemented this. There is one [[patch]] to the default page template, and a new plugin. -- [[Will]]
+
+----
+
+ diff --git a/templates/page.tmpl b/templates/page.tmpl
+ index f2f9c34..3176bed 100644
+ --- a/templates/page.tmpl
+ +++ b/templates/page.tmpl
+ @@ -46,6 +46,9 @@
+ <TMPL_IF NAME="HISTORYURL">
+ <li><a href="<TMPL_VAR HISTORYURL>">History</a></li>
+ </TMPL_IF>
+ +<TMPL_IF NAME="GETSOURCEURL">
+ +<li><a href="<TMPL_VAR GETSOURCEURL>">Get Source</a></li>
+ +</TMPL_IF>
+ <TMPL_IF NAME="PREFSURL">
+ <li><a href="<TMPL_VAR PREFSURL>">Preferences</a></li>
+ </TMPL_IF>
+
+----
+
+ #!/usr/bin/perl
+ package IkiWiki::Plugin::getsource;
+
+ use warnings;
+ use strict;
+ use IkiWiki;
+ use open qw{:utf8 :std};
+
+ sub import { #{{{
+ hook(type => "getsetup", id => "getsource", call => \&getsetup);
+ hook(type => "pagetemplate", id => "getsource", call => \&pagetemplate);
+ hook(type => "sessioncgi", id => "getsource", call => \&cgi_getsource);
+ } # }}}
+
+ sub getsetup () { #{{{
+ return
+ plugin => {
+ safe => 1,
+ rebuild => 1,
+ },
+ getsource_mimetype => {
+ type => "string",
+ example => "application/octet-stream",
+ description => "Mime type for returned source.",
+ safe => 1,
+ rebuild => 0,
+ },
+ } #}}}
+
+ sub pagetemplate (@) { #{{{
+ my %params=@_;
+
+ my $page=$params{page};
+ my $template=$params{template};
+
+ if (length $config{cgiurl}) {
+ $template->param(getsourceurl => IkiWiki::cgiurl(do => "getsource", page => $page));
+ $template->param(have_actions => 1);
+ }
+ } # }}}
+
+ sub cgi_getsource ($$) { #{{{
+ my $cgi=shift;
+ my $session=shift;
+
+ # Note: we use sessioncgi rather than just cgi
+ # because we need $IkiWiki::pagesources{} to be
+ # populated.
+
+ return unless (defined $cgi->param('do') &&
+ $cgi->param("do") eq "getsource");
+
+ IkiWiki::decode_cgi_utf8($cgi);
+
+ my $page=$cgi->param('page');
+
+ if ($IkiWiki::pagesources{$page}) {
+
+ my $data = IkiWiki::readfile(IkiWiki::srcfile($IkiWiki::pagesources{$page}));
+
+ if (! $config{getsource_mimetype}) {
+ $config{getsource_mimetype} = "text/plain";
+ }
+
+ print "Content-Type: $config{getsource_mimetype}\r\n";
+
+ print ("\r\n");
+
+ print $data;
+
+ exit 0;
+ }
+
+ error("Unable to find page source for page: $page");
+
+ exit 0;
+ }
+
+ 1
diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn
index 62d5f04d6..2a196ed23 100644
--- a/doc/todo/structured_page_data.mdwn
+++ b/doc/todo/structured_page_data.mdwn
@@ -165,6 +165,89 @@ See also:
>>>> I've just updated the second of the two patches below. The two patches are not mutually
>>>> exclusive, but I'm leaning towards the second as more useful (for the things I'm doing). -- [[Will]]
+I think it's awesome that you're writing this code to explore the problem
+space, [[Will]] -- and these plugins are good stabs at at least part of it.
+Let me respond to a few of your comments.. --[[Joey]]
+
+On use cases, one use case is a user posting a bug report with structured
+data in it. A template is one way, but then the user has to deal with the
+format used to store the structured data. This is where a edit-time form
+becomes essential.
+
+> This was the idea with the 'form' plugin. With the 'data' plugin I was exploring
+> a different approach: try to keep the markup simple enough that the user can edit
+> the markup directly, and still have that be ok. I admit it is a stretch, but I thought
+> it worth exploring.
+
+Another use case is, after many such bugs have been filed,
+wanting to add a new field to each bug report. To avoid needing to edit
+every bug report it would be good if the fields in a bug report were
+defined somewhere else, so that just that one place can be edited to add
+the new field, and it will show up in each bug report (and in each bug
+report's edit page, as a new form field).
+
+> If I was going to do that, I'd use a perl script on a checked out
+> workspace. I think you're describing a rare operation and
+> so I'd be happy not having a web interface for it. Having said that,
+> if you just wanted to change the form for *new* pages, then you
+> can just edit the template used to create new pages.
+
+Re the form plugin, I'm uncomfortable with tying things into
+[[!cpan CGI::FormBuilder]] quite so tightly as you have.
+
+> Yeah :). But I wanted to explore the space and that was the
+> easiest way to start.
+
+CGI::FormBuilder
+could easily change in a way that broke whole wikis full of pages. Also,
+needing to sanitize FormBuilder fields with security implications is asking
+for trouble, since new FormBuilder features could add new fields, or
+add new features to existing fields (FormBuilder is very DWIM) that open
+new security holes.
+
+> There is a list of allowed fields. I only interpret those.
+
+I think that having a type system, that allows defining specific types,
+like "email address", by writing code (that in turn can use FormBuilder),
+is a better approach, since it should avoid becoming a security problem.
+
+> That would be possible. I think an extension to the 'data' plugin might
+> work here.
+
+One specific security hole, BTW, is that if you allow the `validate` field,
+FormBuilder will happily treat it as a regexp, and we don't want to expose
+arbitrary perl regexps, since they can at least DOS a system, and can
+probably be used to run arbitrary perl code.
+
+> I validate the validate field :). It only allows validate fields that match
+> `/^[\w\s]+$/`. This means you can really only use the pre-defined
+> validation types in FormBuilder.
+
+The data plugin only deals with a fairly small corner of the problem space,
+but I think does a nice job at what it does. And could probably be useful
+in a large number of other cases.
+
+> I think the data plugin is more likely to be useful than the form plugin.
+> I was thinking of extending the data directive by allowing an 'id' parameter.
+> When you have an id parameter, then you can display a small form for that
+> data element. The submission handler would look through the page source
+> for the data directive with the right id parameter and edit it. This would
+> make the data directive more like the current 'form' plugin.
+
+> That is making things significantly more complex for less significant gain though. --[[Will]]
+
+> Oh, one quick other note. The data plugin below was designed to handle multiple
+> data elements in a single directive. e.g.
+
+ \[[!data key="Depends on" link="bugs/bugA" link="bugs/bugB" value=6]]
+
+> would match `data_eq(Depends on,6)`, `data_link(Depends on,bugs/bugA)`, `data_link(Depends on,bugs/bugB)`
+> or, if you applied the patch in [[todo/tracking_bugs_with_dependencies]] then you can use 'defined pagespecs'
+> such as `data_link(Depends on,~openBugs)`. The ability to label links like this allows separation of
+> dependencies between bugs from arbitrary links.
+
+----
+
#!/usr/bin/perl
# Interpret YAML data to make a web form
package IkiWiki::Plugin::form;
diff --git a/doc/todo/supporting_comments_via_disussion_pages.mdwn b/doc/todo/supporting_comments_via_disussion_pages.mdwn
index 80b375db3..e0495c8c2 100644
--- a/doc/todo/supporting_comments_via_disussion_pages.mdwn
+++ b/doc/todo/supporting_comments_via_disussion_pages.mdwn
@@ -182,3 +182,34 @@ My approach is:
I've also updated Marcelo's code (above) to current ikiwiki, and moved it to a "marceloblogcomment" namespace - it's in the "marcelocomments" branch of my repository (see <http://git.debian.org/?p=users/smcv/ikiwiki.git;a=log;h=refs/heads/marcelocomments>). I had to reconstitute the .tmpl file, which Marcelo didn't post here.
--[[smcv]]
+
+OK, the postcomment branch in my repository contains an implementation. What
+do you think so far? Known issues include:
+
+* The combination of RSS/Atom links and the "post new comment..." button is
+ ugly - I need a way to integrate the "new comment" button into the feed links
+ somehow, like the way inline embeds its own "new blog post..." feature
+ (I don't think the current way really scales, though)
+
+* There are some tweakables (whether to commit comments into the VCS, whether
+ wikilinks are allowed, whether directives are allowed) that are theoretically
+ configurable, but are currently hard-coded
+
+* The wikilink/directive disarming doesn't work unless you have
+ prefixdirectives set (which I just realised)
+
+* \[[!smcvpostcomment]] now displays the comments too, by invoking \[[!inline]]
+ with suitable parameters - but it does so in a very ugly way
+
+* Start-tags in a comment with no corresponding end-tag break page formatting
+ (unless htmltidy is enabled - inline and aggregate have the same problem)
+
+* There is no access control, so anonymous users can always comment, and so
+ can all logged-in users. Perhaps we need to extend canedit() to support
+ different types of edit? Or perhaps I should ignore canedit() and make the
+ access control configurable via a parameter to \[[!smcvpostcomment]]?
+ I'd like to be able to let anonymous (or at least non-admin) users comment
+ on existing pages, but not edit or create pages (but perhaps I'm being too
+ un-wikiish).
+
+--[[smcv]]
diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn
index 8435e9f58..3af0458bd 100644
--- a/doc/todo/tracking_bugs_with_dependencies.mdwn
+++ b/doc/todo/tracking_bugs_with_dependencies.mdwn
@@ -191,7 +191,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
----
diff --git a/IkiWiki.pm b/IkiWiki.pm
- index 4e4da11..2cc5f09 100644
+ index 4e4da11..8b3cdfe 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -1550,7 +1550,16 @@ sub globlist_to_pagespec ($) { #{{{
@@ -208,7 +208,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
+ \))?\s*$
+ ) |
+ (\s and \s) | (\s or \s) # or we find 'and' or 'or' somewhere
- + /x);
+ + /xs);
} #}}}
sub safequote ($) { #{{{
@@ -221,7 +221,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
my $spec=shift;
# Support for old-style GlobLists.
- @@ -1650,7 +1659,9 @@ sub pagespec_translate ($) { #{{{
+ @@ -1650,12 +1659,14 @@ sub pagespec_translate ($) { #{{{
|
\) # )
|
@@ -232,18 +232,25 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
|
[^\s()]+ # any other text
)
+ \s* # ignore whitespace
+ - }igx) {
+ + }igxs) {
+ my $word=$1;
+ if (lc $word eq 'and') {
+ $code.=' &&';
@@ -1666,16 +1677,23 @@ sub pagespec_translate ($) { #{{{
elsif ($word eq "(" || $word eq ")" || $word eq "!") {
$code.=' '.$word;
}
- + elsif ($word =~ /^define\(\s*~(\w+)\s*,(.*)\)$/) {
+ - elsif ($word =~ /^(\w+)\((.*)\)$/) {
+ + elsif ($word =~ /^define\(\s*~(\w+)\s*,(.*)\)$/s) {
+ $code .= " (\$params{specFuncs}->{$1}="; # (exists \$params{specFuncs}) &&
+ $code .= "memoize(";
+ $code .= &pagespec_makeperl($2);
+ $code .= ")";
+ $code .= ") ";
+ }
- elsif ($word =~ /^(\w+)\((.*)\)$/) {
+ + elsif ($word =~ /^(\w+)\((.*)\)$/s) {
if (exists $IkiWiki::PageSpec::{"match_$1"}) {
- $code.="IkiWiki::PageSpec::match_$1(\$page, ".safequote($2).", \@_)";
+ $code.="IkiWiki::PageSpec::match_$1(\$page, ".safequote($2).", \%params)";
@@ -258,7 +265,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
}
}
- @@ -1683,23 +1701,36 @@ sub pagespec_translate ($) { #{{{
+ @@ -1683,8 +1701,18 @@ sub pagespec_translate ($) { #{{{
$code=0;
}
@@ -278,27 +285,16 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
} #}}}
sub pagespec_match ($$;@) { #{{{
- my $page=shift;
- my $spec=shift;
- my @params=@_;
- + my %params=@_;
+ @@ -1699,7 +1727,7 @@ sub pagespec_match ($$;@) { #{{{
- # Backwards compatability with old calling convention.
- if (@params == 1) {
- - unshift @params, 'location';
- + %params = { location => $params[1] };
- }
-
- + $params{specFuncs} = {} unless defined $params{specFuncs};
- +
my $sub=pagespec_translate($spec);
return IkiWiki::FailReason->new("syntax error in pagespec \"$spec\"") if $@;
- return $sub->($page, @params);
- + return $sub->($page, %params);
+ + return $sub->($page, @params, specFuncs => {});
} #}}}
sub pagespec_valid ($) { #{{{
- @@ -1748,11 +1779,78 @@ sub new { #{{{
+ @@ -1748,11 +1776,78 @@ sub new { #{{{
package IkiWiki::PageSpec;
@@ -377,7 +373,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
my $from=exists $params{location} ? $params{location} : '';
# relative matching
- @@ -1782,11 +1880,16 @@ sub match_internal ($$;@) { #{{{
+ @@ -1782,11 +1877,12 @@ sub match_internal ($$;@) { #{{{
sub match_link ($$;@) { #{{{
my $page=shift;
@@ -386,17 +382,21 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
my %params=@_;
+ my $link=lc($fulllink);
- - my $from=exists $params{location} ? $params{location} : '';
- + if (substr($fulllink, 0, 1) eq '~') {
- + return check_named_spec_existential($page, $fulllink, \&match_link, %params);
- + }
-
- + my $from=exists $params{location} ? $params{location} : '';
+ my $from=exists $params{location} ? $params{location} : '';
+ -
+
# relative matching
if ($link =~ m!^\.! && defined $from) {
$from=~s#/?[^/]+$##;
- @@ -1811,12 +1914,25 @@ sub match_link ($$;@) { #{{{
+ @@ -1804,19 +1900,32 @@ sub match_link ($$;@) { #{{{
+ }
+ else {
+ return IkiWiki::SuccessReason->new("$page links to page $p matching $link")
+ - if match_glob($p, $link, %params);
+ + if match_glob($p, $fulllink, %params);
+ }
+ }
+ return IkiWiki::FailReason->new("$page does not link to $link");
} #}}}
sub match_backlink ($$;@) { #{{{
@@ -423,7 +423,7 @@ account all comments above (which doesn't mean it is above reproach :) ). --[[W
if (exists $IkiWiki::pagectime{$testpage}) {
if ($IkiWiki::pagectime{$page} < $IkiWiki::pagectime{$testpage}) {
- @@ -1834,6 +1950,11 @@ sub match_created_before ($$;@) { #{{{
+ @@ -1834,6 +1943,11 @@ sub match_created_before ($$;@) { #{{{
sub match_created_after ($$;@) { #{{{
my $page=shift;
my $testpage=shift;
diff --git a/doc/todo/turn_edittemplate_verbosity_off_by_default.mdwn b/doc/todo/turn_edittemplate_verbosity_off_by_default.mdwn
index 4c703b940..87e55685c 100644
--- a/doc/todo/turn_edittemplate_verbosity_off_by_default.mdwn
+++ b/doc/todo/turn_edittemplate_verbosity_off_by_default.mdwn
@@ -28,3 +28,7 @@ I think this (untested) patch might just do the trick:
--[[madduck]]
[[!tags wishlist patch]]
+
+[[done]], though the patch I eventually applied uses "silent" as the
+parameter name. Sorry for forgetting about this patch until someone else
+implemented it too. --[[Joey]]
diff --git a/doc/todo/wikitrails.mdwn b/doc/todo/wikitrails.mdwn
new file mode 100644
index 000000000..ca97c9404
--- /dev/null
+++ b/doc/todo/wikitrails.mdwn
@@ -0,0 +1,41 @@
+## summary
+at times it is useful to have a guided tour or trail through a subset of the pages of a wiki; in pmwiki, this is implemented as [wikitrails](http://www.pmwiki.org/wiki/PmWiki/WikiTrails).
+
+i'm working on a python xmlrpc plugin for ikiwiki to support wikitrails, both as a navigation feature (have "forward" and "back" links based on a sequence) and a modified inline that includes all pages in the trail with appropriate modifications (suitable for printing if necessary).
+
+the current status is published on `git://github.com/github076986099/ikiwiki-plugins.git`; as of now, i don't have a public demo of it.
+
+feedback on both the concept and the code is very much appreciated by [[discussion]] or [email](mailto:chrysn@fsfe.org).
+
+## usage
+
+two preprocessor commands are provided:
+
+### \[[!trail index="my_indexpage"]]
+
+embeds a navigation object with forward and back links as well as an indicator of the current position in the trail.
+
+if index is not specified, a suitable page up the path is used.
+
+this works very well together with the [[sidebar|plugins/sidebar]] plugin if the pages in a directory are roughly the same as the pages in the trail and the `index` is directory index page; just put the \[[!trail]] in the sidebar.
+
+### \[[!trailinclude index="my_indexpage"]]
+
+all pages linked from the index page are included in the same way as \[[!inline]] does, but in the proper sequence, with headings according to the indent in the source page and adoptions for the headings inside the page (a level 2 heading in a page that is a sub-sub-chapter in the whole trail will become a level 5 heading when trailincluded).
+
+## the index page
+
+the index page is parsed as markdown; numbered lists and "`*`" bulleted lists are discovered.
+
+## current issues
+
+ * rebuilding --- currently, there is no propper rebuilding of pages (will use `will_render` and `add_depends`). care has to be taken of how not yet created pages play into this.
+ * inline recursion --- there is simply no guard yet
+ * navigation layout --- has to be both flexible and usable-by-default
+ * heading shifting
+ * currently only works for markdown
+ * can break the limit of html's six heading levels
+ * search for index page is currently next to hardcoded
+ * reading the index --- markdown syntax parsing is currently on a it-can-use-what-i-produce level; maybe integrate with existing mdwn parser
+ * uses undocumented titlepage command
+ > Don't worry about that, titlepage isn't going anywhere, and will probably before a formal part of the api next time I consider api changes. --[[Joey]]
diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn
new file mode 100644
index 000000000..327e61491
--- /dev/null
+++ b/doc/todo/wikitrails/discussion.mdwn
@@ -0,0 +1,24 @@
+This sounds like a more general version of what I want for
+one-photo-per-page galleries, where each page has previous|up|next links
+(like this plugin) and the index page has a list or grid of thumbnails
+(\[[!inline]] with a specially modified template perhaps). I'll watch this
+with interest! --[[smcv]]
+
+This is a nice idea, I do have my gripes about the imeplementation.
+
+Assuming that the index's list is in mdwn format is not ideal. I guess the
+other way to do it would be to make the index be a directive, something
+like: \[[!trail pages="foo bar baz"]]. Assuming that a flat trail structure
+is enough, otherwise you'd have to get more fancy.
+
+The trailinclude seems a bit redundant with inline, and wanting to inline
+together all pages in a trail for printing or whatever seems like an
+unusual use case anyway?
+
+The !trail directive could be simplified to just \[[!trail my_indexpage]].
+But I wonder if needing to add this directive to every page is the best
+approach. Alternate approach would be to make the trail index cause
+breadcrums to be automatically inserted at the top of every page on the
+trail. (You'd have to use a directive to define the index for that to work.)
+
+--[[Joey]]
generated by cgit v1.2.3 (git 2.39.1) at 2024-08-31 22:28:23 +0000