[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs failes to communicate with other X clients

From: Robin Hu
Subject: Re: Emacs failes to communicate with other X clients
Date: Sat, 24 May 2003 11:10:06 +0000
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (windows-nt)

>>>>> "Eli" == Eli Zaretskii <address@hidden> writes:

    >> From: Robin Hu <address@hidden> Date: Fri, 23 May 2003
    >> 09:19:10 +0000

    Eli> I'm not sure I understand correctly the situation, but IIRC,
    Eli> gbk is not supported by compound-text-with-extensions.  If you
    Eli> want to add such a support, you need to modify the alist of
    Eli> non-standard ICCCM encodings used by Emacs to match known
    Eli> coding-systems to the encoding name mentioned in the X
    Eli> selection encoding.  See mule.el for the definitions of those
    Eli> alists.

    Yeah, icccm list had been appended with GBK-0, that's why my emacs
    can decode some gbk characters correctly, but problems are still
    there. In the example I gived in the previous post, one embeded gbk
    character will make all characters fail to be decoded. ;-(

    Eli> How can Emacs leave that to X?  We need to convert the X
    Eli> selection text into the internal representation of characters
    Eli> used by Emacs; X knows nothing about that representation.  Am I
    Eli> missing something?

    But selection-coding-sytem can do this translation. For example, we
    can leave X to decode compound text to gbk locale coding, then
    set-selection-coding-system to chinese-gbk, then everything should
    go fine. Why don't we just totally leave this copy/paste working to
    be transparent to Emacs, to make this work just like a keyboard? If
    I understand the source corrently, ntEmacs works in this way. Any

reply via email to

[Prev in Thread] Current Thread [Next in Thread]