cleaned up, updated and submitted for patch

diff --git a/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn b/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn
index d4dae771daa2a9c82e2fc8f0deba1bb6045ec25b..0a8ee99c763102778b607f3bd90134f64a0b437b 100644 (file)
--- a/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn
+++ b/doc/bugs/color_plugin_produces_artifacts_in_table-of-contents.mdwn
@@ -1,4 +1,4 @@
-# Bug Descriptipn 
+# Bug Description 

 
 If color and toc plugins are enabled and you use colored headers, those headers are never colored but sometimes are prefixed with text artifacts like "color: red".
 
 
 If color and toc plugins are enabled and you use colored headers, those headers are never colored but sometimes are prefixed with text artifacts like "color: red".
 


@@ -21,61 +21,57 @@ Reason for this behaviour is:
 There are a few possible solutions to this depending on how it should work:
 
 1. The easiest thing would be to just add a "last" parameter to the toc plugin format hook (or "first" to the color plugin). Result: No color in tocs at all
 There are a few possible solutions to this depending on how it should work:
 
 1. The easiest thing would be to just add a "last" parameter to the toc plugin format hook (or "first" to the color plugin). Result: No color in tocs at all

-1. Adding four (**EDIT** seven) lines to toc.pm (and possibly removing ~4 now superfluous lines **EDIT** No) would make it preserve ALL markup in headers, color as well as html markup or markdown (*emphasize* for example). Execution order of the plugins would not matter at all
+1. Adding seven lines to toc.pm would make it preserve ALL markup in headers, color as well as html markup or markdown (*emphasize* for example). Execution order of the plugins would not matter at all

 1. A bit more code would be necessary to just specifically preserve the color, but nothing else
 
 I would propose implementing the second option because visual markers in headers are useful to convey additional information very fast and this information should be preserved in the toc. Example: Bug or task/project tracker with color conveying status of the bug or task.
 
 1. A bit more code would be necessary to just specifically preserve the color, but nothing else
 
 I would propose implementing the second option because visual markers in headers are useful to convey additional information very fast and this information should be preserved in the toc. Example: Bug or task/project tracker with color conveying status of the bug or task.
 

-It seems you can stuff anything into ordered lists (according to w3.orgs doku), so apart from stylistic reasons I don't see any problems with markup in the toc. 
+It seems you can stuff anything into ordered lists (according to w3.orgs doku), so apart from stylistic reasons and suboptimal display of links in headers (see below) I don't see any problems with markup in the toc. 

 
 # Patch
 
 
 # Patch
 

-This is the proposed patch to the second solution. I did not yet test it with the latest version of ikiwiki, but I did check that both plugins are identical in my test versions and the latest. I will update my wikis in use to the latest version and test it further, anyway. 
-
-The part that could probably be removed in toc is the handler call "$p->handler(text => sub {" in line 110. It collects all text in the header as HTML::Parser "dtext", which means entities are decoded in the text. Since that step is probably already done in ikiwiki or doesn't need to be done (otherwise ikiwiki with toc.pm disabled would not work correctly) I'm pretty sure the "dtext" is not necessary. And in that case the patch below would just collect that text in the default handler. Not tested at all, I want to hear a second opinion first. 
-
-**EDIT** Ok, the handler call is still necessary, but the "dtext" could be changed to "text". Also I needed to add 3 more lines, the patch below is up to date. It works with all markup and markdown I could think of. The only case not handled optimal is if the header is just a link and nothing else, then there is no text left for the local link, the toc links directly to a different page. Is that acceptable or not?
-
-(Should I upload this patch as a branch to ikiwiki.info? Not sure about how patch submission works here)
-
-    diff --git a/IkiWiki/Plugin/toc.pm b/IkiWiki/Plugin/toc.pm
-    index ac07b9a..5c2b056 100644
-    --- a/IkiWiki/Plugin/toc.pm
-    +++ b/IkiWiki/Plugin/toc.pm
-    @@ -57,6 +57,7 @@ sub format (@) {
-           my $startlevel=($params{startlevel} ? $params{startlevel} : 0);
-           my $curlevel=$startlevel-1;
-           my $liststarted=0;
-    +  my $headercollect=0;
-           my $indent=sub { "\t" x $curlevel };
-           $p->handler(start => sub {
-                   my $tagname=shift;
-    @@ -107,6 +108,7 @@ sub format (@) {
-                           $index.=&$indent."<li class=\"L$curlevel\">".
-                                   "<a href=\"#$anchor\">";
-
-    +                  $headercollect=1;
-                           $p->handler(text => sub {
-                                   $page.=join("", @_);
-                                   $index.=join("", @_);
-    @@ -117,12 +119,17 @@ sub format (@) {
-                                           $p->handler(text => undef);
-                                           $p->handler(end => undef);
-                                           $index.="</a>\n";
-    +                                  $headercollect=0;
-    +                          }
-    +                          else {
-    +                              $index.=join("",@_);
-                                   }
-                                   $page.=join("", @_);
-                           }, "tagname, text");
-                   }
-                   else {
-                           $page.=$text;
-    +                  $index.=$text if ($headercollect);
-                   }
-           }, "tagname, text");
-           $p->handler(default => sub { $page.=join("", @_) }, "text");
-    -- 
-    1.8.4.5
-
+This is the proposed patch to the second solution. Tested with the latest version. It works with all markup and markdown I could think of. The only case not handled optimal is if the header is just a link and nothing else, then there is no text left for the local link, the toc links directly to a different page. Is that acceptable or not?
+
+
+
+diff --git a/IkiWiki/Plugin/toc.pm b/IkiWiki/Plugin/toc.pm
+index ac07b9a..5c2b056 100644
+--- a/IkiWiki/Plugin/toc.pm
++++ b/IkiWiki/Plugin/toc.pm
+@@ -57,6 +57,7 @@ sub format (@) {
+        my $startlevel=($params{startlevel} ? $params{startlevel} : 0);
+        my $curlevel=$startlevel-1;
+        my $liststarted=0;
++       my $headercollect=0;
+        my $indent=sub { "\t" x $curlevel };
+        $p->handler(start => sub {
+                my $tagname=shift;
+@@ -107,6 +108,7 @@ sub format (@) {
+                        $index.=&$indent."<li class=\"L$curlevel\">".
+                                "<a href=\"#$anchor\">";
+                        
++                       $headercollect=1;
+                        $p->handler(text => sub {
+                                $page.=join("", @_);
+                                $index.=join("", @_);
+@@ -117,12 +119,17 @@ sub format (@) {
+                                        $p->handler(text => undef);
+                                        $p->handler(end => undef);
+                                        $index.="</a>\n";
++                                       $headercollect=0;
++                               }
++                               else {
++                                   $index.=join("",@_);
+                                }
+                                $page.=join("", @_);
+                        }, "tagname, text");
+                }
+                else {
+                        $page.=$text;
++                       $index.=$text if ($headercollect);
+                }
+        }, "tagname, text");
+        $p->handler(default => sub { $page.=join("", @_) }, "text");
+
+
+[[!tag  patch]]