[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: Mon, 26 May 2003 02:56:54 +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: 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.

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

reply via email to

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