# HG changeset patch
# User aidan
# Date 1152375357 0
# Node ID b03fc4eae965990f1b098015d95c5cc2244d20fd
# Parent  45671f160bd52aa492fa0ae1ec925c2bbb42039a
[xemacs-hg @ 2006-07-08 16:15:54 by aidan]
Fix a Mule build failure, update comments.

diff -r 45671f160bd5 -r b03fc4eae965 src/ChangeLog
--- 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):
diff -r 45671f160bd5 -r b03fc4eae965 src/lisp.h
--- 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
diff -r 45671f160bd5 -r b03fc4eae965 src/redisplay.c
--- 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;
diff -r 45671f160bd5 -r b03fc4eae965 src/syntax.h
--- 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.
diff -r 45671f160bd5 -r b03fc4eae965 src/text.c
--- 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);