Emacs

Longlines mode in Emacs

I was getting frustrated with the fact that Emacs default modes didn’t handle long lines well.  This is fine for editing code where I keep all lines under 80 characters, but for editing documents it was a pain.  Going to the end of a line <Ctl> + E took you to the beginning of a paragraph since Emacs was concerned with the actual line of the file, not the displayed line.  The solution is longlines mode. This mode breaks up long lines for editing, and still saves them as a single line.  I used to have to download and install it.  Now it is bundled with Emacs 22.  Nice.

<Alt>+x, longlines-mode

Installing Emacs 22 on Ubuntu Feisty Fawn

Update: Emacs22 is now available via apt. Before trying this try sudo apt-get install emacs22. You will still need to edit your .emacs file as instructed in the last paragraph to handle Java annotations.

Emacs 22 is now released. I have installed on my Ubuntu Feisty Fawn system. The package is not yet available on the apt repositories, so this required building from source. Here are the steps I followed:

Install prerequisites as follows:
sudo apt-get install g++
sudo apt-get install libgtk2.0-dev

Download the source from http://ftp.gnu.org/pub/gnu/emacs/emacs-22.1.tar.gz.

After unpacking, run:
./configure --with-gtk --enable-font-backend --with-xft --with-freetype
make
sudo make install

Voila! The executable is now installed at: /usr/local/bin/emacs-22.1

The java-mode still does not handle annotations correctly. Getting around this requires adding the following to the ~/.emacs file. It simply treats annotations as comments:

(add-hook
 'java-mode-hook
 '(lambda () "Treat Java 1.5 @-style annotations as comments."
    (setq c-comment-start-regexp "(@|/(/|[*][*]?))")
    (modify-syntax-entry ?@ "< b" java-mode-syntax-table)))

Creating a Swing Test Runner for Maven 2

I have been a devoted Emacs user since a co-worker introduced it to me in 2001. Emacs’ efficient layout of keystrokes enables me to work faster and longer with less hand fatigue than other editors. My optimal Java development environment is a bash shell (Cygwin if using Windows), Emacs, and a good build tool such as Maven. I feel a sense of commitment to this setup since I have been using it for over 6 years now.

Recently I have been switching projects from Maven 1 to Maven 2. This has been great except for the fact that Maven 2 does not have a GUI test runner for unit tests. Suddenly my optimal development environment is missing a test runner. In Maven 1, the test:ui goal would invoke the org.juint.swing.SwingRunner. There is an open issue for this in the Surefire JIRA to add back the GUI support to the command line, but it doesn’t look like it will be addressed any time soon.

So what to do?

One solution is to bite the bullet and join the rest of the world and use an IDE like Eclipse. This is definitely the path of least resistance. I have tried this, but it just hasn’t worked for me. I simply don’t flow as well with Eclipse.

I am thinking that the best solution is to create a Swing test runner for Maven 2. I have been looking at what this will take and have identified some components of a design. Here goes:

  • I would focus solely on TestNG for now.
  • It would be nice if the test runner did not need to be restarted after each compilation. I could see myself keeping the test runner window open, and issuing mvn compile commands in a separate window.
  • The test runner would need to fork the execution of the tests - running them in a completely separate class loader. This in itself would not be difficult. The test runner would just instantiate Surefire in the same way that the Maven Surefire plug-in does.
  • Surefire would need to know about the classpath. This could be done differently depending if the test runner were invoked from maven or from the command line.
  • The real challenge would involve reporting test events from the tests running in the surefire class loader back to the Swing application. The Eclipse plug-in for TestNG uses the RemoteTestNG class and a set of socket communications back to the GUI. I expect something similar would need to be done.

I expect to have some progress on this over the next couple of weeks, as spare time permits.