In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> This time Emacs works well with crxvt-gb under zh_CN.GB2312, but > there's still some strange behavior can be observed under zh_CN.GBK, > if the sequence to be paste to crxvt-gb is a mixed sequence, I mean a > english character, a hanzi, a space for example, that is `a 你 ', > crxvt will be messed up. > But I don't think it's Emacs's fault this time. Because same behevior > can be observed while copying from other editor(vim) to crxvt-gb. It > seems crxvt-gb sucks. May be we shoule never use crxvt-gb under > zh_CN.GBK. It seems that ctext decoder of crxvt-gb is buggy. It expects extra "ESC ( B" (ASCII designtion) after Chinese characters encoded using an extended segment. According to the spec of CTEXT, it is not necessary to produce that extra designation sequence, but doing that is harmless. So, I've just commited such a change for mule.el. --- Kenichi Handa [EMAIL PROTECTED]
_______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
