User: aidan Date: 06/07/08 18:16:01 Modified: xemacs/src ChangeLog lisp.h redisplay.c syntax.h text.c Log: Fix a Mule build failure, update comments. Revision Changes Path 1.986 +11 -0 XEmacs/xemacs/src/ChangeLog Index: ChangeLog =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/ChangeLog,v retrieving revision 1.985 retrieving revision 1.986 diff -u -p -r1.985 -r1.986 --- ChangeLog 2006/07/08 09:17:59 1.985 +++ ChangeLog 2006/07/08 16:15:54 1.986 ＠＠ -1,5 +1,16 ＠＠ 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. + +2006-07-08 Aidan Kehoe <kehoea(a)parhasard.net&gt; + * symbols.c (Fsubr_name): Use the CHECK_SUBR macro instead of the GNU code's explicit if statement. 1.143 +1 -1 XEmacs/xemacs/src/lisp.h Index: lisp.h =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/lisp.h,v retrieving revision 1.142 retrieving revision 1.143 diff -u -p -r1.142 -r1.143 --- lisp.h 2006/05/06 08:09:36 1.142 +++ lisp.h 2006/07/08 16:15:56 1.143 ＠＠ -399,7 +399,7 ＠＠ typedef signed char SChbyte; /* 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 1.100 +1 -1 XEmacs/xemacs/src/redisplay.c Index: redisplay.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.99 retrieving revision 1.100 diff -u -p -r1.99 -r1.100 --- redisplay.c 2006/04/25 14:02:09 1.99 +++ redisplay.c 2006/07/08 16:15:56 1.100 ＠＠ -1428,7 +1428,7 ＠＠ add_octal_runes (pos_data *data) 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; 1.15 +1 -1 XEmacs/xemacs/src/syntax.h Index: syntax.h =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/syntax.h,v retrieving revision 1.14 retrieving revision 1.15 diff -u -p -r1.14 -r1.15 --- syntax.h 2006/02/21 11:33:46 1.14 +++ syntax.h 2006/07/08 16:15:57 1.15 ＠＠ -149,7 +149,7 ＠＠ WORD_SYNTAX_P (Lisp_Object table, Ichar 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. 1.28 +7 -9 XEmacs/xemacs/src/text.c Index: text.c =================================================================== RCS file: /pack/xemacscvs/XEmacs/xemacs/src/text.c,v retrieving revision 1.27 retrieving revision 1.28 diff -u -p -r1.27 -r1.28 --- text.c 2006/06/19 18:19:38 1.27 +++ text.c 2006/07/08 16:15:57 1.28 ＠＠ -215,13 +215,11 ＠＠ Boston, MA 02111-1307, USA. */ 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 ＠＠ non_ascii_valid_ichar_p (Ichar ch) { 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);