Hrvoje> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: Hrvoje> As Kyle noticed, buffer sizes will suffer. Currently an Hrvoje> Emacs buffer can accept up to 1G of characters. With the Hrvoje> swap, it will be "only" 512M. Believe it or not, there Hrvoje> _will_ be people hurt by the difference. Yup. But they'll be hurting soon anyway; any process that can generate a >512M buffer surely can generate a >1G buffer. The only way I know of to generate an absurdly large file that won't generate one twice as big just as easily is to save something in MS Word .doc format; and the overhead there isn't 512M (yet). Hrvoje> That the classical Emacsen didn't even have 30 bits is not Hrvoje> a good argument. I've written a NEWS entry that says: [...] Sure it is; it means that right now few people are using the capability, and they're probably technically able to come up with an alternative way to handle those humongous files. I want that bit for UCS-4 chars _before_ .doc's overhead hits 512MB, when the outcry from making this change would be too huge. Hrvoje> I wouldn't like to lose this. No shit. Me neither. But higher principles call: Hrvoje> Finally, I do need integers as large as I can get, even Hrvoje> when it's not the full 32 bits. We'll have to find Hrvoje> another way for dealing with UCS-4. How about not 32 bit, but 64 or 128 or whatever you want? Hey, Steve! We have a volunteer to implement bignums! Seriously, UCS-4 needs _exactly_ 31 bits, that's exactly what we have. Why make huge amounts of complexity in a fundamental data type when it's completely unnecessary? People who want 31- vs 30- bit integers probably would be a lot happier with bignums; both are artificial caps. We need bignums anyway, eg for time values. (I don't need them enough to implement them, though.) Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch&gt; writes: Hrvoje> That would be the worst possible option. Mule should Agreed. Hrvoje> bring new functionality, not cripple XEmacs. I can Right. That's why we should make the switch to 31-bit characters immediately and unconditionally :-), and beg, borrow, steal, or implement a bignum package ASAP. Hrvoje> already hear people saying, "Oh, you need larger buffers? Hrvoje> Why, compile without Mule -- everyone sensible does that." -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."