I've overlooked your reply mail in the flow of bouncing mails... Anyway, at first, I was careless when I wrote this:
>> 1, (set-selection-coding-system 'chinese-gbk) > >Of course you need it. In the other environment, I think >UTF-8 extended segment (which is more widely accepted) >should be used for non-standard charsets. I incorrectly read above as 1, (set-language-environment 'chinese-gbk) , thus I wrote the above nonsense reply. Sorry for the confusion. In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes: > If I don't set selection coding system to chinese-gbk, things turned > around, I can paste to emacs, but the coming out "compound text" is > not encoded properly, so crxvt-gb can't read them. I'm very confused. You at first sent us the patch for decoding "gbk-0" encoded compound text. So, I thought crxvt-gb also accepts such an encoding, and thus committed the recent change for making ctext-pre-write-convsion produce correct "gbk-0" extended segment (but only for characters that gb2312 designation can't be used). As you wrote "a ctext required software such as crxvt-gb", I thought crxvt-gb at least accept gb2312 designation sequence. But, it seems that your crxvt-gb doesn't accept such an encoding. Please tell me what kind of encoding does it accept, for instance, for chinese word "nihao" (hello) in exact byte sequence. By the way, I've just installed debian package "xcingb" (which include crxvt-gb-2.3). But, when I run it with LANG=zh_CN.bgk, it doesn't send/accept ctext to/from Emacs. It only sends/accepts GBK encoded text (or perhaps it's just GB2312 encoded text). When I run it with --version, it says: rxvt Version 2.10 [...] Is it different from what you are using? --- Kenichi Handa [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
