• Download
• XEmacs in GSoC
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• XEmacs in GSoC
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

XEmacs Ideas Page

for Google Summer of Code 2013

Please refer to the XEmacs developers' page for more information about our development process and resources for developers.

For advice about implementation of your project, whether one of our suggestions or an original proposal, post to the XEmacs Contributors list <xemacs-beta@xemacs.org>.

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

1. 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.

2. 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.

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

   2. Fix the non-blocking sound support.

   Language: C.

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

   Language: C, C++.

4. 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.

5. 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.

6. 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.

   You may refer to PEP 393 -- Flexible String Representation, Python's specification for a similar feature.

   Language: C.

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.

1. Port SMIE from GNU Emacs.

   Language: XEmacs Lisp.

2. Port the org-mode trunk to XEmacs package format.

   Language: XEmacs Lisp.

3. Port the VM mailreader trunk to XEmacs package format.

   Language: XEmacs Lisp.

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

   Language: XEmacs Lisp, some C.

5. 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.

6. 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:

1. Architecting XEmacs by Ben Wing.

2. XEmacs Wishlist by Jamie Zawinski.

(Note that these pages describe features that may require too little or too much code to be appropriate for Google Summer of Code.)