mule doesn't like languages different from english

------=_Part_317_27260794.1109777741525
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello!

My problem seems simple, but despite of this, I was unable to solve.=20

Being hungarian I just want to write in hungarian (any text) using
xemacs-mule running on anXFree86 xserver (which is actually running on
windows; this is the one supported by cygwin).

I'm using the correct (hungarian) keyboard and -of course- the
hungarian keymap on X

Everything in quite O.K., until I write into an xemacs buffer. The
accented charaters are display correctly, event the (hungarian-only)
udblacute and odblacute.  I'm happy.

Problems begin, when I want to save my text. In the saved text around
some accented characters ESC-A and ESC-B sequences tend to appear.

Ok,ok I know that this is the effect of the actual coding system,
which is tried to be "intelligently" chosen by xemacs.

However, I want greater control over the chosen/used coding system;
because my text is input for an another program (actually a document
formatter), which expects it to be encoded in ISO-8859-2; the ESC-A,
etc. characters render my text to incorrect.

How can I set a coding system/set up xemacs, so that it fulfills the
following requirements:
1)  the saved output is ISO-8859-2-encoded version of the visible
buffer content.
(ie udblacute corresponds 0xFB, odblacute to 0xF5, etc.)

2) the saved output can be re-opened, and the buffer is able to
reproduce the previous visual content (i.e no otilde in the place of
odblacute, no ucirc instead of udblacute, etc.)
It is not really necessary, that the xemacs recognizes the encoding,
it would be enough that after I specify it, the visual output
corresponds to the previous (original edit) state.

Test case:
---------------
I attach a file, that contans two such words that in them appear every
accented characters of the hungarian language. The file is expected to
be interpreted in ISO-8859-2.

1) I read it into xemacs. First error (but it is completely
tolerable): the character appearing beween 't' and 'r' should be
udblacute, but ucircumflex (u and a hat) appears.

2) Let's write something into the buffer. For example write the two
words, in the form that it should have been displayed. OK., done. The
output is visually correct. Lets save:
Hey! instead of udblacute and odblacute ~ appears in the saved file!!!
Ok, this is because of the "Raw" buffer encoding.

3) Set the buffer coding system (C-x C-m f) to iso-8859-2. Save.
Aaaaargh!!!! The saved file is (almost) full of ESC-A, ESC-B chars!!!=20
I do not reallly need them; the make the output unsuitable for further
processing ...

4) Let's go further. re-start xemacs, end re-open the just saved file
(with only 2*2 words, remember?) Aaaaargh!  The visual content of the
buffer contains ^[-A and ^[-B characters....  I guess these are the
ESC-A and ESC-B sequences, aren't they?

So, I'm a little bit lost with mule; I do not really know that it
could ever be useful to anyone using different language than english;
but why does it exist then?!


Thanks,=20
Tam=E1s

------=_Part_317_27260794.1109777741525
Content-Type: text/plain; name="test.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="test.txt"

=C1rv=EDzt=FBr=F5 t=FCk=F6rf=FAr=F3g=E9p
------=_Part_317_27260794.1109777741525--