(Note from Martin: since Ben currently has I/O problems, I am
re-posting his message with the aim of making it more readable (and
I'm in the process of making a web site about the architectural
changes to XEmacs that I think should be made both in the near future
and further off. I hope to have a preliminary version of this site up
within two weeks or so. The intent is to provide a vision of what
should be done to XEmacs, how it should be done, and in what order,
rather than the current haphazard process which I might characterize
as, ``Implement now, think later.'' The contents of the site, of
course, will be my own opinion, and many others may not agree with it
and may go ahead and implement what they feel like doing regardless of
what my suggestions may be. At the very least, however, I hope to
provide some guidance and a starting point for discussion.
I'm quite interested in proposals from other people about
architectural changes, and this is the purpose of this e-mail message.
Part of my site will include proposals from other people as well as
including the text of the proposals themselves (if the author
consents). I will include a link to the canonical home page for the
proposal as maintained by the author, if such a page exists. I
currently know of two pages containing XEmacs proposals,
- Joel Peterson's redisplay rewrite page
- Michael Sperber's Lisp engine changes
The sort of proposals that I'm looking for should not merely be
opinions about what should be done, but rather, detailed proposals
concerning specific architectural changes. Possible issues that could
be addressed in these proposals are, for example,
-- A specification of a change to be made, how the existing code
will be changed and what the mechanism behind the new
implementation will be.
-- An examination of the strengths and weaknesses of different
possible implementations designed to solve a specific problem.
-- An analysis of what exactly is causing a specific problem to happen
(for example, an analysis of profiling data for many common start-
up scenarios to determine why XEmacs start-up is so slow).
Along with any proposal that advocates a specific architectural
change, it would really nice if the following issues were addressed:
1) Why is this change important or necessary?
2) How important or necessary is this change in relation to other
architectural changes being considered?
3) What benefit--direct or indirect--will the users of XEmacs see?
4) How much work will it take to make this change?
5) How long do you think it will be before this change is finished and
integrated into XEmacs?
6) What other impacts or dependencies will this project have? For
example, any change to the Lisp engine that implements any
major language changes will have an impact in that a lot of
existing Lisp code will have to be rewritten, especially start-up
code and other code that is part of the XEmacs base. Additional
dependencies for this change would include conversion programs
between XEmacs Lisp and whatever the new language is, and
emulators probably in both directions, byte code compilers,
byte code disassemblers, debuggers, etc.
I am happy to provide the canonical home page for peoples' proposals,
or to mirror proposals whose home pages are elsewhere, in order to
make it easier for somebody who is reading my site. Alternatively, I
can just provide links to those pages, and I'll probably do so in the
beginning, until I set things up a little better.
There are some particular proposals that I would like to see written.
These include, for example,
-- Steven Turnbull's fixed width buffer changes.
-- Olivier Galibert's portable unexec replacement.
-- Kyle Jones's portable unexec replacement.
-- Some theory behind Kyle Jones's minimal tagbits, aka `gung-ho'
-- Ideas from Kirill and Kyle concerning implementing dialog boxes.
(I'm also going to be providing my own proposal for this.)