There's been a lot of work on contrib syntax highlighting plugins. One should be
picked and added to ikiwiki core.
-Ideally, it should support both converting whole source files into wiki
+We want to support both converting whole source files into wiki
pages, as well as doing syntax highlighting as a preprocessor directive
-(which is either passed the text, or reads it from a file).
+(which is either passed the text, or reads it from a file). But,
+the [[ikiwiki/directive/format]] directive makes this easy enough to
+do if the plugin only supports whole source files. So, syntax plugins
+do no really need their own preprocessor directive, unless it makes
+things easier for the user.
## The big list of possibilities
* [[plugins/contrib/highlightcode]] uses [[!cpan Syntax::Highlight::Engine::Kate]],
operates on whole source files only, has a few bugs (see
[here](http://u32.net/Highlight_Code_Plugin/), and needs to be updated to
- support [[bugs/multiple_pages_with_same_name]].
+ support [[bugs/multiple_pages_with_same_name]]. (Currently a 404 :-( )
* [[!cpan IkiWiki-Plugin-syntax]] only operates as a directive.
Interestingly, it supports multiple highlighting backends, including Kate
and Vim.
* [[users/jasonblevins]]'s code plugin uses src-highlight, and supports both
while file and directive use.
-* [hlsimple](http://pivot.cs.unb.ca/git/?p=ikiplugins.git;a=blob_plain;f=IkiWiki/Plugin/hlsimple.pm;hb=795f888a2c1b17f6d90a8f01f74b09395f0738d5) 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).
+* [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).
On the other hand, there are not many predefined languages yet. Defining language syntaxes is about as much
work as source-highlight, but in perl. I plan to package the base module for debian. Perhaps after the author
releases the 5 or 6 language definitions he has running on his web site, it might be suitable for inclusion in ikiwiki. [[DavidBremner]]
-## General problems
+## General problems / requirements
* Using non-perl syntax highlighting backends is slow. I'd prefer either
using a perl module, or a multiple-backend solution that can use a perl
module as one option. (Or, if there's a great highlighter python module,
we could use an external plugin..)
-* Currently no single plugin supports both modes of operation (directive
- and whole source file to page).
-
- > This is now fixed by the [[ikiwiki/directive/format]] directive for all
- > whole-source-file plugins, right?
-
+* Engines that already support a wide variety of file types are of
+ course preferred. If the engine doesn't support a particular type
+ of file, it could fall back to doing something simple like
+ adding line numbers. (IkiWiki-Plugin-syntax does this.)
+* Emitting html that uses CSS to control the display is preferred,
+ since it allows for easy user customization.
* Nothing seems to support
[[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
inside source files. Doing this probably means post-processing the
* The whole-file plugins all get confused if there is a `foo.c` and a `foo.h`.
This is trivially fixable now by passing the keepextension option when
- registering the htmlize hooks, though.
+ registering the htmlize hooks, though. That also should handle the
+ case of source files with names that do not contain an extension (ie,
+ "Makefile") -- in this case you just register the while filename
+ in the htmlize hook.
* Whole-file plugins register a bunch of htmlize hooks. The wacky thing
about it is that, when creating a new page, you can then pick "c" or
- "h" or "pl" etc from the dropdown that normally has "mdwn" etc in it.
- Is this a bug, or a feature? (Even if a feature, plugins with many
- extensions make the dropdown unusable.. One way to deal with that is have
- a config setting that lists what extensions to offer highlighting for.
- Most people won't need/want the dozens some engines support.)
-* The per page highlighters can't handle creating wiki pages from
- "Makefile", or other files without a significant extension.
- Not clear how to fix this, as ikiwiki is very oriented toward file
- extensions. The workaround is to use a directive on a wiki page, pulling
- in the Makefile.
-
- > I wonder how hard it would be to make a patch whereby a file with
- > no `.` in the name, and a name that matches a filetype, and where
- > that filetype was registered `keepextension`, then the file is just
- > chosen as the appropriate type. This would allow `Makefile` to
- > work.
-
-like this:
-
- diff --git a/IkiWiki.pm b/IkiWiki.pm
- index 8d728c9..1bd46a9 100644
- --- a/IkiWiki.pm
- +++ b/IkiWiki.pm
- @@ -618,6 +618,8 @@ sub pagetype ($) {
-
- if ($page =~ /\.([^.]+)$/) {
- return $1 if exists $hooks{htmlize}{$1};
- + } elsif ($hooks{htmlize}{$page}{keepextension}) {
- + return $page;
- }
- return;
- }
-
-## format directive
-
-Rather than making syntax highlight plugins have to provide a preprocessor
-directive as well as handling whole source files, perhaps a generic format
-directive could be used:
+ "h" or "pl" etc from the dropdown that normally has "Markdown" etc in it.
+ Is this a bug, or a feature? Even if a feature, plugins with many
+ extensions make the dropdown unusable..
- \[[!format pl """..."""]]
+ Perhaps the thing to do here is to use the new `longname` parameter to
+ the format hook, to give them all names that will group together at or
+ near the end of the list. Ie: "Syntax: perl", "Syntax: C", etc.
-That would run the text through the pl htmlizer, from the syntax hightligh
-plugin. OTOH, if "rst" were given, it would run the text through the rst
-htmlizer. So, more generic, allows mixing different types of markup on one
-page, as well as syntax highlighting. Does require specifying the type of
-format, instead of allowing it to be guessed (which some syntax highlighters
-can do). (This directive is now implemented..)
+## format directive and comments
-Hmm, this would also allow comments inside source files to have mdwn
-embedded in them, without making the use of mdwn a special case, or needing
-to postprocess the syntax highlighter output to find comments.
+Hmm, the [[ikiwiki/directive/format]] directive would also allow comments
+inside source files to have mdwn embedded in them, without making the use
+of mdwn a special case, or needing to postprocess the syntax highlighter
+output to find comments.
/* \[[!format mdwn """
"""]] */
-Note that this assumes that directives are expanded in source files.
+Note that this assumes that directives are expanded in source files,
+which has its own set of problems.
sipb-www / ikiwiki.git / blobdiff