To all XEmacs contributors, I've been discussing future improvements to python-mode with Barry Warsaw and Glyph Lefkowitz over the last few days. They decided that since Guido van Rossum also uses Emacs, we should pull him into the discussion. His reaction was very positive; he said he's sick of hearing complaints about Emacs support for Python development, and would very much like to see the Python community settle on one Emacs and one python-mode for the future. As usual, he came up with some radical ideas, but I think there's a touch of genius to them. Also, he has promised on the order of a half-dozen GSoC students to implement them. Therefore, effective immediately, the position of "Mr. XEmacs" is being furloughed, to be replaced by a "Benevolent Dictator for Two Years" (GvR himself), with the assistance of a "Friendly Language Uncle for Life" (Barry). All agreed that Dunnet, not to mention the eistring code, is sufficiently twisty that we don't need help from Glyph. GvR took a look at the allocator, and he strongly recommends replacing the current GCPRO scheme, which is tedious and error prone, with a reference counting collector. At the same time, it should be fairly easy to introduce threading on the Python model, by implementing a *nonlocal* interpreter lock, ie, NIL, which should avoid the problems of Python's GIL, the *global* interpreter lock. GvR is a little disappointed that our current implementation of NIL is a mere stub that always produces a false value, though. "After 60 years, *somebody* should have a proof-of-concept implementation!" he said. Once this is done, we can turn to the next important task, which is to replace our current non-standard Lisp language with something more readable (if even less standard), namely, a parenthesis-less interpreted stack-oriented parser, or P-Lisp. This approach was chosen because he expects it to be easy for us to pronounce, based on the historical usage, E-Lisp. Of course this will require introduction of syntactic whitespace, but this shouldn't be too hard, since we already have several whitespace modes. Of course, there remains one important problem, which is the existing base of Lisp code. The various modes cannot be ignored, so some kind of emulation of Lisp will be needed. However, attempting to emulate Lisp on top of P-Lisp running on the current byte-code engine is clearly inefficient. Again, a radical suggestion: replace it with Dalvik, which is a modern and very efficient VM. Hopefully, efficient enough to support "E-Lisp in P-Lisp" to run .els. Since XEmacs is already an OS, this will make it possible to use XEmacs as a drop-in replacement for Android. Although we don't expect rapid penetration into the non-developer market, it seems certain that "XEmacs phones" and tablet PCs will occupy a strategic niche among software developers, especially the burgeoning Python community. Experienced developers will realize that all code we have inherited from the FSF will be gone at this point, leaving only code by Zawinski and Wing. Guido suggests that we can probably get more contributions with an appropriate Pythonic license; no need to hassle with the GPL any more! And with a near 100% replacement of the code base, it's possible. I've channeled Steve Baur, with the result that "if we can't have GPLv2, it's better to have no GPL at all!" So that's settled, I think. I think you can see that we all have our work cut out for us. But I hope that you will appreciate this plan, as I do. Once implemented, Emacsen will never be the same! Comments and patches welcome! Steve aka "Mr. XEmacs" (on vacation) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta