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

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.