(insert 8000) seems fundamentally broken to me. Integers are not characters. We went through reams of Ebola warnings last year (or was it the year before) to get rid of stuff like this. I think Finsert ought to be made to signal wrong-type-argument when handed an integer.

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp&gt; writes: OK. Here is the patch. With this patch, Finsert will be OK, but you can still make XEmacs crash with (int-to-char 8000). I'll write fix for that later. When this patch is applied, w3 must be fixed since it uses (insert INT) to insert &#1000; or something like that. 1999-11-09 Yoshiki Hayashi <t90553(a)mail.ecc.u-tokyo.ac.jp&gt; * editfns.c (buffer_insert_1): Don't treat an integer as a character. -- Yoshiki Hayashi

Ben Wing <ben(a)666.com&gt; writes: I am confused. Your plan and Kyles' plan below can't coexist. It's easy to fix and here is the patch. I'll send this to xemacs-patches if this is needed after discussions are over. Index: mule-charset.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/mule-charset.c,v retrieving revision 1.12.2.20 diff -u -r1.12.2.20 mule-charset.c --- mule-charset.c 1999/10/26 05:48:52 1.12.2.20 +++ mule-charset.c 1999/11/09 08:03:45 ＠＠ -267,7 +267,8 ＠＠ if (f3 < 0x20) return 0; - if (f3 != 0x20 && f3 != 0x7F) + if (f3 != 0x20 && f3 != 0x7F && !(f2 > MIN_CHAR_FIELD2_PRIVATE && + f2 < MAX_CHAR_FIELD2_PRIVATE)) return 1; /* ＠＠ -276,6 +277,8 ＠＠ FIELD2_TO_PRIVATE_LEADING_BYTE are the same. */ charset = CHARSET_BY_LEADING_BYTE (f2 + FIELD2_TO_OFFICIAL_LEADING_BYTE); + if (EQ (charset, Qnil)) + return 0; return (XCHARSET_CHARS (charset) == 96); } else ＠＠ -300,7 +303,8 ＠＠ } #endif /* ENABLE_COMPOSITE_CHARS */ - if (f2 != 0x20 && f2 != 0x7F && f3 != 0x20 && f3 != 0x7F) + if (f2 != 0x20 && f2 != 0x7F && f3 != 0x20 && f3 != 0x7F + && !(f1 > MIN_CHAR_FIELD1_PRIVATE && f1 < MAX_CHAR_FIELD1_PRIVATE)) return 1; if (f1 <= MAX_CHAR_FIELD1_OFFICIAL) ＠＠ -310,6 +314,8 ＠＠ charset = CHARSET_BY_LEADING_BYTE (f1 + FIELD1_TO_PRIVATE_LEADING_BYTE); + if (EQ (charset, Qnil)) + return 0; return (XCHARSET_CHARS (charset) == 96); } } Kyle Jones <kyle_jones(a)wonderworks.com&gt; writes: I'm for this idea but as Ben pointed out, it will be a hard work. Any suggestions? I agree with this. -- Yoshiki Hayashi

Sorry for the duplicate; I accidentally sent the first copy before I deleted the unquoted stuff left from Ben's message, making it hard to figure out where my message ended. Ben> When I wrote all this code, I made a conscious decision, for Ben> compatibility reasons, to allow integers wherever characters Ben> are allowed. If we're going to change this, (a) we should Ben> think carefully about what this means, I don't have a problem with allowing people to use `255' as an abbreviation for `?\377', as long as they don't care if we define the default interpretation for bytes in GR to be Latin-2. A move which is long overdue IMHO. ;-) But I can't see a good reason why "characters" with "code points" bigger than 255 should be permitted to be represented by integers as long as `int-char' doesn't take a character set argument. I'm tempted to restrict that to ASCII + C1 controls, even. It doesn't necessarily make sense. Japanese, for example, should properly have its code points defined by ku-ten, a pair of integers in the range 1-94; I don't even know that it really makes sense to talk of an integer representation for Japanese characters outside of Unicode. What did you have in mind as the semantics for say `(int-char 161)'? Or '(int-char 8000)' for that matter? -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 __________________________________________________________________________ __________________________________________________________________________ What are those two straight lines for? "Free software rules."