Projects active and planned for future release

Note: This page doesn't really belong here. There should be a permanent page of on-going projects to be associated with Architecting XEmacs (or its successor page). So this URL will likely change. This confusion of roles means this page should not be interpreted as policy.

Some projects that have been proposed that I think should be postponed until a future release:

External modules: J. Kean Johnston

External modules allow C code to be dynamically loaded (on architectures that permit) to extend the Lisp environment in basically the same way that loading Lisp code does.

ISO 8859 encoding detection and interpretation: Yoshiki Hayashi

The ISO 8859 coding systems currently allow and generate ISO 2022 charset designation sequences. This is contrary to most users' expectations, and a violation of the ISO 8859 standard. (ISO 2022 designation sequences may be used in the context of an ISO 8859 stream, but strictly speaking that ends the ISO 8859 coded character data element.)

Furthermore, the latin-iso8859-1 coding system is inconsistent, in that it doesn't recognize the ISO 2022 sequences. The various ISO 8859 coding systems should be made consistent.

Unicode internal encoding: Stephen J. Turnbull

The traditional Mule leading byte representation leads to a number of problems. A Unicode internal representation would alleviate many of these, and be directly interchangeable with many external programs as well. ``UTF-2000'' refers to the implementation developed by Tomohiko Morioka, likely to be a source of much code.

Fill and justification: Stephen J. Turnbull

Fill and justification are broken right now. The ``kinsoku'' code that implements word-wrapping in the Asian style interferes with Western style algorithms. Furthermore, both use whitespace in special ways to indicate semantics for later wrapping. These should be fixed, and better guesses as to the user's intentions be used.

Unicode coding systems (external support) Stephen J. Turnbull

There is internal support for recognizing Unicode encodings. The actual encoding and decoding routines, related tables, etc, can and will be done as a package (there are two possible implementations already extant, but both suffer from certain Japanese biases as far as I can tell). Putting them in the core at this time is not a good idea, although some kind of Unicode support needs to be in the core soon.

The Great Path Searching Overhaul: Michael Sperber

1111. The Great Path Searching Overhaul.

The Great Package System Redesign: Michael Sperber

1112. The Great Package System Redesign.

The Great GC Swap: Michael Sperber

1113. The Great GC Swap.

1114. <censored>: Michael Sperber

Ask Mr. Preprocessor.

Lisp-level encoding stream interface Ben Wing

An lstream interface for use in creating arbitrary lisp coding systems (not just international encodings but gzip, base64, md5, etc.).

Conform with <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Automatically validated by PSGML