Before I start scaring you off:
Would it be difficult to have a separate "unsigned integer
type?". That could still go up to 2^30-1.
Hrvoje Niksic <hniksic(a)srce.hr> writes:
That would be the worst possible option. Mule should bring new
functionality, not cripple XEmacs.
No released XEmacs has that functionality remember? Note that
currently you cripple anyway your XEmacs when you switch it on, you
get an enormous memory overhead on all lisp types.
I wouldn't loose any sleep over 1-bit of integer precision (unless we
were going from 32 to 31).
We have two competing primitive types. One of them is more or less
naturally limited to 31-bits and for the other the cut-off is
arbitrary. We have only one with 31-bits available, you choose?
I can already hear people saying,
"Oh, you need larger buffers? Why, compile without Mule -- everyone
sensible does that."
No, the answer would be "use a 64-bit system everyone sensible does
that". I think the number of cases where you want to edit a 0.75 G
file in XEmacs is extremely low, certainly much lower than the # of
people profiting from full UCS-4 transparency (probably also not a big
group).
> You do not really want to do O(n^2) operations on 1 Gbyte
buffers
> anyway.
You don't. Why do you ask?
Because I think editing a 1 Gbyte buffer in a Mule XEmacs will be so
slow that it doesn't matter much anyway.
Jan