doc/todo/syntax_highlighting.mdwn

   1 There's been a lot of work on contrib syntax highlighting plugins. One should be
   2 picked and added to ikiwiki core.
   3
   4 > I'm calling this [[done]] since I added the [[plugins/highlight]]
   5 > plugin. There are some unresolved issues touched on here,
   6 > but they either have the own other bug reports, or are documented
   7 > as semi-features in the docs to the plugin. --[[Joey]]
   8
   9 We want to support both converting whole source files into wiki
  10 pages, as well as doing syntax highlighting as a preprocessor directive
  11 (which is either passed the text, or reads it from a file). But,
  12 the [[ikiwiki/directive/format]] directive makes this easy enough to
  13 do if the plugin only supports whole source files. So, syntax plugins
  14 do no really need their own preprocessor directive, unless it makes
  15 things easier for the user.
  16
  17 ## The big list of possibilities
  18
  19 * [[plugins/contrib/highlightcode]] uses [[!cpan Syntax::Highlight::Engine::Kate]],
  20   operates on whole source files only, has a few bugs (see
  21   [here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to
  22   support [[bugs/multiple_pages_with_same_name]]. (Currently a 404 :-( )
  23 * [[!cpan IkiWiki-Plugin-syntax]] only operates as a directive.
  24   Interestingly, it supports multiple highlighting backends, including Kate
  25   and Vim.
  26 * [[plugins/contrib/syntax]] only operates as a directive
  27   ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]),
  28   and uses [[!cpan Text::VimColor]].
  29 * [[plugins/contrib/sourcehighlight]] uses source-highlight, and operates on
  30   whole source files only. Needs to be updated to
  31   support [[bugs/multiple_pages_with_same_name]].
  32 * [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]
  33   also uses source-highlight, and operates on whole source files.
  34   Updated to work with the fix for [[bugs/multiple_pages_with_same_name]].  Untested with files with no extension, e.g. `Makefile`.
  35 * [[users/jasonblevins]]'s code plugin uses source-highlight, and supports both
  36   whole file and directive use.
  37
  38 * [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).
  39 On the other hand, there are not many predefined languages yet.  Defining language syntaxes is about as much
  40 work as source-highlight, but in perl.  I plan to package the base module for debian. Perhaps after the author
  41 releases the 5 or 6 language definitions he has running on his web site, it might be suitable for inclusion in ikiwiki. [[DavidBremner]]
  42
  43 * [[plugins/highlight]] uses [highlight](http://www.andre-simon.de) via
  44   its swig bindings. It optionally supports whole files, but also
  45   integrates with the format directive to allow formatting of *any* of
  46   highlight's supported formats. (For whole files, it uses either
  47   keepextension or noextension, as appropriate for the type of file.)
  48
  49 ## General problems / requirements
  50
  51 * Using non-perl syntax highlighting backends is slower. All things equal,
  52   I'd prefer either using a perl module, or a multiple-backend solution that
  53   can use a perl module as one option. (Or, if there's a great highlighter
  54   python module, we could use an external plugin..)
  55
  56   Of course, some perl modules are also rather slow.. Kate, for example
  57   can only process about 33 lines of C code, or 14 lines of
  58   debian/changelog per second. That's **30 times slower than markdown**!
  59
  60   By comparison, source-highlight can do about 5000 lines of C code per
  61   second... And launching the program 100 times on an empty file takes about
  62   5 seconds, which isn't bad. And, it has a C++ library, which it
  63   seems likely perl bindings could be written for, to eliminate
  64   even that overhead.
  65   > [highlight](http://www.andre-simon.de) has similar features to source-highlight, and swig bindings
  66   > that should make it trivial in principle to call from perl.  I like highlight a bit better because
  67   > it has a pass-through feature that I find very useful.  My memory is unfortunately a bit fuzzy as to how
  68   > well the swig bindings work. [[DavidBremner]]
  69
  70 * Engines that already support a wide variety of file types are of
  71   course preferred. If the engine doesn't support a particular type
  72   of file, it could fall back to doing something simple like
  73   adding line numbers. (IkiWiki-Plugin-syntax does this.)
  74 * XHTML output.
  75 * Emitting html that uses CSS to control the display is preferred,
  76   since it allows for easy user customization. (Engine::Simple does
  77   this; Kate can be configured to do it; source-highlight can be
  78   made to do it via the switches `--css /dev/null --no-doc`)
  79 * Nothing seems to support
  80   [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
  81   inside source files. Doing this probably means post-processing the
  82   results of the highlighting engine, to find places where it's highlighted
  83   comments, and then running them through the ikiwiki rendering pipeline.
  84   This seems fairly doable with [[!cpan Syntax::Highlight::Engine::Kate]],
  85   at least.
  86 * The whole-file plugins tend to have a problem that things that look like
  87   wikilinks in the source code get munged into links by ikiwiki, which can
  88   have confusing results. Similar problem with preprocessor directives.
  89   One approach that's also been requested for eg,
  90   [[plugins/contrib/mediawiki]] is to allow controlling which linkification
  91   types a page type can have on it.
  92
  93   > The previous two points seem to be related.  One thought: instead of
  94   > getting the source from the `content` parameter, the plugin could
  95   > re-load the page source.  That would stop directives/links from
  96   > being processed in the source.  As noted above, comments
  97   > could then be parsed for directives/links later.
  98   >
  99   > Would it be worth adding a `nodirectives` option when registering
 100   > an htmlize hook that switches off directive and link processing before
 101   > generating the html for a page?
 102
 103 * The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
 104   This is trivially fixable now by passing the keepextension option when
 105   registering the htmlize hooks, though. There's also a noextension option
 106   that should handle the
 107   case of source files with names that do not contain an extension (ie,
 108   "Makefile") -- in this case you just register the while filename
 109   in the htmlize hook.
 110 * Whole-file plugins register a bunch of htmlize hooks. The wacky thing
 111   about it is that, when creating a new page, you can then pick "c" or
 112   "h" or "pl" etc from the dropdown that normally has "Markdown" etc in it.
 113   Is this a bug, or a feature? Even if a feature, plugins with many
 114   extensions make the dropdown unusable..
 115
 116   Perhaps the thing to do here is to use the new `longname` parameter to
 117   the format hook, to give them all names that will group together at or
 118   near the end of the list. Ie: "Syntax: perl", "Source code: c", etc.