Ar an t-ochtÃº lÃ¡ de mÃ IÃºil, scrÃobh Vin Shelton:
It looks like your 2D Mule charsets patch broke the Mule build, at
least for me. (My non-Mule builds - both optimized and debug - built
Here's the error message:
Thanks! Looks like I only built with that change integrated with text
error-checking turned off, which was a particularly stupid idea. Does the
below patch work for you?
2006-07-08 Aidan Kehoe <kehoea(a)parhasard.net>
* redisplay.c (add_octal_runes):
Change some comments to reflect a 21-bit character space.
* text.c (non_ascii_valid_ichar_p):
Check that no character value is greater than 2^^21, not
2^^19. This fixes the Mule build when error-checking is turned on.
XEmacs Trunk source patch:
Diff command: cvs -q diff -u
Files affected: src/text.c src/syntax.h src/redisplay.c src/lisp.h
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/lisp.h,v
retrieving revision 1.142
diff -u -u -r1.142 lisp.h
--- src/lisp.h 2006/05/06 08:09:36 1.142
+++ src/lisp.h 2006/07/08 13:46:28
＠＠ -399,7 +399,7 ＠＠
/* To the user, a buffer is made up of characters. In the non-Mule world,
characters and Ibytes are equivalent, restricted to the range 0 - 255.
- In the Mule world, many more characters are possible (19 bits worth,
+ In the Mule world, many more characters are possible (21 bits worth,
more or less), and a character requires (typically) 1 to 4 Ibytes for
its representation in a buffer or string. Note that the representation
of a character by itself, in a variable, is very different from its
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/redisplay.c,v
retrieving revision 1.99
diff -u -u -r1.99 redisplay.c
--- src/redisplay.c 2006/04/25 14:02:09 1.99
+++ src/redisplay.c 2006/07/08 13:46:32
＠＠ -1428,7 +1428,7 ＠＠
if (data->ch >= 0x100)
/* If the character is an extended Mule character, it could have
- up to 19 bits. For the moment, we treat it as a seven-digit
+ up to 21 bits. For the moment, we treat it as a seven-digit
octal number. This is not that pretty, but whatever. */
data->ch = (7 & (orig_char >> 18)) + '0';
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/syntax.h,v
retrieving revision 1.14
diff -u -u -r1.14 syntax.h
--- src/syntax.h 2006/02/21 11:33:46 1.14
+++ src/syntax.h 2006/07/08 13:46:32
＠＠ -149,7 +149,7 ＠＠
the tag and the comment bits.
Clearly, such a scheme will not work for Mule, because the matching
- paren could be any character and as such requires 19 bits, which
+ paren could be any character and as such requires 21 bits, which
we don't got.
Remember that under Mule we use char tables instead of vectors.
RCS file: /pack/xemacscvs/XEmacs/xemacs/src/text.c,v
retrieving revision 1.27
diff -u -u -r1.27 text.c
--- src/text.c 2006/06/19 18:19:38 1.27
+++ src/text.c 2006/07/08 13:46:34
＠＠ -215,13 +215,11 ＠＠
this to 2048, and further shrinkage would become uncomfortable.
No such problems exist in XEmacs.
- Composite characters could be represented as 0x8D C1 C2 C3,
- where each C[1-3] is in the range 0xA0 - 0xFF. This allows
- for slightly under 2^20 (one million) composite characters
- over the XEmacs process lifetime, and you only need to
- increase the size of a Mule character from 19 to 21 bits.
- Or you could use 0x8D C1 C2 C3 C4, allowing for about
- 85 million (slightly over 2^26) composite characters.
+ Composite characters could be represented as 0x8D C1 C2 C3, where each
+ C[1-3] is in the range 0xA0 - 0xFF. This allows for slightly under
+ 2^20 (one million) composite characters over the XEmacs process
+ lifetime. Or you could use 0x8D C1 C2 C3 C4, allowing for about 85
+ million (slightly over 2^26) composite characters.
10. Internal API's
＠＠ -4695,8 +4693,8 ＠＠
int f1, f2, f3;
- /* Must have only lowest 19 bits set */
- if (ch & ~0x7FFFF)
+ /* Must have only lowest 21 bits set */
+ if (ch & ~0x1FFFFF)
f1 = ichar_field1 (ch);
Santa Maradona, priez pour moi!