1 There's been a lot of work on contrib syntax highlighting plugins. One should be
2 picked and added to ikiwiki core.
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).
8 The big list of possibilities:
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
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 Has problems with [[bugs/multiple_pages_with_same_name]].
29 * Using non-perl syntax highlighting backends is slow. I'd prefer either
30 using a perl module, or a multiple-backend solution that can use a perl
31 module as one option. (Or, if there's a great highlighter python module,
32 we could use an external plugin..)
33 * Currently no single plugin supports both modes of operation (directive
34 and whole source file to page).
35 * Nothing seems to support
36 [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
37 inside source files. Doing this probably means post-processing the
38 results of the highlighting engine, to find places where it's highlighted
39 comments, and then running them through the ikiwiki rendering pipeline.
40 This seems fairly doable with [[cpan Syntax::Highlight::Engine::Kate]],
42 * The whole-file plugins tend to have a problem that things that look like
43 wikilinks in the source code get munged into links by ikiwiki, which can
44 have confusing results. Similar problem with preprocessor directives.
45 One approach that's also been requested for eg,
46 [[plugins/contrib/mediawiki]] is to allow controlling which linkification
47 types a page type can have on it.
48 * The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
49 This is trivially fixable now by passing the keepextension option when
50 registering the htmlize hooks, though.
51 * Whole-file plugins register a bunch of htmlize hooks. The wacky thing
52 about it is that, when creating a new page, you can then pick "c" or
53 "h" or "pl" etc from the dropdown that normally has "mdwn" etc in it.
54 Is this a bug, or a feature? (Even if a feature, plugins with many
55 extensions make the dropdown unusable.. One way to deal with that is have
56 a config setting that lists what extensions to offer highlighting for.
57 Most people won't need/want the dozens some engines support.)
58 * The per page highlighters can't handle creating wiki pages from
59 "Makefile", or other files without a significant extension.
60 Not clear how to fix this, as ikiwiki is very oriented toward file
61 extensions. The workaround is to use a directive on a wiki page, pulling