X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/1e561f8b5fc78dbc3675dde30fea396a3590a2b5..31826c8b975245efb8e578efa037a2ce5c088b83:/doc/todo/syntax_highlighting.mdwn

diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn
index 041d92b13..b5d083ba5 100644
--- a/doc/todo/syntax_highlighting.mdwn
+++ b/doc/todo/syntax_highlighting.mdwn
@@ -7,22 +7,29 @@ pages, as well as doing syntax highlighting as a preprocessor directive
 
 ## The big list of possibilities
 
-* [[plugins/contrib/highlightcode]] uses [[cpan Syntax::Highlight::Engine::Kate]],
+* [[plugins/contrib/highlightcode]] uses [[!cpan Syntax::Highlight::Engine::Kate]],
   operates on whole source files only, has a few bugs (see
   [here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to
   support [[bugs/multiple_pages_with_same_name]].
-* [[cpan IkiWiki-Plugin-syntax]] only operates as a directive.
+* [[!cpan IkiWiki-Plugin-syntax]] only operates as a directive.
   Interestingly, it supports multiple highlighting backends, including Kate
   and Vim.
 * [[plugins/contrib/syntax]] only operates as a directive
   ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]),
-  and uses [[cpan Text::VimColor]].
+  and uses [[!cpan Text::VimColor]].
 * [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on
   whole source files only. Needs to be updated to
   support [[bugs/multiple_pages_with_same_name]].
 * [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]
   also uses src-highlight, and operates on whole source files.
-  Has problems with [[bugs/multiple_pages_with_same_name]].
+  Updated to work with the fix for [[bugs/multiple_pages_with_same_name]].  Untested with files with no extension, e.g. `Makefile`.
+* [[users/jasonblevins]]'s code plugin uses src-highlight, and supports both
+  while file and directive use.
+
+* [hlsimple](http://pivot.cs.unb.ca/git/?p=ikiplugins.git;a=blob_plain;f=IkiWiki/Plugin/hlsimple.pm;hb=HEAD) is a wrapper for the the perl module Syntax::Highlight::Engine::Simple.  This is pure perl, pretty simple, uses css. It ought to be pretty fast (according to the author, and just because it is not external).
+On the other hand, there are not many predefined languages yet.  Defining language syntaxes is about as much 
+work as source-highlight, but in perl.  I plan to package the base module for debian. Perhaps after the author 
+releases the 5 or 6 language definitions he has running on his web site, it might be suitable for inclusion in ikiwiki. [[DavidBremner]]
 
 ## General problems
 
@@ -32,12 +39,16 @@ pages, as well as doing syntax highlighting as a preprocessor directive
   we could use an external plugin..)
 * Currently no single plugin supports both modes of operation (directive
   and whole source file to page).
+
+  > This is now fixed by the [[ikiwiki/directive/format]] directive for all
+  > whole-source-file plugins, right?
+
 * Nothing seems to support 
   [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
   inside source files. Doing this probably means post-processing the 
   results of the highlighting engine, to find places where it's highlighted
   comments, and then running them through the ikiwiki rendering pipeline.
-  This seems fairly doable with [[cpan Syntax::Highlight::Engine::Kate]],
+  This seems fairly doable with [[!cpan Syntax::Highlight::Engine::Kate]],
   at least.
 * The whole-file plugins tend to have a problem that things that look like
   wikilinks in the source code get munged into links by ikiwiki, which can
@@ -45,6 +56,17 @@ pages, as well as doing syntax highlighting as a preprocessor directive
   One approach that's also been requested for eg,
   [[plugins/contrib/mediawiki]] is to allow controlling which linkification
   types a page type can have on it.
+
+  > The previous two points seem to be related.  One thought: instead of
+  > getting the source from the `content` parameter, the plugin could
+  > re-load the page source.  That would stop directives/links from
+  > being processed in the source.  As noted above, comments
+  > could then be parsed for directives/links later.
+  >
+  > Would it be worth adding a `nodirectives` option when registering
+  > an htmlize hook that switches off directive and link processing before
+  > generating the html for a page?
+
 * The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
   This is trivially fixable now by passing the keepextension option when
   registering the htmlize hooks, though.
@@ -61,6 +83,28 @@ pages, as well as doing syntax highlighting as a preprocessor directive
   extensions. The workaround is to use a directive on a wiki page, pulling
   in the Makefile.
 
+  > I wonder how hard it would be to make a patch whereby a file with
+  > no `.` in the name, and a name that matches a filetype, and where
+  > that filetype was registered `keepextension`, then the file is just
+  > chosen as the appropriate type.  This would allow `Makefile` to
+  > work.
+
+like this:
+
+    diff --git a/IkiWiki.pm b/IkiWiki.pm
+    index 8d728c9..1bd46a9 100644
+    --- a/IkiWiki.pm
+    +++ b/IkiWiki.pm
+    @@ -618,6 +618,8 @@ sub pagetype ($) {
+     	
+     	if ($page =~ /\.([^.]+)$/) {
+     		return $1 if exists $hooks{htmlize}{$1};
+    +	} elsif ($hooks{htmlize}{$page}{keepextension}) {
+    +		return $page;
+     	}
+     	return;
+     }
+
 ## format directive
 
 Rather than making syntax highlight plugins have to provide a preprocessor
@@ -73,8 +117,8 @@ That would run the text through the pl htmlizer, from the syntax hightligh
 plugin. OTOH, if "rst" were given, it would run the text through the rst
 htmlizer. So, more generic, allows mixing different types of markup on one
 page, as well as syntax highlighting. Does require specifying the type of
-format, instead of allows it to be guessed (which some syntax highlighters
-can do).
+format, instead of allowing it to be guessed (which some syntax highlighters
+can do). (This directive is now implemented..)
 
 Hmm, this would also allow comments inside source files to have mdwn
 embedded in them, without making the use of mdwn a special case, or needing