So you can get to the ideas as quickly as possible, we have a
separate page for XEmacs-specific Summer of
Code policies and plans. That page also contains references
to specifications for accepted projects and proposals under
consideration -- please check those before making a proposal. If
your idea seems to overlap another proposal, please do
consult the
developer community before abandoning it.

And without further ado, our ideas. Happy hacking!

The Idea List

Add lexical scope support as in GNU Emacs. Compatibility
with GNU Emacs syntax and semantics is essential, but internal
implementation is likely to differ substantially.

Language: XEmacs Lisp, some C.

XEmacs sound support is gradually bit-rotting. It was
written at a time when the only formats reliably supported were
"raw" audio streams. Modern sound libraries are far more capable;
the XEmacs facilities should be generalized to delegate more work
to those libraries when possible. On the other hand, XEmacs does
support extracting audio streams from compound file formats like
MIME mail messages. Appropriate validation is required for such
streams.

Update the sound support for modern ALSA on Linux
and similar systems.

Fix the non-blocking sound support.

Language: C.

Finish the Qt port of XEmacs. Adding support for embedding
XEmacs as a widget (KPart) in KDE applications is highly desirable.

Language: C, C++.

Develop a Cocoa port of XEmacs. This may be "too large",
but based on past experience with X11-based GUIs and the aborted
Carbon port, it should be possible. XEmacs "consoles" are quite
modular, with a well-defined set of routines that need to be
implemented to interface to a new GUI library. Also, much code
can probably be adapted from GNU Emacs's Mac and NeXTStep ports.

Language: C, Objective-C.

Convert the XEmacs internal text representation to Unicode.
In general, most of the work for conversion to UTF-8 is already
done, as the traditional "MULE" encoding used internally is
formally very similar to UTF-8 (eg, it is ASCII-compatible, and
the first byte encodes the length of each character in bytes).

This applies to editing buffers and strings.

Language: C.

Convert the XEmacs internal buffer representation to fixed-width,
but adapting to the range of characters actually present in the
buffer. That is, text using only the ASCII and Latin-1 character
sets would be 8 bits wide, text using only characters from the BMP
would be 16 bits wide, and text using other planes of the Unicode
code set would be 32 bits wide.

Conversions of string format is desirable as well. However,
the entire C code base will need to be analyzed for cases where
"internal" strings that happen to be all-ASCII are passed directly
to external libraries or the OS, as wide-format strings will
contain many null bytes that such libraries will incorrectly
interpret as string terminators.

The following ideas are important to XEmacs, but we haven't
thought carefully about the amount of work involved. Each one
individually may be
insufficient for Google Summer of Code projects. Especially for
the Lisp porting projects, it may be possible to combine several
related ports into a single project. Also, most areas of XEmacs
have insufficient tests, and that's even more true of GNU Emacs.

Port SMIE from GNU Emacs.

Language: XEmacs Lisp.

Port the org-mode trunk to XEmacs package format.

Language: XEmacs Lisp.

Port the VM mailreader trunk to XEmacs package format.

Language: XEmacs Lisp.

Port the AUCTeX (and preview-latex) trunk to XEmacs package
format.

Language: XEmacs Lisp, some C.

Improve support for commit logs vs. ChangeLog files. For
example, make C-x 4 a do something useful for projects that don't
use ChangeLogs. This also requires figuring out how to serialize
commit logs in a useful way, since ChangeLog files are often used
precisely because they do linearize the changes.

Language: XEmacs Lisp.

Port Emacs' jit-lock to XEmacs.

Language: XEmacs Lisp, some C.

Aside from the explicit ideas listed above, we are
open to original proposals from students, of appropriate scale
for the Summer of Code.

Of course, we always need more porting of GNU Emacs features.
However, usually this is not too difficult, so they may not make
very good proposals.

For inspiration, we recommend these
resources by past designers of XEmacs: