aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoey Hess <joey@kodama.kitenet.net>2008-10-26 19:43:57 -0400
committerJoey Hess <joey@kodama.kitenet.net>2008-10-26 19:43:57 -0400
commit65bf71d387ba406d4fcf697d76151b6953176cf8 (patch)
tree22e6954f3472aefb220dec883fecb12663a70278
parente8652cb0a55e6c458b700a25281eac3f2197a8d2 (diff)
downloadikiwiki-65bf71d387ba406d4fcf697d76151b6953176cf8.tar
ikiwiki-65bf71d387ba406d4fcf697d76151b6953176cf8.tar.gz
organizing and pulling together syntax highlighting info
-rw-r--r--doc/plugins/contrib/sourcehighlight.mdwn5
-rw-r--r--doc/todo/syntax_highlighting.mdwn54
-rw-r--r--doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn5
3 files changed, 63 insertions, 1 deletions
diff --git a/doc/plugins/contrib/sourcehighlight.mdwn b/doc/plugins/contrib/sourcehighlight.mdwn
index 2eb22e6ed..fb368945b 100644
--- a/doc/plugins/contrib/sourcehighlight.mdwn
+++ b/doc/plugins/contrib/sourcehighlight.mdwn
@@ -20,3 +20,8 @@ This problem with sourcehighlight needs to be fixed before it is very useful.
- Is there a way to configure the colors used by source-highlight (other than editing the globally installed "default.style" file)? It would help if I could pass the command arbitrary command-line arguments; then I could configure which config file it's supposed to use. For instance, I'm not a fan of hard-coding the colors into the HTML output. IMHO, css-style formatting should be preferred. All that can be set via the command line ... --Peter
> I don't really have time right now, but it should be easy to add, if you look at how src-lang is handled. Patches are welcome :-) --[[DavidBremner]]
+
+Note that [[Will]] wrote a plugin that uses source-highlight also. It's
+available
+[here|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]].
+--[[Joey]]
diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn
new file mode 100644
index 000000000..e992cc514
--- /dev/null
+++ b/doc/todo/syntax_highlighting.mdwn
@@ -0,0 +1,54 @@
+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
+pages, as well as doing syntax highlighting as a preprocessor directive
+(which is either passed the text, or reads it from a file).
+
+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]].
+* [[cpan IkiWiki-Plugin-syntax]] only operates as a directive.
+ Interestingly, it supports multiple highlighting backends, including Kate
+ and Vim.
+* [[plugins/contrib/syntax]] only operates as a directive
+ ([[not_on_source_code_files|automatic_use_of_syntax_plugin_on_source_code_files]]),
+ and uses [[cpan Text::VimColor]].
+* [[plugins/contrib/sourcehighlight]] uses src-highlight, and operates on
+ whole source files only. Needs to be updated to
+ support [[bugs/multiple_pages_with_same_name]].
+* [[sourcecode|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]]
+ also uses src-highlight, and operates on whole source files.
+ Has problems with [[bugs/multiple_pages_with_same_name]].
+
+General problems:
+
+* 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.
+* Currently no single plugin supports both modes of operation (directive
+ and whole source file to page).
+* Nothing seems to support
+ [[wiki-formatted_comments|wiki-formatted_comments_with_syntax_plugin]]
+ inside source files. Doing this probably means post-processing the
+ results of the highlighting engine, to find places where it's highlighted
+ comments, and then running them through the ikiwiki rendering pipeline.
+ This seems fairly doable with [[cpan Syntax::Highlight::Engine::Kate]],
+ at least.
+* The whole-file plugins tend to have a problem that things that look like
+ wikilinks in the source code get munged into links by ikiwiki, which can
+ have confusing results. Similar problem with preprocessor directives.
+* 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.
+* 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..)
+* The per page highlighters can't handle "Makefile", or other files
+ without a significant extension.
+*
diff --git a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
index 08ca61b0c..a5244c9ef 100644
--- a/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
+++ b/doc/todo/wiki-formatted_comments_with_syntax_plugin.mdwn
@@ -1 +1,4 @@
-[[Wishlist]] item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the [[plugins/contrib/syntax]] plugin. This would allow the use of links and formatting in comments.
+[[Wishlist]] item: I'd love to see the ability to optionally switch back to
+wiki syntax within the comments of code pretty-printed with the
+[[plugins/contrib/syntax]] plugin. This would allow the use of links and
+formatting in comments.