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 |
|------------------------------------<steve(a)sxemacs.org>---|