• 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

Intro to Architecting XEmacs

I would like to see myself in the position of an architect of XEmacs. I think there are some good reasons for this:

1. I've had a lot of experience working with or on a lot of different aspects of XEmacs for a long time.

2. In my opinion, there's currently not nearly enough effort spent thinking about higher level issues, such as the direction that XEmacs is heading in and its overall priorities in the near and long-term. This is not a new situation, and there is a very good reason for this, which is that the developers of XEmacs invariably get completely sucked into the coding and maintenance issues, and can barely keep their heads above water doing this, given that it is such a large task. My enforced absence from coding gives me a broader and more detached perspective on the whole development process. Perhaps you could call this "making the most of a bad situation".

With that said, the single most important issue in XEmacs development is ensuring the future survival of the development effort. Development nearly died after Chuck and I left, and I consider it somewhat of a miracle that Steve came along and did such a good job of resurrecting the development process and getting so many other people involved. I don't expect this situation to exist forever, though, and I'm sure that many of the current developers of XEmacs will move on in time. In order to keep the development process going, we need a steady influx of developers and beta testers, and the best way for this to happen is to keep our user base up. This means that we can't just continue to design features with existing users in mind, but we need to continue to add features in order to recruit new ones. I know that this sounds a lot like bletcherous processes such as proselytizing, but unfortunately I think this is just the cold, hard reality of software development.

I think we need to continue to expand upon the strengths of XEmacs. The way I see it, those strengths are:

1. In comparison to GNU Emacs, a better user interface and a more open development process.

2. In comparison to most modern GUI editors, much better customizability, and a good set of powerful and interesting extensions.

3. In comparison to many other free software products, comprehensive support and easy building and installation on many different platforms.

Here's what I think are the most important features for version 21.2 that should be added:

1. Removal of the unexec mechanism. Everyone agrees with this, I think. Kyle and Olivier are working on portable and general replacements. I have an outline of a process that I used in Win-Emacs that is also portable and should be a lot easier to implement and perhaps faster than the mechanisms proposed by Kyle and Olivier, but it is a stopgap mechanism in that it is not relocatable (which can cause problems with dynamic libraries), and because it makes certain minimal assumptions about memory layout which could pose problems on certain rather unusual architectures (although it's not clear that this would be a problem in practice).

2. A GUI installation process under Windows using InstallShield or similar products such as Wise. Doing this is not very difficult and also does not require very much knowledge of the internals. I think somebody has already volunteered to do this, and so I imagine it should have no trouble getting done without too much design work necessary.

For version 22.0:

1. Dialog boxes. I think proper dialog boxes are extremely important, probably more so than almost any other new feature that people are considering implementing. More and more users are expecting applications to conform to user interface guidelines involving dialog boxes and tab components and such. The longer we delay in doing this, the more XEmacs will start to look like a dinosaur application that will simply get discarded and replaced by more modern-looking applications, even if they are significantly less powerful. I also think it's possible to integrate dialog boxes cleanly with minibuffer input in such a way that people can choose to have dialog boxes always, never, or only when invoked by the mouse, as currently.

2. I also think that custom absolutely needs to have its user interface changed to function more like standard options or customization screens in modern applications. This, of course, requires proper dialog box and component support, and particularly requires such things as tab components, but once all these are implemented, it should not be impossible (or even that difficult) to make this change.

3. Internationalization. Yes, I know this is a pet project of mine and Steve's, and it is clearly not as immediately pressing as any of the first three items listed, and it's also big and open-ended, but getting it working under Windows, at least basically, can potentially gain us a huge new user base. I'll have more to say on this presently.