After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319687 - Pasting of text containing characters not in the terminal's encoding silently fails
Pasting of text containing characters not in the terminal's encoding silently...
Status: RESOLVED FIXED
Product: gnome-terminal
Classification: Core
Component: general
2.13.x
Other All
: Normal normal
: ---
Assigned To: GNOME Terminal Maintainers
GNOME Terminal Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-10-24 23:56 UTC by Nicholas Miell
Modified: 2007-12-10 23:51 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Nicholas Miell 2005-10-24 23:56:23 UTC
Please describe the problem:
If you attempt to paste text containing characters not in the terminal locale's
character set, the paste will silently fail (i.e. nothing will happen at all
with no indication as to why).

Steps to reproduce:
1. Set your terminal to a limited character encoding (like ISO-8859-1)
2. Copy some text containing characters not included in that encoding. (Here's
some: Em Dash: — Ellipsis: …)
3. Attempt to paste that copied text into your terminal



Actual results:
Nothing happens.

Expected results:
Ideally, attempting to paste such text would pop up a message box saying
something like "The text you are attempting to Paste contains characters that
cannot be represented in the current terminal encoding. [Paste without these
characters] [Cancel Paste]" (But all easy to understand and HIGified, of course).

Does this happen every time?
Yes

Other information:
Comment 1 Samuli Kärkkäinen 2005-12-30 19:02:21 UTC
I so confirm this bug. To anyone who wonders if this bug is a serious one, I holily reassure you it is. It seems totally random, and it's really maddening when pasting appears to simply not work completely randomly. Most recently I was bitten by it by someone using apostrophe (') that really was something else, and visually it wasn't possible to see the difference.
Comment 2 Reinout van Schouwen 2006-01-22 14:01:36 UTC
Confirming this bug with gnome-terminal 2.13.3.
Comment 3 Brent Smith (smitten) 2006-01-29 01:30:51 UTC
Marking NEW.
Comment 4 Pascal Terjan 2007-06-30 19:15:35 UTC
Actually other cases of pasting silently fail and while I think another bug report should be opend (as it should not fail in that case), reporting other paste errors would be nice IMHO.

As reported in comments of http://qa.mandriva.com/show_bug.cgi?id=20778 , when copying from galeon, if an accentuated character occurs just before a newline, the paste will silently fail in gnome-terminal (but work in other apps) while copying the exact same text is OK if no accentuated character is at the end of the lines.
Comment 5 BAndersson 2007-12-10 19:40:39 UTC
Confirming this bug in gnome-terminal 2.18.2. To rephrase Samuli's comment above; this is super-irritating. As one who like to paste text into the body of a mail (as opposed to attaching it as a file) this bug really hurts. In case anyone wonder, I use Pine as a mail client.

Original bug report describes the behaviour perfectly. 
Comment 6 Behdad Esfahbod 2007-12-10 23:51:36 UTC
Just committed a change to first try g_iconv_open with "targetcharset//translit"  and try "targetcharset" if that fails.  With GLibc and GNU iconv, that means translation never fails and it does a very nice job of transliteration.  For example, converting from UTF-8 to Latin1//translit, Arabic chars are replaced by question marks, but "Ňň" will be converted to "Nn".

2007-12-10  Behdad Esfahbod  <behdad@gnome.org>

        Bug 319687 – Pasting of text containing characters not in the
        terminal's encoding silently fails

        * src/vteconv.c (_vte_conv_open): Try to open converter with
        transliteration.  Supported by GNU iconv and GLibc.