X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/3a1ff1d0dc4b09d211e075b653c5a3767d05b74e..83826b39cfefd2588da09ca427d48f11a92ea8c0:/doc/todo/syntax_highlighting.mdwn

diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn
index 576d456f3..81ba19bc8 100644
--- a/doc/todo/syntax_highlighting.mdwn
+++ b/doc/todo/syntax_highlighting.mdwn
@@ -14,20 +14,20 @@ things easier for the user.
 * [[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]].
+  support [[bugs/multiple_pages_with_same_name]]. (Currently a 404 :-( )
 * [[!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]].
-* [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on
+* [[plugins/contrib/sourcehighlight]] uses source-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.
+  also uses source-highlight, and operates on whole source files.
   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
+* [[users/jasonblevins]]'s code plugin uses source-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 [[!cpan 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).
@@ -35,12 +35,37 @@ On the other hand, there are not many predefined languages yet.  Defining langua
 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
+## General problems / requirements
+
+* Using non-perl syntax highlighting backends is slower. All things equal,
+  I'd prefer either using a perl module, or a multiple-backend solution that
+  can use a perl module as one option. (Or, if there's a great highlighter
+  python module, we could use an external plugin..)
+
+  Of course, some perl modules are also rather slow.. Kate, for example
+  can only process about 33 lines of C code, or 14 lines of
+  debian/changelog per second. That's **30 times slower than markdown**!
+
+  By comparison, source-highlight can do about 5000 lines of C code per
+  second... And launching the program 100 times on an empty file takes about
+  5 seconds, which isn't bad. And, it has a C++ library, which it
+  seems likely perl bindings could be written for, to eliminate 
+  even that overhead.
+  > [highlight](http://www.andre-simon.de) has similar features to source-highlight, and swig bindings
+  > that should make it trivial in principle to call from perl.  I like highlight a bit better because 
+  > it has a pass-through feature that I find very useful.  My memory is unfortunately a bit fuzzy as to how
+  > well the swig bindings work. [[DavidBremner]]
+
 
-* Using non-perl syntax highlighting backends is slow. I'd prefer either
-  using a perl module, or a multiple-backend solution that can use a perl
-  module as one option. (Or, if there's a great highlighter python module,
-  we could use an external plugin..)
+* Engines that already support a wide variety of file types are of
+  course preferred. If the engine doesn't support a particular type
+  of file, it could fall back to doing something simple like
+  adding line numbers. (IkiWiki-Plugin-syntax does this.)
+* XHTML output.
+* Emitting html that uses CSS to control the display is preferred,
+  since it allows for easy user customization. (Engine::Simple does
+  this; Kate can be configured to do it; source-highlight can be 
+  made to do it via the switches `--css /dev/null --no-doc`)
 * Nothing seems to support 
   [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
   inside source files. Doing this probably means post-processing the 
@@ -67,7 +92,8 @@ releases the 5 or 6 language definitions he has running on his web site, it migh
 
 * 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. That also should handle the
+  registering the htmlize hooks, though. There's also a noextension option
+  that should handle the
   case of source files with names that do not contain an extension (ie,
   "Makefile") -- in this case you just register the while filename
   in the htmlize hook.