Call for proposals on XEmacs architectural changes

(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 more read!)) Ben sez: 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, which are: - Joel Peterson's redisplay rewrite page http://www.geocities.com/SiliconValley/Peaks/3639/new-redisplay.txt - Michael Sperber's Lisp engine changes http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-gener... 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' implementation. -- Ideas from Kirill and Kyle concerning implementing dialog boxes. (I'm also going to be providing my own proposal for this.) -- Ben Wing