Bug 83357

Summary: Hungarian accents not saved
Product: [Retired] Red Hat Linux Reporter: Need Real Name <karolyi>
Component: xemacsAssignee: Jens Petersen <petersen>
Status: CLOSED DEFERRED QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: mitr, srevivo
Target Milestone: ---Keywords: MoveUpstream
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-04-08 21:44:46 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
Some Hungarian text
none
Current coding systems
none
Another coding system
none
Some erroneously saved hungarian text none

Description Need Real Name 2003-02-03 04:44:40 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:
When writing text in Hungarian, the Hungarian umlauts appear correctly
on the screen, in the xemacs buffer. However, after saving and loading
the same text, these characters disappear, and a ~ appears in their
place. All other programs seem to handle these characters well, moreover, when I
cut and paste the text into another window with the mouse, they work perfectly
there. Just xemacs is unable to save them properly.



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


How reproducible:
Always

Steps to Reproduce:
1. Write text containing the characters with Hungarian accents
2. Save file
3. Load file
    

Actual Results:  In place of the Hungarian umlauted characters, ~ appears.

Expected Results:  See the original accented characters.

Additional info:

xemacs 21.4 (patch 8) "Honest Recruiter"
Computer: HP XT6200 notebook, with a Hungarian keyboard.
Output of locale:
LANG,LC_NUMERIC,LC_TIME,LC_COLLATE,LC_MONETARY,LC_MESSAGES,LC_PAPER,
LC_NAME,LC_ADDRESS,LC_TELEPHONE,LC_MEASUREMENT,LC_IDENTIFICATION are all
en_US, but
LC_CTYPE=hu_HU
Comment 1 Jens Petersen 2003-02-05 01:07:21 EST
Could you please attach some Hungarian text (as a binary file with
content-type binary/octet-stream)?

Could you also select from the menubar "Edit -> Multilingual ("mule") ->
Describe Current Coding Systems" and attach the output.

Does Emacs work better with Hungarian?
Comment 2 Need Real Name 2003-02-06 08:27:39 EST
Created attachment 89894 [details]
Some Hungarian text

The last word in the file contains the two problematic characters: ő and ű.
Comment 3 Need Real Name 2003-02-06 08:34:57 EST
Created attachment 89895 [details]
Current coding systems

This is the output of 
EDIT -> Multilingual -> Display current coding systems.
This produced the previously described behaviour.
Then I fiddled with the settings, and I received a different behaviour, see
next attachement.
Comment 4 Need Real Name 2003-02-06 09:00:39 EST
Created attachment 89896 [details]
Another coding system

When I put
(set-language-environment "Latin-2")
in 
~/.xemacs/init.el
the behaviour changes: then it saves properly all the accented characters, but
inserts some "escape" characters or something similar to each line containing
accented characters other than those in the last word of the first attachement
(titled "some Hungarian text"), just before the first accented character of the
line, and to the end of the line.

If I load now attachement one (titled "some Hungarian text") into xemacs, it
loads properly, if I save it again, it saves and re-loads properly. But when I
write it again, it looks to be the same in the buffer, but after saving it, I
get a different result (see next attachement). The result is similar now to
that xemacs tries to interpret all other accented characters by some oter
encodings, hence it inserts some escapes, but it handles the accents properly
that are unique to latin-2 encoding.

This attachement contains the output of
EDIT -> Mule -> Show current coding systems
when I included in .xemacs/init.el:
(set-language-environment "Latin-2")
Comment 5 Need Real Name 2003-02-06 09:04:14 EST
Created attachment 89897 [details]
Some erroneously saved hungarian text

Some Hungarian text that was saved erroneously by xemacs. The first line was
written by another editor (joe), then it was loaded to xemacs, and the rest was
typed there. On the screen the first and the second line looks to be the same,
but after saving they will differ.

As for the last question of comment #1, I never tried emacs, just xemacs.
Comment 6 Jens Petersen 2003-05-19 03:18:01 EDT
What locale are you using btw?

If you load "un-define" into XEmacs and work in a utf-8 coding-system,
do things work better for you?

(The current XEmacs (xemacs + xemacs-sumo now) in rawhide is configured
by default to start up in utf-8 if run in a utf-8 locale (like hu_HU.UTF-8).
Comment 7 Need Real Name 2003-05-23 08:02:44 EDT
As for locale, I mentioned in the original message that it is:

LANG,LC_NUMERIC,LC_TIME,LC_COLLATE,LC_MONETARY,LC_MESSAGES,LC_PAPER,
LC_NAME,LC_ADDRESS,LC_TELEPHONE,LC_MEASUREMENT,LC_IDENTIFICATION are all
en_US, but
LC_CTYPE=hu_HU

Originally I worked in utf-8 encoding, but it did not work with Hungarian
accents at all (I do not remember what it did with xemacs, it did not work with
most programs). I do not know what load "un-define" means.

Some other ideas: I tried in the meantime xemacs in debian. There they have
several packages for xemacs, and their xeamcs-mule package worked like the
xemacs in redhat. However, their xemacs-nomule package works somewhat better: it
substitutes different, but similar characters instead of the Hungarian accents
in the edit window, but after saving they are correct. In the edit window they
use latin1 characters. I understand that mule should provide the support for
latin2 characters, but it does it incorrectly it seems. Probably it is not a
redhat-specific problem.

Best wishes:
Gyorgy
Comment 8 Jens Petersen 2003-11-05 20:31:56 EST
Could you please retest with the latest xemacs packages?
Comment 9 Jens Petersen 2004-04-08 21:44:46 EDT
Closing for lack of activity.  Please re-open if you still
have problems with current xemacs.  Thanks.