git.oblomov.eu Git - ikiwiki/blob - 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 We want to support both converting whole source files into wiki
   5 pages, as well as doing syntax highlighting as a preprocessor directive
   6 (which is either passed the text, or reads it from a file). But,
   7 the [[ikiwiki/directive/format]] directive makes this easy enough to
   8 do if the plugin only supports whole source files. So, syntax plugins
   9 do no really need their own preprocessor directive, unless it makes
  10 things easier for the user.
  11
  12 ## The big list of possibilities
  13
  14 * [[plugins/contrib/highlightcode]] uses [[!cpan Syntax::Highlight::Engine::Kate]],
  15   operates on whole source files only, has a few bugs (see
  16   [here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to
  17   support [[bugs/multiple_pages_with_same_name]].
  18 * [[!cpan IkiWiki-Plugin-syntax]] only operates as a directive.
  19   Interestingly, it supports multiple highlighting backends, including Kate
  20   and Vim.
  21 * [[plugins/contrib/syntax]] only operates as a directive
  22   ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]),
  23   and uses [[!cpan Text::VimColor]].
  24 * [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on
  25   whole source files only. Needs to be updated to
  26   support [[bugs/multiple_pages_with_same_name]].
  27 * [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]
  28   also uses src-highlight, and operates on whole source files.
  29   Updated to work with the fix for [[bugs/multiple_pages_with_same_name]].  Untested with files with no extension, e.g. `Makefile`.
  30 * [[users/jasonblevins]]'s code plugin uses src-highlight, and supports both
  31   while file and directive use.
  32
  33 * [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).
  34 On the other hand, there are not many predefined languages yet.  Defining language syntaxes is about as much
  35 work as source-highlight, but in perl.  I plan to package the base module for debian. Perhaps after the author
  36 releases the 5 or 6 language definitions he has running on his web site, it might be suitable for inclusion in ikiwiki. [[DavidBremner]]
  37
  38 ## General problems
  39
  40 * Using non-perl syntax highlighting backends is slow. I'd prefer either
  41   using a perl module, or a multiple-backend solution that can use a perl
  42   module as one option. (Or, if there's a great highlighter python module,
  43   we could use an external plugin..)
  44 * Currently no single plugin supports both modes of operation (directive
  45   and whole source file to page).
  46
  47   > This is now fixed by the [[ikiwiki/directive/format]] directive for all
  48   > whole-source-file plugins, right?
  49
  50 * Nothing seems to support
  51   [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
  52   inside source files. Doing this probably means post-processing the
  53   results of the highlighting engine, to find places where it's highlighted
  54   comments, and then running them through the ikiwiki rendering pipeline.
  55   This seems fairly doable with [[!cpan Syntax::Highlight::Engine::Kate]],
  56   at least.
  57 * The whole-file plugins tend to have a problem that things that look like
  58   wikilinks in the source code get munged into links by ikiwiki, which can
  59   have confusing results. Similar problem with preprocessor directives.
  60   One approach that's also been requested for eg,
  61   [[plugins/contrib/mediawiki]] is to allow controlling which linkification
  62   types a page type can have on it.
  63
  64   > The previous two points seem to be related.  One thought: instead of
  65   > getting the source from the `content` parameter, the plugin could
  66   > re-load the page source.  That would stop directives/links from
  67   > being processed in the source.  As noted above, comments
  68   > could then be parsed for directives/links later.
  69   >
  70   > Would it be worth adding a `nodirectives` option when registering
  71   > an htmlize hook that switches off directive and link processing before
  72   > generating the html for a page?
  73
  74 * The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
  75   This is trivially fixable now by passing the keepextension option when
  76   registering the htmlize hooks, though.
  77 * Whole-file plugins register a bunch of htmlize hooks. The wacky thing
  78   about it is that, when creating a new page, you can then pick "c" or
  79   "h" or "pl" etc from the dropdown that normally has "mdwn" etc in it.
  80   Is this a bug, or a feature? (Even if a feature, plugins with many
  81   extensions make the dropdown unusable.. One way to deal with that is have
  82   a config setting that lists what extensions to offer highlighting for.
  83   Most people won't need/want the dozens some engines support.)
  84 * The per page highlighters can't handle creating wiki pages from
  85   "Makefile", or other files without a significant extension.
  86   Not clear how to fix this, as ikiwiki is very oriented toward file
  87   extensions. The workaround is to use a directive on a wiki page, pulling
  88   in the Makefile.
  89
  90   > I wonder how hard it would be to make a patch whereby a file with
  91   > no `.` in the name, and a name that matches a filetype, and where
  92   > that filetype was registered `keepextension`, then the file is just
  93   > chosen as the appropriate type.  This would allow `Makefile` to
  94   > work.
  95
  96 like this:
  97
  98     diff --git a/IkiWiki.pm b/IkiWiki.pm
  99     index 8d728c9..1bd46a9 100644
 100     --- a/IkiWiki.pm
 101     +++ b/IkiWiki.pm
 102     @@ -618,6 +618,8 @@ sub pagetype ($) {
 103
 104         if ($page =~ /\.([^.]+)$/) {
 105                 return $1 if exists $hooks{htmlize}{$1};
 106     +   } elsif ($hooks{htmlize}{$page}{keepextension}) {
 107     +           return $page;
 108         }
 109         return;
 110      }
 111
 112 ## format directive and comments
 113
 114 Hmm, the [[ikiwiki/directive/format]] directive would also allow comments
 115 inside source files to have mdwn embedded in them, without making the use
 116 of mdwn a special case, or needing to postprocess the syntax highlighter
 117 output to find comments.
 118
 119         /* \[[!format mdwn """
 120
 121         This is a comment in my C file. You can use mdwn in here.
 122
 123         """]] */
 124
 125 Note that this assumes that directives are expanded in source files,
 126 which has its own set of problems.