To Emacsians Everywhere! A few of you know what I am about to say, a few of you could probably make a pretty good educated guess, the rest of you... well, you're in for a treat. For quite a while now I've felt that only having 2 one true editors wasn't enough. So I have created a third. It is called "SXEmacs" and it is a fork of XEmacs 21.4.16. ,----[ Our Mission Statement: ] | To provide the Open Source community with a text editing and | development environment that is based on XEmacs and is 2nd to none | in regards to stability, features, and innovation. | | To foster a user and developer friendly project environment. | | And, above all, to have fun doing it. `---- Before I go any further, please, if you wish to follow up to this message, observe the MFT header. Discussion of SXEmacs on the XEmacs and GNU/Emacs forums I've posted to here would not be appropriate. This is a one off post just to let people know what is going on. So why would I do such an incredibly foolish thing that probably has more chance of failing than succeeding? Well, isn't that reason enough? And for those of you who can't comprehend that, here are some more boring, mundane reasons: o I believe that XEmacs, even 21.4, is too broken and unstable. o I want to make some fairly radical changes that I know the Review Board would never go for. o I want a development environment that doesn't get boiled down in "politics". o I want more control of the project as a whole and at the same time make it easier for developers to contribute and become involved. Some of the items we have on our "todo" list (quotes there, because I just realised we don't actually have a physical list yet :-P): o Use GNU/arch (tla) for revision control instead of CVS. This is already done. My repo is at steve(a)sxemacs.org--2004 http://arch.sxemacs.org/2004/ o Have a written procedures and policies manual. (partially completed) o Use a PostgreSQL'd Bugzilla for issue tracking. (we have it in place but unfortunately the guy I have handling it for us broke something and currently we can't connect to it) o Move away from GNU coding standards in the C code and write code in a manner that the gods intended. I'm following fairly closely the Linux kernel in this regard. I have already run indent(1) over all the C code. o autoconf 2.5x compatible. (not begun) o Remove every scrape of Windoze code. (not begun) SXEmacs will _NOT_ run on Windoze. o Back port Mike Sperber's KKCC garbage collector from XEmacs 21.5. And at a later stage look at using the Boehm GC. o Back port Jerry James' DSO, bignum, bigfloat, and ratio work from XEmacs 21.5. o Multi-threading o Do away with the idea of a buffer being nothing more than a string. o FFI -- Foreign Function Interface (pretty much like DSO's but far more flexible) o Possibly move to a client/server model o A package system where the package tells SXEmacs where and how to get updates. It is our intention to maintain compatibility on the lisp level with XEmacs for as long as we can. Providing that compatibility doesn't hinder SXEmacs' growth and potential. For now in SXEmacs: (and running-xemacs running-sxemacs (featurep '(and sxemacs xemacs))) => t Our aim is _NOT_ to hinder the development or progress of either the XEmacs project or the GNU/Emacs project. In fact, it is exactly the opposite. Our innovations will benefit the other projects even if those innovations prove to be bad or unsuccessful. We don't wish to eventually become absorbed into the XEmacs (or GNU/Emacs) code base, and we have no desire for the opposite to happen. I'm a leader, not a follower, the SXEmacs Project is the same. I sincerely hope you can keep up with (even surpass) us. Everyone at the SXEmacs Project and myself would like to wish you and your families a very happy and safe New Year's. -- |---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---| | In space, | | No one can hear you rip a stinky | |------------------------------------&lt;steve(a)sxemacs.org&gt;---|