On 4 juin 08, at 14:49, malaka ekanayake wrote: The trick here is to well engineer the partitioner, i.e., the component that will break the actual text in a set of disjoint areas (the partitions) with a given content type. This is basically what is done in http://www.realsolve.co.uk/site/tech/jface-text.php where several partition types are identified. Once a good "partitioning model" for the document is built, then each partition, depending on its content-type, can be associated to a scanner for syntax highlighting, a content formatter, a content assistant, etc. All these components, in fact, can be assigned on a per-partition basis. This means that the granularity of the partitions should be evaluated even with respect to what support should be given to the user. For example, the partitioner could return a huge single partition of type XWIKI_DOCUMENT. But what a content assistant would be able to suggest in this case? Not too much. In the XML-Editor example the partitioner wisely identifies XML_START_TAG partitions so that a content assistant associated to this partition type can usefully suggest all the tags defined in the corresponding DTD. In XWiki, for example, an XWiki link is a good candidate for a partition type. This doesn't answer the question of how to architect a good partitioner for a document containing multiple languages... I would say that it should be possible to modularize partitioners, i.e., having a partitioner for XWiki, one for Velocity, one for Groovy, etc. and then have a main partitioner that delegates the work to the others when it see a given pattern. A good starting point for understanding if and how this could be done, is to have a look at the JDT code. After all a Java editor handles, in the same document, the Java and JavaDoc languages. To be practical I would suggest to start simple. You might try to write a standalone plugin (you can also start from the plugin with an editor template) with partitioner and a highlighter that is able to process the plain XWiki document, and to provide syntax highlighting for basic XWiki syntax elements. This should show you what are the issues in building such a kind of extension. Then we could try to think about velocity snippets and to combine what you wrote with something velocity specific. Even though you don't have the latest XEclipse, integrating your standalone plugin into XEclipse would be only a matter of setting your SourceViewerConfiguration in the constructor of org.xwiki.eclipse.ui.editors.PageEditor. Let's set a deadline in a week to see how far you can go. It would be good to have your plugin committed in the sandbox so that we can work together. Probably Vincent or another administrator can give you an account for accessing the sandbox. Of course, feel free to ask question in the meanwhile :) Cheers, Fabio