Bug 187026 - Cannot paste from gnome-terminal (or any GNOME program) into emacs
Summary: Cannot paste from gnome-terminal (or any GNOME program) into emacs
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 5
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Chip Coldwell
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2006-03-28 04:44 UTC by Eric Hopper
Modified: 2008-05-06 15:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-05-06 15:40:45 UTC
Type: ---

Attachments (Terms of Use)
A screenshot. (2.45 KB, image/png)
2006-11-15 20:58 UTC, Pawel Salek
no flags Details

Description Eric Hopper 2006-03-28 04:44:15 UTC
Description of problem:
When I select some text in gnome-terminal or some other GNOME program and try to
use the middle button to paste it into emacs, it doesn't work.  In fact, there
is no way I can see to paste it at all.  I've resorted to typing 'cat
>~/.clipboard' in a window, pasting into that, then using C-x i in emacs to
insert that file into the buffer.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1.Select text in gnome-terminal
2.Try to use the middle button to paste it into emacs
Actual results:
emacs pastes some random text it had cut before.

Expected results:
Pasting the text I had selected in gnome-terminal

Additional info:

Comment 1 Pawel Salek 2006-06-26 07:30:19 UTC
Pasting text works for me as long as it is pure 7-bit ASCII. Pasting diacritic
characters like Å, ö works partially: the characters are surrounded by some

Comment 2 Chip Coldwell 2006-11-14 22:35:41 UTC
I am unable to reproduce this problem.  I was able to paste from gnome terminal,
including some text that included an "ä".

Which window manager are you using?

Have you tried pasting from an xterm?


Comment 3 Chip Coldwell 2006-11-14 22:36:25 UTC
In fact, from an xterm I could paste in Chinese characters ....

Comment 4 Pawel Salek 2006-11-15 20:55:49 UTC
I see the problem with emacs-21.4-17 (FC6). Try pasting following test:
"wzięły". Strangely enough, when I copy the gibberish from the emacs window to
firefox, it looks ok again. I think I will attach a screenshot...

Comment 5 Pawel Salek 2006-11-15 20:58:41 UTC
Created attachment 141305 [details]
A screenshot.

A screenshot. I wonder whether this could be some strange font problem: emacs
does not detect right font and chooses to display the pasted text in another

Comment 6 Chip Coldwell 2006-11-17 18:12:36 UTC
This went by on emacs-devel recently:

From: Romain Francoise <romain@orebokech.com>
Subject: Cut buffers and character encoding
To: emacs-devel@gnu.org
Date: Thu, 09 Nov 2006 08:39:34 +0100
Organization: orebokech dot com


I received a bug report about Emacs 22.0.90 stating that Emacs doesn't
do charset conversion when receiving text from a cut buffer.  From the

| When I paste the cut buffer in an Emacs window in UTF-8 locales, Emacs
| doesn't do any charset conversion. This problem occurs with both X and
| GTK versions.
| To reproduce the problem:
| 1. In UTF-8 locales: emacs -q
| 2. Open an xterm.
| 3. In the xterm, type 'éèê'.
| 4. Select 'éèê' in the xterm.
| 5. Quit the xterm (now, 'éèê' is no longer in the primary selection,
|    only in the cut buffer, which Emacs supports).
| 6. Paste in Emacs (middle mouse button).
| I get:
| \351\350\352
| instead of:
| éèê

This is in apparent contradiction to what the docstring of the
`selection-coding-system' variable says:

,----[ C-h v selection-coding-system RET ]
| Documentation:
| Coding system for communicating with other X clients.
| When sending or receiving text via cut_buffer, selection, and clipboard,
| the text is encoded or decoded by this coding system.

Using xcutsel to move the cut buffer back to a primary selection shows
that the content itself is fine, so the problem lies with Emacs.

More info here: http://bugs.debian.org/397447


Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Emacs-devel mailing list

Comment 7 Chip Coldwell 2006-11-17 18:15:30 UTC
The issue here is a difference between the encoding used by the X selection and
the encoding used by the visited emacs buffer.  Try the following experiment

M-x find-file-literally /tmp/test1

Copy and paste in some text that contains non-ASCII characters.  You will most
likely see the octal codes for the iso-8859-1 (Latin-1) encodings of these
characters.  Then try

C-x RET c utf-8 C-x C-f /tmp/test2

and past in the same text.  Let me know what happens.


Comment 8 Pawel Salek 2006-11-18 00:23:40 UTC
In both cases, the text ąśźż gets pasted wrong in the same way. There is one
thing I noticed when I saved the files and tested the file content with "file"

literal:   UTF-8 Unicode text, with escape sequences (14 bytes)
Pure file as generated with cat (or vi, or emacs -nw) is:
testcat:   UTF-8 Unicode text (9bytes)

These two files look identical when I can them to terminal window, although they
have different sizes. I wonder whether this is a question of ignoring or
removing these escape sequences. Strangely enough, if I run emacs without window
(i.e. with -nw option), everything works fine. But I guess different paste
mechanisms are used then.

See also http://www.gatago.com/gnu/emacs/help/9025951.html

I should add that pasting latin-1 characters (öäå) works fine but not latin-2

Comment 9 Chip Coldwell 2006-11-20 15:12:53 UTC
(In reply to comment #8)

> literal:   UTF-8 Unicode text, with escape sequences (14 bytes)
> Pure file as generated with cat (or vi, or emacs -nw) is:
> testcat:   UTF-8 Unicode text (9bytes)

The escape sequences appear to be a prefix before and suffix after the correct
character encodings.  In particular, it is prefixed by ^[%G (\033\045\107) and
followed by ^[%@ (\033\045\100).  However the characters in between are correct
and show up that way if you run

C-c RET X utf-8

before you paste in.



Comment 10 Bug Zapper 2008-04-04 02:19:05 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 11 Bug Zapper 2008-05-06 15:40:38 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.