• What is JEmacs?
• Why create JEmacs?
• How does JEmacs work? What are the problems and how are they solved?
• Internationalization in JEmacs and Java.

JEmacs is a next-generation Emacs written in Java.

It includes:

• An implementation of the Scheme language.
• An implementation of the ELisp base language.
• Compilers for both to Java bytecodes.
• A set of Java classes, based on the Swing GUI api, that implement the Emacs "types", such as Buffer, Keymap, Window, Marker.
• A set of Scheme bindings to the Java methods. These are "similar to" and have the same names as standard Emacs Lisp functions, but are written in Scheme and intended to be called from Scheme.
• The equivalent ELisp functions: Implementations of the high-level Emacs functions as ELisp functions, so existing ELisp applications can (mostly) run without change.

This is a major undertaking. Some reasons why it might be worthwhile:

• Swing is a modern GUI toolkit with good support for major Emacs concepts.
• Building on a Java run-time means we benefit from the work being done to run Java (bytecodes) fast.
• Java is multi-threaded.
• Kawa is a modern object-oriented Scheme, while Emacs is based on rather old design ideas.
• Java is based on Unicode and has good internationalization support.
• Java has lots of neat packages we can use.
• It would be useful to have Scheme (and ELisp) scripting for Swing applications.
• It is a good way to learn Swing!
• One problem: There is no open-source Swing implementation.

Kawa is a Scheme implementation written in Java.

Kawa compiles Scheme definitions to Java bytecodes.
This provides decent performance, with fast response.
Benefits from products and research into fast Java execution.

Kawa is a modern object-oriented Scheme with many features, includes a full set of numeric types (including units), a module system, and easy Java/Scheme integration.

Kawa is GPL'd free software, used by a number of projects.

Part of Kawa is a package for generating Java bytecodes, plus a higher-level package using Expression objects.

These are used to generate efficient Java bytecodes from Scheme. There is also an incomplete compiler for EcmaScript (JavaScript).

Others are using Kawa to compile other languages.

I am working on compiling Emacs Lisp. This replaces the Emacs byte-compiler: Instead of .elc files loaded into the Emacs bytecode interpreter we use Java .class bytecode files loaded into a Java Virtual Machine.

Implementing ELisp raises some problems compared to Scheme:

• Slightly different reader syntax.
• ELisp treats false and empty list as the same; in Scheme they are different.
• Different set of pre-defined functions and macros.
• ELisp has a separate name-space for functions and variables.
• ELisp has dynamic scoping and buffer-local variables; Scheme has lexical scoping.

In Kawa, each global variable is a Binding object.

A Binding has an optional name, a value field, and a Constraint.

The constraint contains the actual methods that get/set the value of the Binding.

Setting b to x does b.constraint.set(b, x).

The default action for get retrieves the Binding's value field.
Different sub-classes of Constraint have different implementations of get and set.

If there is a thread-local dynamic or buffer-local binding, we just put the appropriate constraint in the binding.

This framework can handle indirection, unbound variables (get throws an exception), and constraint propagation. Changing a value can trigger arbitrary checks or notification messages.

In Emacs, a mode is a set of keybindings, functions, and variables local to a buffer.

In JEmacs, it makes sense (not yet implemented) we want a separate mode class for each mode.

Each buffer has a linked list of mode instances, one for each major/minor mode of the buffer.

Mode functions are compiled to virtual methods of the mode object.

Instead of a buffer-local variable, use a field of the mode object.

Provides fast access to variables in compiled code, without run-ime symbol lookup.

A derived mode can use mode class inheritance.

Not clear if this model works for legacy ELisp code.

Swing is a new GUI toolkit introduced by Sun in 1998. It builds on the earlier AWT (Abstract Windowing Toolkit), but has new "widgets" based on separating the "model" (data) and "view+control" (look+feel).

Swing contains a number of concepts similar to or inspired by Emacs. Most importantly, separation between Document and JTextComponent is similar to that between Emacs buffer and window. JEmacs builds on this separation.

Swing also has a Keymap class similar to that of Emacs, and a Position is like an Emacs marker.

Unfortunately, neither of these are quite right for Emacs, but it was not difficult to create new classes that implement the Swing interfaces.

I wrote Java classes to implement the Emacs editing types:

• Buffer: An Emacs buffer. Contains a Swing StyledDocument that manages the actual text (and styles). Contains a BufferKeymap, which manages the actions executed for different keystrokes.
• BufferKeymap: A data structure in one-to-one association with a Buffer. It implements the Swing Keymap interface, and manages the primitive Keymaps, to give the Emacs functionality.
• Window: Extends the Swing JtextPane class. Includes an associated Modeline, and a scrollbar.
• Frame: A top-level window. A Frame contains a nested hierarchy of Windows, sub-divided using Swing's JSplitPane.
• Marker: A position in a buffer that gets adjusted as needed. Implements the Swing Position interface, but also knows the Buffer it points to.
• BufferContent: The actual characters of the Buffer. (A Buffer contains a Document, which used a BufferContent object,) This class is needed because standard Swing does not support the Marker semantics Emacs needs.

JEmacs includes a number of Scheme procedures for operating on the Java classes just mentioned.

The Scheme API is designed to be similar to the traditional ELisp functions, but put in Scheme form.

(define (beginning-of-line
         #!optional
         (n  :: <int> 1)
         (buffer :: <buffer> (current-buffer)))
  (invoke buffer 'setPoint (point-at-bol n buffer)))

(define-key global-map "\C-a" beginning-of-line)

This makes it easier to mix Scheme and ELisp, convert (if desired) ELisp to Scheme, and lets us re-use ELisp documentation.

Goal is to be able to run most ELisp package unmodified.

Some packages may require minor changes, but no more than (say) porting to XEmacs.

So far one package (hanoi.el) runs basically as is.

It may be desirable to re-write some packages, optionally in Scheme. For example, dired needs a more modern interface.

Major Emacs annoyance is that it is single-threaded:
This means Emacs freezes up when doing non-trivial tasks.

But Java supports multiple threads, so no problem, right?

Wrong - we still have to deal with:

• ELisp is single threaded. An Elisp function may at any time switch to a different buffer or window.
  Hence we cannot just associate a thread with each buffer or window.
• Swing is single-threaded. Only one thread (the event thread) can safely modify a buffer that is visible in a window.

Solution: Interactive Emacs "commands" execute in the Swing event handler thread. However, commands that may take some time should create a "worker thread." When the worker thread is finished, it lets the event thread know it is done, so it can update the buffers and display.

Java char type is 16-bit Unicode character.

Internal strings and JEmacs buffers use these Unicode chars.

External files consist of 8-bit bytes.

Mapping between byte streams and character streams uses named encodings.

The Swing framework handles bi-directional text for us.

(Note split selection due to bi-directional text; also incomplete fonts.)

Documents will be increasingly represented using XML (externally) and DOM [Document Object Model] (internally).

Document formatting will be done using the "flow objects" of XSL (XML Stylesheet Language).

Most of the programs and libraries for manipulating and formatting XML are written in Java. The Apache group has some major Java-based XML projects.

If Emacs is to support word processing features, it should build on XML standards. It is easier to use third-party Java libraries if the Emacs core is Java-based.

The future of Emacs should include XML, WP, I18n, L10n. Much of the activity in those areas uses Java. This suggests that perhaps the future Emacs should be Java-based.

• "Proof-of-concept" prototype working, including partial ELisp implementaion
• Still a lot of work before you want to use it for day-to-day editing.
• Using Java and Swing libraries takes care of many problems.
• JEmacs homepage: http://JEmacsSourceForge.net/.
  (Soon also JEmacs.net.)
• JEmacs mailing list. (See homepage.)
• JEmacs currently distributed as part of Kawa.
• Kawa home-page: http://www.gnu.org/software/kawa/.