Re: (insert 8000) crashes XEmacs 21.2.16

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? The bug you're seeing looks to actually be a bug in CHAR_INTP(), which is supposed to recognize valid character integers. Therefore, you should fix this macro. ben Yoshiki Hayashi wrote: -- 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."