Package gnu.jemacs.buffer

Provides various building blocks for building an Emacs-like text editor.

See:
Description

Class Summary

Buffer
BufferContent	A Content class that supports Emacs-style Markers.
BufferKeymap	This manages the keymaps active for a given buffer.
BufferReader
BufferWriter	A Writer that writes at a Buffer's point or a Marker.
Command	An Action that causes a command (such as a Procedure) to be excuted.
FinalAction	A wrapper around an action.
Frame
InsertAction	An Action to insert the typed character into a buffer.
Marker
MarkerReader
Menu	This manages a menu (for menubars or popup menus).
Modeline
PrefixAction	This Action is performed when a prefix key is typed.
ReplBuffer	A Buffer for "read-eval-print"-style command processors.
TooLongAction	A pseudo-action to wrap an integer.
Window

Exception Summary

CancelledException	Used to signal that an action was cancelled.
Signal

Package gnu.jemacs.buffer Description

Provides various building blocks for building an Emacs-like text editor. It also provides a number of Scheme procedures that have the same name and similar functionality as the Emacs Lisp functions.

It uses the Swing tool-kit.

Plan

The plan is to use this together with the (unfinished) gnu.jemacs.lang package to provide a fully-functional re-implementation of Emacs Lisp which compiles to Java bytecodes. I'm hoping volunteers will help me make "JEmacs" into something useful. I have fairly clear ideas about much of what need to be done. Contact me if you are interested.

Home page

There is now a JEmacs home page. Also check out the Kawa home page.

Screen snapshot

There is a now a teaser screen snapshot.

Status

Very unfinished proof of concerpt. It is a functional but very minimal editor. Many of the core Emacs concepts (keymaps, windows, frames, buffers, markers) are implemented, and generally in such a way as to provide the standard Emacs semantics. There are Scheme functions with the same name and similar behavior as the standard Emacs Lisp functions. However, there is only a very limited set of core "editing" commands, and no searching commands. And it is not robust or reliable.

To-do

A couple of things volunteers might start with (but let me know before you spend serious time on any of these):

• Implement more of the editing commands: Insert/delete/forward/backward word/line.
• Display the modeline in inverse video, but extend it to the full window width.
• Come up with a design for narrowing a buffer. One possibility is to use some kind of invisible style for the text outside the narrowing. But I think a more flexible design would use an "IndirectDocument" class that refers to a sub-range of a buffer. This would help with "Indirect Buffers", and might be flexible and elegant in general.
• Perhaps Buffer should inherit from Document (or rather DefaultStyledDocument). However, that might lose some flexibility.
• Needs methods to control Window scrolling.
• Think about how to map extents and faces to Swing attributes and styles.
• Decide how to implement Emacs strings. Initially, we'll use kawa.lang.FString, but we do want to support strings with extents and text properties.

Usage

These classes depend on Swing, so make sure you have Swing available. Then make sure you have a version of the Kawa classes that contains the gnu.jemacs.buffer classes. (In other words, Kawa needs to have been configure --with-swing support.) Then just start Kawa in the usual way:

java kawa.repl

Then evaluate:

(emacs)

That brings up a Emacs window.

You can do (split-window) to create new (sub-)windows in an existing frame; type (make-frame) to create a new frame (to-level window), or do (get-buffer-create NAME) to create a new buffer. Note also how ctrl/B and ctrl/F have been bound to the correct functions. For other working key-bindings, look for the calls to define-key in emacs.scm.

The call (scheme-swing-window) creates a new Scheme interaction window.

License

Same as the package gnu.expr: Modified Gnu Public License. See the file COPYING. For now, the copyright holder is Per Bothner; in the future it may make more sense to make the FSF the copyright owner, since the plan is to use a lot of the existing ELisp packages once ELisp support is complete.

Author

Per Bothner, <bothner@gnu.org>