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): emacs-21.4-14 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:
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 gibberish.
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? Chip
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. 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 way.
This went by on emacs-devel recently: From: Romain Francoise <romain> Subject: Cut buffers and character encoding To: emacs-devel Date: Thu, 09 Nov 2006 08:39:34 +0100 Organization: orebokech dot com Hi, 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 report: ,---- | 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 Thanks, -- Romain Francoise <romain> | 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 Emacs-devel http://lists.gnu.org/mailman/listinfo/emacs-devel
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. Chip
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" program: 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. Hmmmm. Chip
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. http://fedoraproject.org/wiki/LifeCycle/EOL 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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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.