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