CodeBlockColorizer

This page is about syntax highlighting, colorizing pre sections and inlining attachments with parsing (i.e. colorization). Based on Taesu Pyo's BaseParser

Integration in moin--main--1.3

TLA Branch

ograf@bitart.de--2004-local/moin--colorize--1.3

Live Examples

Index
ColorizeTest
FormatTest
InlineTest

TODO (only in the branch):

MERGED (to moin--main--1.3):

Questions & Thoughts:

Alternate Highlighting

Taesu Pyo's BaseParser from ParserMarket is a possibility (and is currently used in the branch). But it is kind of hard labor to do all those parsers for all those formats out there. So why not use some existing syntax highlighting engine or definition?

Reuse highlighting from some other project

CSS for syntax coloring

Here is a module to manage the css styles for syntax coloring: css.py

The classes are based on Oliver version, made by joining X/Emacs and Vim definitions, but its very bad as is. A lot of the styles are useless and we have to group them in a way that make more sense, like put all stuff that usually displayed using the same color into one group.

We can duplicate the behavior of mature applications like Emacs and Vim, or try to improve and simplify. I know that I use only 4-5 colors and I don't need most of the fine grain control that those apps have. Code with too many harsh colors simply does not look good and hard to read. Less is more in this case.

The benefit of a simple structure is that we can add many simple colorizers that use only the main classes both for parsing the code and for formating. Basic support for a lot of languages is better than great colorizer for the language that you don't need.

Maybe something like this - feel free to improve this list:

First, the default group, that use the default font and color of code fragments:

Below are classes and their sub classes that use different colors:

Here is an example python code using default color scheme based on this list: color-test.html

TOC & Include

Problems with multiple or recursive Includes

Recursive and multiple Includes are a pain in the a**. They never can work with caching (in case of full page includes) cause the second include will get the same heading ids as the first. Solution: prefix ids with content-ID (its unique per default in this branch) and disable caching for ALL includes.

To make this more clear: there is only one cached copy of a page. This is the whole page, so from/to includes can't use the cache. If a page includes an other page multiple times, at least the second include will use the cached copy, inclusive all IDs (cause they are passed as arguments to the formatter). So double includes always break IDs if caching is used.

A possible solution is to put ID generation into the formatter. The text_python formatter has to uniquify the IDs, so the cached copy will always output unique IDs. But this will make everything harder for Include & TOC, cause they have to use the same method to generate the hrefs to the headings...

MoinMoin: CodeBlockColorizer (last edited 2007-10-29 19:09:45 by localhost)