Re: non-ASCII cut/paste emacs <-> mozilla

[Kenichi Handa]

Miles Bader <address@hidden> writes:
> Eli Zaretskii <address@hidden> writes:
>>  > So mozilla is apparently just pasting the raw encoded
>>  > characters from X, without interpretation.
>>  
>>  Yes, it looks like a ctext-encoded string.  You can verify that by 
>>  setting a breakpoint in x_encode_text and looking at the string it is 
>>  about to send to X.
>>  
>>  Weird.  What system is that?

> Debian unstable.

> It seems as if it's just mozilla's problem, but I'm rather astonished
> that it can't even deal with latin-1 characters.

> Has anyone out there successfully used Mozilla to cut/paste non-ASCII text?

> Also, does anyone know of any low-level tools that cat be used to
> directly send/receive binary data to/from the X cut buffer mechanism, so
> I can reduce the variables to one program?

Run Emacs under gdb and set breakpoints at
selection_data_to_lisp_data and lisp_data_to_selection_data,
then see how bytes are decoded/encoded.

At least, with this Mozilla:
        Mozilla 1.0
        Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0)
        Gecko/20020615 Debian/1.0.0-3
I found very strange behavour.  It seems that Mozilla is
very sensitive to locale.

If you run Mozilla under LANG=ja_JP.eucjp, you can
copy&paste Japanese text with Emacs correctly.  But, in that
case, if you copy&paste latin-1 from Mozilla to Emacs,
Mozilla encode latin-1 by euc-jp while treating all latin-1
chars as JISX0212.  Thus, in that case, before pasting the
characters into Emacs, you must do C-x C-m X euc-jp RET.

And if you run Mozilla under LANG=de_DE, Mozilla correctly
handles latin-1, but doesn't handle Japanese characters at
all in copy&paste even if they are displayed correctly.

If you run Mozilla under LANG=C, Mozilla doesn't handle
latin-1 nor japanese characters in copy&paste.

---
Ken'ichi HANDA
address@hidden