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):
Steps to Reproduce:
1.Select text in gnome-terminal
2.Try to use the middle button to paste it into emacs
emacs pastes some random text it had cut before.
Pasting the text I had selected in gnome-terminal
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
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?
In fact, from an xterm I could paste in Chinese characters ....
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...
Created attachment 141305 [details]
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
This went by on emacs-devel recently:
From: Romain Francoise <firstname.lastname@example.org>
Subject: Cut buffers and character encoding
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:
| 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 ]
| 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 <email@example.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
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.
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
(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.
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
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
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.