diff options
author | Joey Hess <joey@gnu.kitenet.net> | 2009-04-04 17:27:48 -0400 |
---|---|---|
committer | Joey Hess <joey@gnu.kitenet.net> | 2009-04-04 17:27:48 -0400 |
commit | 8e92468eae9ac0ab8161a0c71ff6c6a0a8aef07a (patch) | |
tree | 9e26465e0ca98a5f3cbc6c72a0cace4bf83b93db /doc/todo/syntax_highlighting.mdwn | |
parent | 78a69e5bd632eb86ef8135e9c1d05d2c48b43362 (diff) | |
parent | 08fda4c9d374de1d3de3172a192d4d915d3dc0c1 (diff) | |
download | ikiwiki-8e92468eae9ac0ab8161a0c71ff6c6a0a8aef07a.tar ikiwiki-8e92468eae9ac0ab8161a0c71ff6c6a0a8aef07a.tar.gz |
Merge branch 'master'
Conflicts:
doc/ikiwiki-makerepo.mdwn
Diffstat (limited to 'doc/todo/syntax_highlighting.mdwn')
-rw-r--r-- | doc/todo/syntax_highlighting.mdwn | 133 |
1 files changed, 133 insertions, 0 deletions
diff --git a/doc/todo/syntax_highlighting.mdwn b/doc/todo/syntax_highlighting.mdwn new file mode 100644 index 000000000..b5d083ba5 --- /dev/null +++ b/doc/todo/syntax_highlighting.mdwn @@ -0,0 +1,133 @@ +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. + Updated to work with the fix for [[bugs/multiple_pages_with_same_name]]. Untested with files with no extension, e.g. `Makefile`. +* [[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=HEAD) 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). +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 + +* 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? + +* 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. + One approach that's also been requested for eg, + [[plugins/contrib/mediawiki]] is to allow controlling which linkification + types a page type can have on it. + + > The previous two points seem to be related. One thought: instead of + > getting the source from the `content` parameter, the plugin could + > re-load the page source. That would stop directives/links from + > being processed in the source. As noted above, comments + > could then be parsed for directives/links later. + > + > Would it be worth adding a `nodirectives` option when registering + > an htmlize hook that switches off directive and link processing before + > generating the html for a page? + +* 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.. 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: + + \[[!format pl """..."""]] + +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..) + +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. + + /* \[[!format mdwn """ + + This is a comment in my C file. You can use mdwn in here. + + """]] */ + +Note that this assumes that directives are expanded in source files. |