I have spend a bit of time over the week end working with the jedit edit mode file for R code. That is the file that guides jedit on how to syntax highlight R code. The previous one I was using was based on the idea "let's put all the names of all the functions in standard R packages as keywords", although "it works", it is not a very good idea since it makes the edit mode huge and consequently must have some effect on jedit's performance when painting R code

The new mode file can be found on the biocep-editor project on r-forge

Here are some of the choices I have made

• function calls are highlighted with type FUNCTION. A function call is a name followed by a round bracket
• Core language constructs are highlighted with type KEYWORD1: (for, function, if, else, ifelse, in, repeat, return, switch, while, break, next) I have also added these to that list: (expression, quote, parse, deparse, substitute, get, getAnywhere, assign, exists, expression, bquote, typeof, mode, eval, evalq, with).
• Debugging related functions are highlighted with type KEYWORD2: browser, debug, trace, traceback, recover, undebug, isdebugged, bp, mtrace
• Error handling functions are highlighted using KEYWORD3: try, tryCatch, withRestarts, withCallingHandlers, stop, stopifnot, geterrmessage, warning, signalCondition, simpleCondition, simpleError, simpleWarning, simpleMessage, conditionCall, conditionMessage, computeRestarts, findRestart, invokeRestart, invokeRestartInteractively, isRestart, restartDescription, restartFormals, .signalSimpleWarning, .handleSimpleError
• Object Oriented related functions (S3 and S4) are using type KEYWORD4: class, inherits, setClass, representation, structure, methods, setIs, slot, new, setMethod, validObject, setValidity, getValidity, initialize, setOldClass, callNextMethod, NextMethod, UseMethod, getS3method
• Constants are using type LITERAL2: NULL, Inf, NULL, NA, NaN, T, TRUE, F, FALSE, pi, NA_character_, NA_complex_, NA_integer_, NA_real_
• Apply functions are using LITERAL4: lapply, sapply, by, mapply, tapply, apply, replicate, aggregate. I have also added some functions from the packages reshape and plyr to that list
• Support for R4X by delegating to the R4X mode (mainly XML) between strings "'##((xml" and "'##xml))"
• Support for Roxygen comment, inspired from the way javadoc comments are treated in the java mode

Qt Jambi

I've been looking at excuses to learn Qt for some time now, but could not really justify to myself going back to C++, but now with jambi, you can write Qt programs in java. More importantly, with the Qt Jambi to Awt bridge, you can melt swing components in Qt windows and Qt widgets in swing components. Here is a picture of some swing components in a QWidget

and another one with some Qt components in a swing frame

See this code snippet for how it is easy to do:

12         QGridLayout layout = new QGridLayout(this);
13 
14         // A few Qt widgets
15         layout.addWidget(new QLabel("First name:"), 0, 0);
16         layout.addWidget(new QLineEdit(), 0, 1);
17         layout.addWidget(new QLabel("Last name:"), 1, 0);
18         layout.addWidget(new QLineEdit(), 1, 1);
19 
20         // The AWT part of the GUI
21         {
22             JPanel panel = new JPanel();
23 
24             panel.setLayout(new GridLayout(1, 2));
25 
26             panel.add(new JLabel("Social security number:"));
27             panel.add(new JTextField());
28 
29             // Add the AWT panel to Qt's layout
30             layout.addWidget(new QComponentHost(panel), 2, 0, 1, 2);
31         }
32 

beyond hello world

So I wanted to go beyond the hello world level, and try to integrate jedit in a Qt window. If it works, this could lead to interesting things such as distributing jedit dockable windows through Qt system QtDockWidget which should be easy based on the new abstract docking window manager service in jedit, or using Qt widgets to extend jedit, ...

I managed to embed jedit in a Qt window, although I had to trick jedit to not build a JFrame when a view is created, I've used the same trick as in biocep workbench, which is writing a small patch to the jEdit class so that the view (which is a JFrame) is never set to visible, and its content pane borrowed by some other component, in that case, a Qt component. Here is how everything looks like:

$ tree
.
|-- build.properties
|-- build.xml
|-- jambidocking
|   |-- data
|   |   |-- JambiDockingPlugin.props
|   |   |-- actions.xml
|   |   `-- services.xml
|   `-- src
|       `-- JambiDocking
|           |-- JambiDockingDockingLayout.java
|           |-- JambiDockingWindowManager.java
|           |-- Plugin.java
|           `-- Provider.java
|-- src
|   |-- com
|   |   `-- addictedtor
|   |       `-- jambijedit
|   |           `-- JambiJedit.java
|   `-- org
|       `-- gjt
|           `-- sp
|               `-- jedit
|                   `-- jEdit.java
`-- src_qtjambiawtbridge
    `-- com
        `-- trolltech
            `-- research
                `-- qtjambiawtbridge
                    |-- QComponentHost.java
                    |-- QWidgetHost.java
                    |-- QWidgetWrapper.java
                    |-- QtJambiAwtBridge.java
                    |-- RedirectContainer.java
                    |-- examples
                    |   |-- AwtInQt.java
                    |   `-- QtInAwt.java
                    `-- generated
                        |-- QComponentHostNative.java
                        |-- QWidgetHostNative.java
                        `-- QtJambi_LibraryInitializer.java

19 directories, 21 files

Apart from the code of the Qt Jambi to Awt bridge, there is the patched jEdit.java, the JambiJedit.java file which basically creates a Qt main window and sets jedit as its central widget, and the jambidocking directory which contains the start of an implementation of jedit's shiny new DockableWindowManager system (more on that later)

The good news is that it works, the bad news is that it sort of works

Bad things start to happen when I tried to implement the DockableWindowManager system, here is the kind of messages I get, I suppose the issue is that jedit uses threading quite a lot and Qt is not happy about it

     [java] Exception in thread "main" 7:25:23 PM [main] [error] main: QObject used from outside its own thread, object=com::trolltech::research::qtjambiawtbridge::QComponentHost(0xa305370) , objectThread=Thread[AWT-EventQueue-0,6,main], currentThread=Thread[main,5,main]
     [java] 7:25:23 PM [main] [error] main:  at com.trolltech.qt.GeneratorUtilities.threadCheck(GeneratorUtilities.java:56)
     [java] 7:25:23 PM [main] [error] main:  at com.trolltech.research.qtjambiawtbridge.generated.QComponentHostNative.event(QComponentHostNative.java:37)
     [java] 7:25:23 PM [main] [error] main:  at com.trolltech.research.qtjambiawtbridge.QComponentHost.event(QComponentHost.java:35)
     [java] 7:25:23 PM [main] [error] main:  at com.trolltech.qt.gui.QApplication.exec(Native Method)
     [java] 7:25:23 PM [main] [error] main:  at com.addictedtor.jambijedit.JambiJedit.main(Unknown Source)
     [java] QPixmap: It is not safe to use pixmaps outside the GUI thread
     [java] QPixmap: It is not safe to use pixmaps outside the GUI thread
     [java] QPixmap: It is not safe to use pixmaps outside the GUI thread
     [java] QPixmap: It is not safe to use pixmaps outside the GUI thread
     [java] QPixmap: It is not safe to use pixmaps outside the GUI thread
     [java] QPixmap: It is not safe to use pixmaps outside the GUI thread

Anyway, I zipped it up here in case someone else wants to have a go. It is not quite there yet but at least now I have my excuse to learn Qt, which was the original point ...

jedit usually makes a good job of editing files with various languages in it, for example jsp files contain some java code, sweave files contain some R code, brew templates contain R code, R code might contain XML code (if you use the R4X package, but we'll get to this one some other time). Unfortunately, because jedit uses the same color styles for all languages, you don't get so much of a visual aid to tell you that you switched languages, enters Nested

Nested is a simple jedit plugin that paints the background of a code chunk differently if this code is not coming from the same mode as the mode of the buffer, and the color is left to the user's choice. Here is an example with some java code within a JSP file, the pink background around the java statement comes from the Nested plugin.

The colours are controlled by a file residing on the plugin directory that looks like this :

html,css,#eeeeee
jaxx,java,#ccff99
jaxx,xml,#ffffff
jsp,java,#fff2ff

but you can also use the Nested dockable window to control things

Java code will appear in pink inside a jsp file, java code will appear green inside jaxx files, ... and you can click on the colour if you want to change it to something else

When you open a file that contains sub-languages, an entry will automatically be inserted in the settings if it does not exist yet, in that case, the colour used is the same as the background color of the view, so that by default nothing changes.

For highlighting code inside latex documents there are several options:

• the listings package (somehow supported by the R package SweaveListingUtils
• Using highlight. I am using it in the graph gallery for example
• There are probably other ways ...

This might be a judgement call, but I don't find the latex output of listings or highlight to be visually pleasing enough, but maybe it is just a lack of understanding on how to customize them. Anyway, jedit has the Code2HTML plugin which does a good job of translating the buffer being edited in jedit into html markup, preserving pretty much everything that appear on the jedit text area. This takes advantage of jedit mode files which offers a great deal of flexibility, including nested languages, such as javascript/php, or R and Sweave if you have the right mode files.
So I had a look into the code of the Code2HTML plugin which is simple enough, and have basically done a big s/html/latex/g to support latex output (I realize this is not the best option and I should probably abstract things out so that it would be easier to add new formats: ansi, svg, ...) but it does the trick for now. Here is a screenshot of an example file edited in jedit: And a screenshot of the pdf file Here are the relevant files if you want to try it out:

• The modified source of Code2HTML
• The actual jar file
• An example R file
• ... once translated into latex markup
• ... once compile with pdflatex

Next steps:

• do something about the gutter
• figure out how to invoke that from the command line
• write a sweave driver that would call it so that R code appears formatted in sweave documents

It is often useful when you close a bracket to know which bracket is the corresponding opening bracket, for this jedit has the StructureMatcher interface and the default implementation gives you this information, by surrounding the opening bracket when you type its associated closing bracket.

On the other hand, the XML plugin gives you a more useful information when closing an XML tag. Let's see it in action with this simple XML file from the w3c

On the left, the caret is within the </note> closing tag and so the entire opening <note> tag is being highlighted. Similarly, on the right, the caret is within the opening <heading> tag and consequently the closing </heading> gets highlighted. This is particularly useful when editing xml documents.

So the idea was to have the same sort of behaviour for R scripts. Here's a start, but I also plan to do something with the curly brackets to deal with for loops, function definitions and various apply calls, ... (see that post)

Dependencies

biocep.jar

You need to have the workbench installed on your machine, meaning you need the biocep.jar file to be somewhere you know. Instructions on how to get it and install it can be found on the biocep page. Since the power editor follows the developpment of the workbench closely, I would recommend to build the biocep.jar from source, which can be done by retrieveing the biocep project from r-forge :

$ svn checkout svn://svn.r-forge.r-project.org/svnroot/biocep
$ cd biocep
$ ant distrib

For this to work you need java (>= 1.5) and ant installed. This should create a file biocep.jar that you can copy wherever you like. On my linux machine, I usually put a copy at "/opt/biocep/biocep.jar"

java and ant

the plugin is written in java, so you need a JDK (at least 1.5) installed and also ant.

R packages

The svTools package (from the sciviews) project contains most of the R side code needed by the plugin. At the time of writing, this package is not on CRAN, so you need to install it (and its dependencies) from r-forge:

• svTools : install.packages("svTools",repos="http://R-Forge.R-project.org")
• operators: install.packages("operators",repos="http://R-Forge.R-project.org")
• svMisc: install.packages("svMisc",repos="http://R-Forge.R-project.org")

Retrieve the project from r-forge

You can checkout the biocep-editor project from r-forge by :

$ svn checkout svn://svn.r-forge.r-project.org/svnroot/biocep-editor
$ cd biocep-editor

Once the project is retrieved, you need to edit the file build.properties.sample and rename it build.properties.
The most important properties to edit are "biocep.dir" and "install.dir" :

• biocep.dir is the name of the directory where the biocep.jar file is located (/opt/biocep in my settings)
• install.dir is the name of the directory where the Editor plugin will be installed, it will be something like "C:\Documents and Settings\romain\RWorkbench\plugins" on windows and something like "/home/romain/RWorkbench/plugins/Editor" on linux

You should not need to modify other properties as default values are suitable to build the plugin.

Two "modes" of installation

Dependent mode

The power editor plugin mainly consists of jedit (and jedit plugins) slightly patched so that it can be used as a view of the workbench instead of a main application. The plugin has been developped so that it can coexist with another installed copy of jedit and share the same set of plugins, this is the dependent mode of install because it depends on an installed copy of jedit. Note however that it will only work with versions of jedit greater or equal to 4.3pre16.

The ant targets "installDependent" and "zipDependent" can be used to install or create a zip of the plugin. Since with this mode, we are going to depend on another installed version of jedit, we need to let the plugin know about this version, this is achieved by modifying the file "jedit.properties" with appropriate values of the two properties :

• jedit.home: this is the directory where jedit is installed. A "jedit.jar" file must live in this directory along with directories such as modes and jars. I usually install jedit in the directory "/opt/jedit" on my linux machines and under "C:\Program Files\jEdit" on my windows machines.
• jedit.settings: this is the settings directory of jedit, containing jedit plugins (in the jars directory), user mode files (in the modes) directory, ... on my linux machines, it usually is "/home/romain/.jedit" and on my windows machines "C:\Documents and Settings\romain\.jedit"

Once this file is edited, installing the plugin is achieved with the "installDependent" ant target:

$ ant installDependent

Standalone mode

However, you do not need to have jedit installed for the plugin to work at all, if you do not have jedit installed otherwise, you will use the standalone mode of installation of the plugin. In this mode, you do not need to edit the jedit.properties file since a dummy one will be generated by ant, simply build the plugin using the "installStandalone" target:

ant installStandalone

Check that the plugin is installed

After succesful installation, the workbench should contain the menu item "Plugins > Editor > Power Editor"