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

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

Re: address@hidden: gtk2, iso14755, pasting non-ascii characters, and th


From: josh buhl
Subject: Re: address@hidden: gtk2, iso14755, pasting non-ascii characters, and the x-windows clipboard]
Date: Thu, 18 Dec 2003 10:50:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4; MultiZilla v1.4.0.4A) Gecko/20031107 Debian/1.5-3

Kenichi Handa wrote:
However, the gtk2 apps and the non-gtk2 apps aside from emacs, all
seem to be able to paste this text in from each other properly. Only
emacs has this problem.


Perhaps, that because the other apps use UTF8_STRING request
on selection (which is XFree86 extention) but Emacs 21.3
uses only COMPOUND_TEXT request (standard of X).  The latest
CVS version of Emacs supports UTF8_STRING.

That sounds plausible. If I tried to checkout and compile the latest cvs of emacs to test this, would I have to somehow enable utf8_string, or would it be automatically supported?


This behaviour is independent of what I've set LC_ALL to before
starting emacs, but if I logout and login with default session
language set to german, then all the pasting functions work properly.


???  Then, in what locale were you running gtk2 apps when
pasting didn't work?

The system default, which is no default language (as recommended during the debian locales configuration script for mult-language systems), so just POSIX:

address@hidden:~$ locale
LANG=POSIX
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
address@hidden:~$ locale -a
C
de_DE
address@hidden
de_DE.iso88591
address@hidden
de_DE.utf8
address@hidden
deutsch
en_US
en_US.iso88591
en_US.utf8
german
POSIX
address@hidden:~$

But like I said, I can open a terminal, set LC_ALL=en_US.utf8, start emacs, and the pasting does not work (but only for emacs, it still works with other apps). *HOWEVER*, if I log out, select any of the available locales for the session language in the gdm login, e.g. de_DE.ISO-8859-1 or en_US.UTF-8, and then login, then all the pasting works properly.

I suppose that the session locale setting might also alter the way the X selection buffer deals with the marked text.

The garbaged text corresponds exactly to the unicode hex encodings for
the characters. for example the unicode hex encoding of ß is 00DF and
emacs displays the pasted in ß as \x{00DF}. This certainly isn't a coincidence.


Emacs never generates such \x{.....} notation automatically.
So, the text should be generated on sender site.

This corroborates the suggestion that the session locale setting is also effecting the text in the x selection buffer. But there's still the question (except for your utf8-string explanation) of why other apps can insert this, but emacs can't.

-jb





reply via email to

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