2bbaeedfafd70e65f48b1f10679a7ecc625aefdc
[ikiwiki.git] / 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]]. (Currently a 404 :-( )
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 source-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 source-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 source-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 [[!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).
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 / requirements
39
40 * Using non-perl syntax highlighting backends is slower. All things equal,
41   I'd prefer either using a perl module, or a multiple-backend solution that
42   can use a perl module as one option. (Or, if there's a great highlighter
43   python module, we could use an external plugin..)
44
45   Of course, some perl modules are also rather slow.. Kate, for example
46   can only process about 33 lines of C code, or 14 lines of
47   debian/changelog per second. That's **30 times slower than markdown**!
48
49   By comparison, source-highlight can do about 5000 lines of C code per
50   second... And launching the program 100 times on an empty file takes about
51   5 seconds, which isn't bad. And, it has a C++ library, which it
52   seems likely perl bindings could be written for, to eliminate 
53   even that overhead.
54
55 * Engines that already support a wide variety of file types are of
56   course preferred. If the engine doesn't support a particular type
57   of file, it could fall back to doing something simple like
58   adding line numbers. (IkiWiki-Plugin-syntax does this.)
59 * XHTML output.
60 * Emitting html that uses CSS to control the display is preferred,
61   since it allows for easy user customization. (Engine::Simple does
62   this; Kate can be configured to do it; source-highlight can be 
63   made to do it via the switches `--css /dev/null --no-doc`)
64 * Nothing seems to support 
65   [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
66   inside source files. Doing this probably means post-processing the 
67   results of the highlighting engine, to find places where it's highlighted
68   comments, and then running them through the ikiwiki rendering pipeline.
69   This seems fairly doable with [[!cpan Syntax::Highlight::Engine::Kate]],
70   at least.
71 * The whole-file plugins tend to have a problem that things that look like
72   wikilinks in the source code get munged into links by ikiwiki, which can
73   have confusing results. Similar problem with preprocessor directives.
74   One approach that's also been requested for eg,
75   [[plugins/contrib/mediawiki]] is to allow controlling which linkification
76   types a page type can have on it.
77
78   > The previous two points seem to be related.  One thought: instead of
79   > getting the source from the `content` parameter, the plugin could
80   > re-load the page source.  That would stop directives/links from
81   > being processed in the source.  As noted above, comments
82   > could then be parsed for directives/links later.
83   >
84   > Would it be worth adding a `nodirectives` option when registering
85   > an htmlize hook that switches off directive and link processing before
86   > generating the html for a page?
87
88 * The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
89   This is trivially fixable now by passing the keepextension option when
90   registering the htmlize hooks, though. There's also a noextension option
91   that should handle the
92   case of source files with names that do not contain an extension (ie,
93   "Makefile") -- in this case you just register the while filename
94   in the htmlize hook.
95 * Whole-file plugins register a bunch of htmlize hooks. The wacky thing
96   about it is that, when creating a new page, you can then pick "c" or
97   "h" or "pl" etc from the dropdown that normally has "Markdown" etc in it.
98   Is this a bug, or a feature? Even if a feature, plugins with many
99   extensions make the dropdown unusable.. 
100
101   Perhaps the thing to do here is to use the new `longname` parameter to
102   the format hook, to give them all names that will group together at or
103   near the end of the list. Ie: "Syntax: perl", "Syntax: C", etc.
104
105 ## format directive and comments
106
107 Hmm, the [[ikiwiki/directive/format]] directive would also allow comments
108 inside source files to have mdwn embedded in them, without making the use
109 of mdwn a special case, or needing to postprocess the syntax highlighter
110 output to find comments.
111
112         /* \[[!format mdwn """
113
114         This is a comment in my C file. You can use mdwn in here.
115
116         """]] */
117
118 Note that this assumes that directives are expanded in source files,
119 which has its own set of problems.