There seems to be a conversion glitch when doing copy/paste of the unicode character '∘' *from* xterm, where it converts this character to '°'. This can be observed when doing such a copy/paste from xterm to xterm, or xterm to emacs. Copy/paste of such a character from emacs to emacs works, as does from emacs to xterm.
Please post your `emerge --info' and `emerge -pvq x11-terms/xterm' in a comment.
System uname: Linux-2.6.35-tuxonice-r1-x86_64-Intel-R-_Core-TM-2_CPU_T7200_@_2.00GHz-with-gentoo-2.0.1 Timestamp of tree: Thu, 14 Oct 2010 15:00:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [enabled] app-shells/bash: 4.1_p7 dev-java/java-config: 1.3.7-r1, 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.67 sys-devel/automake: 1.5, 1.7.9-r1::<unknown repository>, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distcc distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de en_GB cs ja" MAKEOPTS="-j13" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="64bit 7zip X Xaw3d a52 aac aalib accessibility ace acpi akonadi alsa amd64 apache2 audio audiofile bash-completion bdf bitmap-fonts bluetooth bzip2 cairo cdparanoia cdr cdrom cg cgi chardet cjk colordiff consolekit css cups curl cxx cyrillic dbus dga divx dri dvd dvdnav dvdr dvi emacs encode enscript epydoc examples exif fat fbcon fbsplash ffmpeg flash fontconfig ftp gd gif gimp gimpprint glib gnutls hal handbook hdaps hddtemp ibmacpi idn ieee1394 imagemagick ipv6 ipw3945 ithreads java javascript joystick jpeg jpeg2k json kde kpathsea lame laptop lcms lm_sensors log4j logrotate lua mime mmx mozdevelop mozdom mp2 mp3 mp4 mp4live mpeg mpeg2 mplayer multilib mysql mysqli nls nptl nsplugin ogg opengl openssh pam pango pcf pdf perl php png ppds pulseaudio python qt3support qt4 quicktime radeon raptor rar realmedia redland rtc screen semantic-desktop smp sound sql sqlite sse sse2 ssl ssse3 subversion svg svgz syslog tgif threads tidy tiff truetype truetype-fonts type1 type1-fonts unicode unzip usb vcd vhosts video virtuoso vnc vncviewer vorbis webdav webkit wifi wma wmf x11vnc xcb xml xorg xsl xslt xterm xulrunner xv xvidxcb zip" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="worker" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="mouse keyboard synaptics" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en_GB cs ja" PHP_TARGETS="php-5.2" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" RUBY_TARGETS="ruby18 ree18" USERLAND="GNU" VIDEO_CARDS="radeon" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS and [ebuild R ] x11-terms/xterm-262 USE="Xaw3d truetype unicode -toolbar"
Select/paste using xterm can use either the primary selection (default), the clipboard or the cut-buffers. The cut-buffers don't support UTF-8. For cases where xterm's translating from UTF-8 to ISO-8859-1, it will use approximations as reported here. The menu entries for "Keep Selection" and "Select to Clipboard" affect the way xterm decides which of those mechanisms is used.
However, I fail to see where cut-buffers are used when selecting ∘ in xterm and pasting it into an emacs file which is marked for emacs as UTF-8. Also, (all - as far as I know) other utf-8 characters I have tried so far behave correctly (are copied 1:1) in the same process.
To point out the specific path, I'd have to know more about the combinations you're using (what's the source program, its locale setting, what's the destination). A quick check here (using en_US.UTF-8 for uxterm's locale) shows the paste working properly. Your report says LC_ALL and LANG are unset, for instance, and it's unclear where emacs is running.
(In reply to comment #5) > To point out the specific path, I'd have to know more about the combinations > you're using (what's the source program, its locale setting, what's the > destination). I thought I have written this in the description. xterm -> emacs (fail) xterm -> xterm (fail) emacs -> emacs (ok) emacs -> xterm (ok) which led me to the conclusion, that the problem occurs when xterm is the source. /usr/bin/xterm that is. Checked with /usr/bin/uxterm et voila: There it works. So yes, uxterm works here too, xterm doesn't. Therefore I mentioned xterm in the bugreport. A quick check here (using en_US.UTF-8 for uxterm's > locale) shows the paste working properly. Your report says LC_ALL and > LANG are unset, for instance, and it's unclear where emacs is running. Emacs is running on my computer. :-)
(In reply to comment #6) > So yes, uxterm works here too, xterm doesn't. Therefore I mentioned xterm in > the bugreport. Hmm. I actually do not exactly know what the difference between uxterm and xterm is. And I should also mention that I'm invoking the xterm as xterm -en utf8 -sb -rightbar -geometry 151x44 -j -s Thought the -en utf8 is equivalent to "uxterm"?
I meant whether emacs is running in an xterm or as a gui (as well as what locale it is using). The "-en" option is relevant, but not the whole story. That doesn't modify any of the locale environment variables. If LC_ALL, etc., are unset, then xterm will see characters as POSIX. Normally the "-lc" option is used, which also tells xterm to pay attention to the locale (in addition to only setting the encoding). The locale tells xterm how to interpret non-POSIX codes, e.g., anything like ISO-8859-1 or UTF-8. The uxterm script ensures that the locale environment variables are set, and also (using the -class option) that the resources are setup with fonts useful for Unicode.
Problem exists - as of today - still in xterm version 324 The problem does not exist in uxterm, so probably this ticket should be closed with the general recommendation to use uxterm instead of xterm if the observed effect is a problem.
is this still valid with 331 version? If that is the case, I would report this to upstream
Can't test the 331 xterm, but the problem seems to be resolved in xterm 333 (on Arch Linux)
great, thanks for feedback
