bug-gnu-emacs
[Top][All Lists]
Advanced

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

Re: clean mess encrusted on to Chinese pastes cut from outside emacs


From: Dan Jacobson
Subject: Re: clean mess encrusted on to Chinese pastes cut from outside emacs
Date: 05 Jul 2001 02:26:34 +0800
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Eli> What is your selection-coding-system set to, and what was the
>> chinese-big5

Eli> Why not compound-text?
Hmm, just tried that and got  [cat -v output:]
^[%/2M-^IBIG5-0^BM-^IBIG5-0^BM-^AM-%| 07  5 01:51:28 CST
where this is the               ^ japanese yen symbol
^[%/2M-^IBIG5-0^BM-^IBIG5-0^BM-%|^[(B 07  5 01:51:28 CST
instead of the chinese         ^ "four" [si4] symbol
Eli> What happens if you set selection-coding-system to no-conversion and
Eli> look at the data which you paste from other applications?

same as above experiment.  also chinese cut from emacs pasted into
rxvt gets messed up too.

hmmm, supercite has peeled away the protective ">"'s from your
message, making it look like the below lines were from the last
message instead of 2 messages ago...  humm...

Eli> application which put the text into the X selection?  (Some
>> Netscape 4.76, rxvt, pydict, indeed any other application than emacs.
Eli> applications are known to produce wrong encoding of the text they put
Eli> into the X selections; Emacs cannot do much about that.)
>> The only problem I have is pasting into emacs items cut outside
>> emacs.  All other combinations and directions are ok, including
>> cutting from within emacs then pasting outside of emacs.

Eli> This is indeed a sign of bugs in other programs: they don't produce
Eli> correct encoding.

all I know is that they seem to talk fine to each other, but not to emacs.

>> By the way, I did (describe-variable (quote selection-coding-system))
>> and the help page didn't mention what file it was defined in... odd.

Eli> That's because it is defined in C.

Hmmm.... we get so used to seeing the Help system giving us a link to
a source .el, or saying "is a built-in function", so when we see none
of these we think something is broken.  Perhaps it should mention "was
defined in C/at emacs compile time" or something... I guess mentioning
just what file too would be ok... but not required... at least tell
the user that it isn't going to be fond in a .el, so don't look there...

>> >Coding system for communicating with other X clients.
>> >When sending or receiving text via cut_buffer, selection, and clipboard,
>> >the text is encoded or decoded by this coding system.
>> 
>> maybe sometimes the user would need to set different values for
>> sending and receiving... perhaps add such a flexibility.

Eli> You have it already: type "C-x RET X" (capital X) before cutting or
Eli> pasting.

I was thinking of the case where the user would want to set all
outgoing stuff different from incoming stuff, for the whole session,
not just one command.  Though I don't know if there is an actual need
to so this, I'm worried that emacs doesn't have this flexibility,
in case one day some user needed it.

>> [I don't know how to check the value of selection-coding-system for
>> Netscape or rxvt, all I know is there is no problem between them.]

Eli> Use no-conversion, and you will see the raw bytes they send.

Apparently they are trying to say "the following line is in BIG-5",
but emacs doesn't need to be told that...

I did (list-coding-systems nil)
but didn't see what is the choice for set-selection-coding-system that
will expect each line to say which encoding system it is in... i.e.,
the beginning of lines coming into emacs will contain the name of the
coding system right in the line... with this prefix [cat -v]:
^[%/2M-^IBIG5-0^BM-^IBIG5-0^B
-- 
http://www.geocities.com/jidanni Tel+886-4-25854780 e-mail:restore .com.



reply via email to

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