Mercurial > hg > xemacs-beta
changeset 3498:b03fc4eae965
[xemacs-hg @ 2006-07-08 16:15:54 by aidan]
Fix a Mule build failure, update comments.
| author | aidan |
|---|---|
| date | Sat, 08 Jul 2006 16:15:57 +0000 |
| parents | 45671f160bd5 |
| children | b1d8bf0387f4 |
| files | src/ChangeLog src/lisp.h src/redisplay.c src/syntax.h src/text.c |
| diffstat | 5 files changed, 21 insertions(+), 12 deletions(-) [+] |
line wrap: on
line diff
--- a/src/ChangeLog Sat Jul 08 09:18:01 2006 +0000 +++ b/src/ChangeLog Sat Jul 08 16:15:57 2006 +0000 @@ -1,3 +1,14 @@ +2006-07-08 Aidan Kehoe <kehoea@parhasard.net> + + * 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@parhasard.net> * symbols.c (Fsubr_name):
--- a/src/lisp.h Sat Jul 08 09:18:01 2006 +0000 +++ b/src/lisp.h Sat Jul 08 16:15:57 2006 +0000 @@ -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
--- a/src/redisplay.c Sat Jul 08 09:18:01 2006 +0000 +++ b/src/redisplay.c Sat Jul 08 16:15:57 2006 +0000 @@ -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;
--- a/src/syntax.h Sat Jul 08 09:18:01 2006 +0000 +++ b/src/syntax.h Sat Jul 08 16:15:57 2006 +0000 @@ -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.
--- a/src/text.c Sat Jul 08 09:18:01 2006 +0000 +++ b/src/text.c Sat Jul 08 16:15:57 2006 +0000 @@ -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);