--- Begin Message ---
Package: xterm
Version: 242-1
Severity: normal
Hi,
Pasting iso-8859-7 text to an xterm window results in hash (#)
characters.
This seems to be the same as the issue reported in #420974
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Locale: LANG=POSIX, LC_CTYPE=el_GR (charmap=ISO-8859-7)
Shell: /bin/sh linked to /bin/bash
Versions of packages xterm depends on:
ii libc6 2.9-4 GNU C Library: Shared libraries
ii libfontconfig1 2.6.0-3 generic font configuration library
ii libice6 2:1.0.5-1 X11 Inter-Client Exchange library
ii libncurses5 5.7+20090404-1 shared libraries for terminal hand
ii libx11-6 2:1.2.1-1 X11 client-side library
ii libxaw7 2:1.0.5-2 X11 Athena Widget library
ii libxft2 2.1.13-3 FreeType-based font drawing librar
ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library
ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library
ii xbitmaps 1.0.1-2 Base X bitmaps
Versions of packages xterm recommends:
ii x11-utils 7.4+1 X11 utilities
ii xutils 1:7.3+18 X Window System utility programs m
Versions of packages xterm suggests:
ii xfonts-cyrillic 1:1.0.0-6 Cyrillic fonts for X
-- debconf-show failed
Thanks,
--- End Message ---
--- Begin Message ---
- To: Thomas Dickey <dickey@radix.net>
- Cc: 529601-done@bugs.debian.org
- Subject: Re: Bug#529601: xterm: copy-and-paste for iso-8859-7 encoding does not work
- From: Kornilios Kourtis <kkourt@cslab.ece.ntua.gr>
- Date: Thu, 21 May 2009 11:41:39 +0300
- Message-id: <20090521084139.GA11681@solar.cslab.ece.ntua.gr>
- In-reply-to: <20090521005620.GA26724@saltmine.radix.net>
- References: <20090520134611.GA28110@saltmine.radix.net> <20090520145354.GA10863@solar.cslab.ece.ntua.gr> <20090521000241.GA15468@saltmine.radix.net> <20090521005620.GA26724@saltmine.radix.net>
Version: 242-1
On Wed, May 20, 2009 at 08:56:20PM -0400, Thomas Dickey wrote:
> On Wed, May 20, 2009 at 08:02:41PM -0400, Thomas Dickey wrote:
> > >
> > > I've tried to play with these two options, and it seems to me that there
> > > isn't a consistent configuration for both the copying and pasting xterm,
> > > that works as expected. The case where selectToClipboard is set for the
> > > copying xterm, but not on the pasting seems to work OK.
> >
> > hmm - I'm not seeing it working at all (which makes it more interesting).
> > I'm using this as a wrapper:
>
> I'm still not reproducing just the case you're seeing, but adding
> a -k8 option does let me select/paste Greek text.
Yes, this works OK for me.
> As you noted in the bug report, the report mentioning the allowC1Printable
> resource is relevant.
>
> Running in just a el_GR locale, that's a different encoding from ISO-8859-1.
>
> The sending xterm sends the selection as a UTF8_STRING, and
> the receiving xterm (if allowC1Printable is false) attempts to read
> that selection data into a Latin-1 string, and replaces non-Latin-1
> by #'s.
>
> as an aside:
> The sending xterm makes the selection available in one or more
> flavors. UTF8_STRING happens to hold the most information, and
> is offered first by xterm if it's compiled for wide-characters.
> But xterm can be (as of #243) told to provide the flavors in a
> different order, or only certain flavors.
>
> The receiving xterm tries each flavor which is presented,
> until it finds one that works.
>
> For the UTF8_STRING, if -k8 is given, the xterm bypasses that branch,
> and either decodes it with XmbTextPropertyToTextList, or skips that
> flavor and accepts a STRING, which (using XmbTextPropertyToTextList) works
> in the current locale.
>
> The two menu settings ("Keep Selection" and "Select to Clipboard")
> control how the sending xterm makes the selection available.
>
> Here's a quick summary of the debug log:
>
> KeepSelecton SelectToClipboard flavor
> no no UTF8_STRING
> yes no UTF8_STRING
> no yes STRING
> yes yes STRING
>
I think that maybe it is a good time for me to finally switch to UTF8 :-)
Thanks,
--
Kornilios Kourtis
--- End Message ---