Bug 74100 - pasting in default configuration works bad for Cyrillic text
pasting in default configuration works bad for Cyrillic text
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: emacs (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Jay Turner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-16 02:00 EDT by olonho
Modified: 2015-01-07 19:00 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-20 02:55:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description olonho 2002-09-16 02:00:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1b) Gecko/20020722

Description of problem:
 If paste i18n text, such as cyrillic to Emacs text appears with some unreadable
prefix. Some investigation showed it's caused by bad value for selection coding
system. It should be set to  compound-text-with-extensions by doing something like
(set-selection-coding-system 'compound-text-with-extensions)
in .emacs. So I'm proposing to put similar string to 
/etc/skel/.emacs. 

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


How reproducible:
Always

Steps to Reproduce:
1. Open russian text, let's say http://lib.ru in Mozilla (or any other X app)
2. select russian text to X clipboard
3. paste it to Emacs - result will be prefixed bu something unreadable.
	

Actual Results:   Bad text appears.

Expected Results:   Russian text should be pasted correctly.

Additional info:

 This encoding is supported only in emacs 21, so it's mostly relevant for Redhat 7.3
Comment 1 Jens Petersen 2002-10-09 00:14:46 EDT
Which version-release of emacs are you using?

I can't reproduce this in RHL 7.3.
Comment 2 olonho 2002-10-09 01:47:12 EDT
 I've been using RH7.2, when found this problem. LANG=ru_RU.koi8r.
emacs was 20.7.
Comment 3 olonho 2002-10-09 01:54:43 EDT
Here's how typical bad text looks like (couldn't copy past as backward copy-past
works OK, so typing from the screen):
^[%/1\200\210koi8-r^BsAMAJA


 Also don't forget to set encoding in Mozilla to KOI8-R.

Comment 4 Jens Petersen 2002-10-09 07:58:27 EDT
Ok, I reproduced the problem now when galeon is running in a non-Japanese.

Well interesting enough the result seems to depend only on the locale of
browser, not that Emacs!

Browser locale          Result
--------------          ------
ja_JP                   works
C or latin-1            get question marks
ru_RU                   garbage as you describe

So one workaround is running mozilla in a Japanese locale! ;-)

Seriously though, I feel this ought to be a well-known problem, no?
Has it ever worked in Emacs before?
Comment 5 Jens Petersen 2002-10-09 09:00:25 EDT
Sorry for the poor language:

1st line should end "in a non-Japanese _locale_."

2nd sentence should end "not that _of_ Emacs!
Comment 6 olonho 2002-10-09 13:41:44 EDT
 It never worked well for me, starting from RH6.2 at least.
Pasting from cut buffers (like xterm) works, but this compound text has problems
(so pasting from KDE or GNOME apps doesn't work).
When I was investigating this prblem I found that someone in Finland complain
about similar problem with Finnish locale, so it doesn't look like 
Cyrillic only problem, it's more like 8-bit non-ISO-1 charsets problem.
 BTW, what's wrong with workaoround I suggested?
Comment 7 Jens Petersen 2003-02-07 11:41:53 EST
Adding `(set-selection-coding-system 'compound-text-with-extensions)'
to .emacs in emacs-21.2-32.  Thank for your patience. :)

[Btw it is already the default in cvs emacs now.]

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