On Fri, 19 Apr 2002, Mats Lidell said: Yes: the bytecode is the same, and the mule-packages tree won't be consulted by the non-MULE XEmacs. Well, some of us don't use MULE because we're monolinguistic savages. :) I'm happy to have support for it *there*, but if it means that my XEmacs size in core grows even larger, or that I have to use disk space on huge Unicode tables for character sets I don't have fonts for and can't even read, well, no thanks. (I'm glad to see that 21.5, while it has the Unicode translit tables, lets you remove them once installed :) and I have no objection to MULE in my XEmacs if it doesn't harm speed or size when you're not viewing anything MULEish... all I use is file-coding.) -- `Unless they've moved it since I last checked, travelling between England and America does not involve crossing the equator.' --- pir

Mats> Well I was hoping for some hard facts here like how much Mats> bigger it will get. We don't know. I can give you an upper bound: UTF-2000 XEmacs balloons from 9MB to 38MB RSS on the Alpha. But Ben's new implementation is likely to be smaller. Mats> Once in a while elisp developers seems to forget that their Mats> code should work both for mule and non-mule (if that even is Mats> feasible) and subtle bugs occur. They're supposed to be _able_ to forget. The mule/no-mule problems are usually not subtle at all: (1) people put non-unibyte code into a Lisp file, and no-mule can't read it, or (2) code signals a missing resource (Mule) under no-mule. But this is no different from the current "no-menubar XEmacs blows chunks" thread; you have to test for a feature before using it. So yes, it's a problem and annoying, but it's not "subtle"; it's usually possible to provide workarounds (move the lookup package, build with Mule) quickly. Mats> If the non-mule version is dropped I guess these problems Mats> would go away. The experience in GNU Emacs has been otherwise. They periodically have problems with *-as-unibyte issues, not to mention the recurring "\201 in Latin-1 files" bug. Mats> So I was curios about what consequences it would have to Mats> drop non mule. Merits: o One less feature to check for in "generic" code. o Lisp developers would be encouraged to be Mule conscious, and internals developers would be encouraged to provide mechanisms to Do The Right Thing without "doing Mule." o People who don't often need Mule facilities would have them available, find more uses for them, and all the good that flows from open source will be enhanced. Demerits: o The costs of Mule consciousness for Lisp developers, and the costs to internals developers of thinking up and providing APIs that DTRT without the Lisp developer doing anything special. o The subtle bugs will be more common until the first point is addressed. o Developers who have up to now been able to add features without worrying about Mule issues, and let the specialists add them later, will have a lot less room to wiggle. o Executable footprint will get larger by default. Mostly we'll lazy load (at least that's Ben's plan), but the default will be to load UTF-8 support rather than accept a couple of \202's in the buffer. o Buffer footprint will get larger for unibyte users (Latin-X characters double in size). Depending on the frequency of those characters, it could be anything from nearly 0% (British users who don't mention money) to nearly 100% (Cyrillic, Greek, Arabic, Hebrew) increase. This means a reduction in maximum buffer size, I believe (I think that byte counts as well as character counts must fit in a Lisp integer in the current implementation). And people have objected to changes on that basis in the past. o Mule operations are alleged to be slower, but it's been surprisingly hard to quantify. o By default multiscript usage will often have surprising results, for example files may get automatically translated to Unicode or ISO 2022. This kind of thing could theoretically occur simply by mixing ISO-8859 1 with 15. We'll try to be sensible about designing those features, but it's unknown territory. I know several people who complain bitterly about "surprises" that I consider natural or even "features". o Backwards compatibility with existing no-mule XEmacsen (we _still_ get occasional bug reports from satisfied 19.14 users) will suffer. That's what I know offhand, I'm sure there are others. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

On 22 Apr 2002, Stephen J. Turnbull wrote: CC to Ben because it's relevant to him. :) The current effect of the 21.5 series with Ben's current set of code is an expansion from 48MB, after a day of running, to 130MB on startup. This is with a bunch of code, Gnus included, loaded, but even so, that's an expansion of four times larger for a startup and, in practice, about the same at runtime. The new code is /big/, especially at runtime. This is a bad thing(tm). I am happy to do what I can to improve the situation, but at the moment I have run out of ideas as to what to look at. Ben, or anyone else, if you have suggestions about where to look to track down what the expansion is, please suggest them. The internals have no fear for me.[1] Daniel Footnotes: [1] Well, something like that, anyway. I can learn 'em. ;) -- Despite all my rage I am still just a rat in a cage. Now I'm naked, nothing but an animal. -- The Smashing Pumpkins, _Bullet With Butterfly Wings_ (Mellon Collie And The Infinite Sadness)

On 22 Apr 2002, Stephen J. Turnbull wrote: Oh. Sorry, I didn't pick that up from your post. Right. Well, my offer to try and help stands. :) Daniel -- The true believer is eternally incomplete, eternally insecure. -- Eric Hoffer