APPROVE COMMIT NOTE: This patch has been committed. src/ChangeLog addition: 2006-07-08 Aidan Kehoe <kehoea(a)parhasard.net&gt; * lisp.h: * redisplay.c (add_octal_runes): * syntax.h: * text.c 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 Index: 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 16:13:33 ＠＠ -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 Index: src/redisplay.c =================================================================== 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 16:13:37 ＠＠ -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'; ADD_NEXT_OCTAL_RUNE_CHAR; Index: src/syntax.h =================================================================== 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 16:13:37 ＠＠ -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. Index: src/text.c =================================================================== 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 16:13:40 ＠＠ -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) return 0; f1 = ichar_field1 (ch); -- Santa Maradona, priez pour moi!