Re: Emacs failes to communicate with other X clients

[Robin Hu]

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

    >> From: Robin Hu <address@hidden> Date: Sat, 24 May 2003
    >> 11:10:06 +0000
    >> 
    Eli> Sounds like a bug.  Unfortunately, I don't know enough about
    Eli> gbk to guess what might be wrong, and don't have time to debug
    Eli> compound-text-with-extensions myself.

    I'll try to clearify myself, and attachment is a dirty patch to
    xselect.c, I also hope this can be any help out of my buggy english
    ;-(

    My point is that compound-text decoding should be left to X itself,
    rather then by emacs itself. It should be better be transparent to
    emacs, for better portable and better extensible.

    My patch implements this idea, it use XmbTextPropertyToTextList to
    decode compound-text, then delegate the result to
    selection_data_to_lisp_data, who will call decode_region with
    chinese-gbk to translate gbk coding characters to emacs-mule. It
    works fine for me these days.

    But there is still some problems I am not so sure. First is that I
    dont know whether this change of behavior will impact any other
    packages exists. Second is that I still wonder if there are any
    better places for this change.

    Eli> Keyboard input is nowhere as transparent as you seem to think.
    Eli> Emacs decodes keyboard input similarly to what it does with X
    Eli> selections.

    I mean decoding X selections should be seperated into 2 stages, then
    compound text is transparent to emacs.

xselect.c.patch
Description: patch to Xselect.c