In article <[EMAIL PROTECTED]>, Zhang Wei <[EMAIL PROTECTED]> writes:
> While copy and paste between Emacs unicode branch and a ctext required > software such as crxvt-gb, emacs can't format/decode correctly the > "gbk-0" encoded compound text. > With the following patch, emacs could accept gbk-0 encoded selection, > but still can't paste to crxvt-gb. Thank you. I've just committed your change. I've also committed a fix for the latter problem. But, as I don't have crxvt-gb, I didn't check if the fix is correct or not. One thing I'm not sure is that the current code still encode most characters by designating GB2312 and some other standard charsets. Extended segment "gbk-0" is used only when they all fails. Is that ok? At least, it's what the documentation of CTEXT tells in my understanding. > btw, because emacs-unicode-2 has a different internal character > representation, functions such as `following-char' and 'char-after', > return a quite different value from emacs22. We have to replace every > occurrence of these function with: > (multibyte-char-to-unibyte (char-after ... )) > (multibyte-char-to-unibyte (following-char ... )) > May be change the definitions of these functions is a better solution. I think we shouldn't change those functions at least to compensate for that problem because we still have to distinguish U+00C0 from raw-8-bit char 0xC0 in a multibyte buffer. Perhaps, we should add a new function `byte-after' (which signals an error when a multibyte character is found). By the way, your changes are accumulating, and soon reach the limit of 15 lines. For further changes, FSF requires assignement paper from you. Have you alreay signed the paper? If not, please ask Richard to send you a proper form. --- Kenichi Handa [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
