]> sipb.mit.edu Git - ikiwiki.git/commitdiff
Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
authorJoey Hess <joey@kodama.kitenet.net>
Sun, 3 Aug 2008 18:21:46 +0000 (14:21 -0400)
committerJoey Hess <joey@kodama.kitenet.net>
Sun, 3 Aug 2008 18:21:46 +0000 (14:21 -0400)
doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn [new file with mode: 0644]
doc/bugs/map_is_inconsistent_about_bare_directories.mdwn
doc/bugs/sidebar_is_obscured_by_recentchanges.mdwn [new file with mode: 0644]
doc/todo/mbox.mdwn
doc/todo/plugin.mdwn
doc/users/schmonz.mdwn

diff --git a/doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn b/doc/bugs/Warns_about_use_of_uninitialized_value_if_prefix__95__directives_is_on_and_a_directive_does_not_contain_a_space.mdwn
new file mode 100644 (file)
index 0000000..6274f12
--- /dev/null
@@ -0,0 +1,17 @@
+In `IkiWiki::preprocess`, the last capturing group in the regex used to parse directives in prefix_directives mode is of the form `(\s+...)?\]\]`, which will not be matched if the directive is something without arguments or whitespace, like `\[[!orphans]]`. As a result, its value is undef instead of being an empty string, causing a warning when it is used in the anonymous sub `$handle`. A trivial fix is to treat it as "" if it is undef.
+
+[[patch]] in the master branch of my git repository, and quoted here. --[[smcv]]
+
+    diff --git a/IkiWiki.pm b/IkiWiki.pm
+    index 241a7c0..d2c35a2 100644
+    --- a/IkiWiki.pm
+    +++ b/IkiWiki.pm
+    @@ -1167,7 +1167,8 @@ sub preprocess ($$$;$$) { #{{{
+                    }sx;
+            }
+     
+    -       $content =~ s{$regex}{$handle->($1, $2, $3, $4)}eg;
+    +       # $4 can be undef if the directive was \[[!foo]]
+    +       $content =~ s{$regex}{$handle->($1, $2, $3, ($4 or ""))}eg;
+            return $content;
+     } #}}}
index 479db3e0f28bd2b7be613443a2b38b314d2f11cd..6e9dc104d52289aa2baf9280de74678dc5f4e35b 100644 (file)
 The [[plugins/map]] plugin has inconsistent behaviour.  In particular, I have in my wiki some directory structures holding files without wikitext pointers (I point directly to the files from elsewhere).  For example, imagine the following file structure in the source dir:
 
-* Assignments.mdwn
-* Assignments
-    * 2004
-        * Assign1.pdf
-        * Assign2.pdf
-    * 2005
-        * Assign1.pdf
-        * Assign2.pdf
-    * 2006
-        * etc., etc.
+    ; ls -R dirA dirB
+    dirA:
+    subA       subB
+    
+    dirA/subA:
+    filea.mdwn fileb.mdwn
+    
+    dirA/subB:
+    filec.mdwn filed.mdwn
+    
+    dirB:
+    subA       subC
+    
+    dirB/subA:
+    filea.mdwn
+    
+    dirB/subC:
+    fileb.mdwn filec.mdwn
 
 When I use map to make a map of this, the result looks more like this:
 
-* Assignments        # this is a link to the correct page
-    * 2004                   # this has a create link
-        * Assign1.pdf
-        * Assign2.pdf
-        * Assign1.pdf
-        * Assign2.pdf
-        * etc., etc.
+<ul>
+<li><span class="createlink">? dirA</span>
+<ul>
+<li><span class="createlink">? subA</span>
+<ul>
+<li>filea
+</li>
+</ul>
+<ul>
+<li>fileb
+</li>
+</ul>
+<ul>
+<li>filec
+</li>
+<li>filed
+</li>
+</ul>
+</li>
+</ul>
+</li>
+<li><span class="createlink">? dirB</span>
+<ul>
+<li><span class="createlink">? subA</span>
+<ul>
+<li>filea
+</li>
+</ul>
+</li>
+</ul>
+<ul>
+<li><span class="createlink">? subC</span>
+<ul>
+<li>fileb
+</li>
+</ul>
+<ul>
+<li>filec
+</li>
+</ul>
+</li>
+</ul>
+</li>
+</ul>
 
-Note that while the 2004 directory exists with a create link, the 2005 and 2006 (etc) directories are missing from the site map.
+Note that while the dirA/subA directory exists with a create link, the dirA/subB directory is missing from the map.  Interestingly, dirB/subC is shown in the map.  If you add a second file to dirB/subA then dirB/subC disappears as well.
 
 I could imagine including all 'bare' directories in the map, and I could imagine including no 'bare' directories in the map.  Just including the first bare directory seems a strange intermediate point.
+
+Attached is a [[patch]] that fixes the issue.  The current map code makes one pass over the sorted list of pages.  This adds an initial pass that goes through and makes sure that all parent directories are included.  With this initial pass added, the following pass could probably be simplified.
+
+Note: This patch adds items to a map while it is in a foreach loop over a sorted list of keys from that same map.  Changing a map while iterating through it is normally problematic.  I'm assuming the sort insulates the code from this - I do not need to iterate over any of the newly added elements.
+
+    diff --git a/IkiWiki/Plugin/map.pm b/IkiWiki/Plugin/map.pm
+    index 5b6a843..16de45e 100644
+    --- a/IkiWiki/Plugin/map.pm
+    +++ b/IkiWiki/Plugin/map.pm
+    @@ -67,6 +67,39 @@ sub preprocess (@) { #{{{
+       # are removed.
+       add_depends($params{page}, join(" or ", keys %mapitems));
+     
+    +  # Include all the parent directories in the map
+    +  my $lastbase="";
+    +  my $commonbase = "";
+    +  $commonbase = $common_prefix if defined $common_prefix && length $common_prefix;
+    +  foreach my $item (sort keys %mapitems) {
+    +          $item=~s/^\Q$common_prefix\E\///
+    +                  if defined $common_prefix && length $common_prefix;
+    +          my $itembase=IkiWiki::dirname($item);
+    +          if ($itembase ne $lastbase) {
+    +                  # find the common dir
+    +                  my @a=split(/\//, $itembase);
+    +                  my @b=split(/\//, $lastbase);
+    +                  my $common_dir=$commonbase;
+    +                  while (@a && @b && $a[0] eq $b[0]) {
+    +                          if (length $common_dir) {
+    +                                  $common_dir.="/";
+    +                          }
+    +                          $common_dir.=shift(@a);
+    +                          shift @b;
+    +                  }
+    +                  # add all the dirs down to the current base
+    +                  while (@a) {
+    +                          if (length $common_dir) {
+    +                                  $common_dir.="/";
+    +                          }
+    +                          $common_dir.=shift(@a);
+    +                          $mapitems{$common_dir}=''
+    +                                  unless defined $mapitems{$common_dir};
+    +                  }
+    +                  $lastbase = $itembase;
+    +          }
+    +  }
+    +
+       # Create the map.
+       my $parent="";
+       my $indent=0;
diff --git a/doc/bugs/sidebar_is_obscured_by_recentchanges.mdwn b/doc/bugs/sidebar_is_obscured_by_recentchanges.mdwn
new file mode 100644 (file)
index 0000000..90bb800
--- /dev/null
@@ -0,0 +1,14 @@
+I've set up a simple sidebar on an otherwise fairly default wiki.  The sidebar uses css float:right and sits above most pages quite nicely.
+
+For example, my wiki's [front](http://www.cse.unsw.edu.au/~cs3431/wiki/) and [news](http://www.cse.unsw.edu.au/~cs3431/wiki/news/) pages show the sidebar nicely floating on top of the background.  (As a side note, I had to add:
+
+    #sidebar {
+       border: 1px solid;
+       background: white;
+    }  
+
+to <code>local.css</code> to get the border and make sure that the RSS feed's grey title didn't show through on the news page.)
+
+Unfortunately, the [recentchanges](http://www.cse.unsw.edu.au/~cs3431/wiki/recentchanges/) page doesn't look so nice - the sidebar appears below the recentchanges list.
+
+I don't understand why the sidebar is appearing below the recentchanges inline, but above the news inline.
index dd0e5756bba1aa916b29ca844d15d2b44431c4bd..91816ae8ad8064bccc146b6240a3ce21806652e5 100644 (file)
@@ -2,9 +2,9 @@ I'd like to be able to drop an unmodified RFC2822 email message into ikiwiki, an
 
 > We're discussing doing just that (well, whole mailboxes, really) over in
 > [[comment_by_mail]] --[[Joey]]
->> If you like to read code, you can have a gander at the 
+>> The 
 >> [mailbox](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=summary) 
->> plugin.  At the moment, it reads all of the messages in a maildir and passes them through 
->> a template of your choice.  Kinda acts like `cat` at the moment because none of the 
->> css is defined yet.  Next missions are threading (Email::Thread?), and maybe some simple css. 
+>> plugin can now be considered a prototype of itself, tested only with maildirs.
+>>  Basic threading and some simple css is now included.  Next mission:
+>> doing something sensible with MIME.
 >> To see the (unsurprising) syntax, look at [a trivial example markdown file](http://pivot.cs.unb.ca/git/?p=ikimailbox.git;a=blob;f=test/in/index.mdwn;hb=HEAD)
index 8db4a0182fd6f5cf46fd63d340c9d048e1f7ad1c..132de44807eabc4ca00c6049356d2ef5f5eac72a 100644 (file)
@@ -61,6 +61,9 @@ Suggestions of ideas for plugins:
     > The hard part is just that right now the assumption of html as the one destination
     > type is in the code a lot. --ChapmanFlack
 
+    >> Readers who bought this also liked: [[format_escape]], [[multiple_output_formats]]
+    >> --[[JeremieKoenig]]
+
 * list of registered users - tricky because it sorta calls for a way to rebuild the page when a new user is registered. Might be better as a cgi?
 > At best, this could only show the users who have logged in, not all
 > permitted by the current auth plugin(s).  HTTP auth would need
index 7e297fbf0d6216dfd2772dbe1e2b776017d8272a..42b3713ea9fead8c5f7be8d82876e3841e9132a3 100644 (file)
@@ -1 +1 @@
-[Amitai Schlair](http://www.schmonz.com/) recently discovered ikiwiki.
+[Amitai Schlair](http://www.schmonz.com/) recently discovered ikiwiki. His first attempt at contributing is [[plugins/contrib/unixauth]].