Re: elisp-packages, mule and non-mule?

Slow and painful death for the person responsible. Seriously, unless you're American or Japanese, Mule has a huge potential to screw you in ways you never knew existed. Not enough people are working on Mule to fix these very serious problems in any reasonable time frame, so one way out is to compile without Mule. If you take *that* away, you've pissed off and ultimately alienated a large number of users. XEmacs is hard to begin using without having to worry about "coding systems", "fontsets", "input methods", "ISO 2022" and similar. Even explaining to someone why the hell my modeline begins with "ESC/Quot" is something I'd rather avoid. Another reason is that XEmacs/Mule is *significantly* slower than XEmacs/no-Mule. The "30%" figure has been bandied around, but that figure is *old*. The actual number might be much larger (or smaller, but I doubt it) than that. I know that hardware is getting faster, but XEmacs is still anything but fast on many real-world configurations. This especially hits people who still use shared multiuser systems, such as in universities and even in commercial companies where software is developed on the Unix server on-site. (Where I worked, it was not uncommon for more than five instances of XEmacs to run on one machine.) Removing Mule is currently a very good and simple way to "optimize" XEmacs for people who don't need Mule functionality -- which is I believe is a large majority of our users.