"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
The appended patch swaps the Lisp integer with the Lisp character
representations, so that characters have 31 bits of precision. This
allows Lisp characters to represent the entire UCS-4 code space. I
don't see that loss of one bit of precision in integers hurts; where
it matters (time values, etc) we need 32 bits anyway, and classical
Emacsen didn't have even 30 bits.
As Kyle noticed, buffer sizes will suffer. Currently an Emacs buffer
can accept up to 1G of characters. With the swap, it will be "only"
512M. Believe it or not, there _will_ be people hurt by the
difference.
That the classical Emacsen didn't even have 30 bits is not a good
argument. I've written a NEWS entry that says:
** It is now possible to build XEmacs with support for 31-bit Lisp
integers (normally, Lisp integers are only 28 bits wide on 32-bit
machines.) Configure with --use-minimal-tagbits to test. With this
change, the maximum buffer size on 32-bit machines is increased from
128M to 1G. This setting will be made default in a future XEmacs
version.
I wouldn't like to lose this.
Finally, I do need integers as large as I can get, even when it's not
the full 32 bits. We'll have to find another way for dealing with
UCS-4.