How do I read and write an iso-8859-1 file in Emacs 23?

How do I read and write an iso-8859-1 file in Emacs 23?

[Alan Mackenzie]

Hi, everybody, 

the subject just about says everything.  Emacs 23 insists on fouling up
my text, converting (for example) ü ("u umlaut") into \374 each time I
try to save it.  It then complains it can't save \374 because it can't
"convert" it.

In desperation, I tried putting this on the first line of the text:

    -*- mode : Text ; buffer-file-coding-system : iso-8859-1-unix -*-

.  Should this help?  Is it causing me problems?

I've tried reading the fine manual.  It helps me not in the slightest.
What am I missing here?  All I want to do is read an 8859-1 text file,
edit it, and write it back again.  How do I tell Emacs that an 0xFC
character in the file is actually a "u umlaut", and not anything else.
Why is Emacs insisting on trying to be so clever?

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: How do I read and write an iso-8859-1 file in Emacs 23?

[Peter Dyballa]

Am 28.03.2010 um 22:43 schrieb Alan Mackenzie:

>    -*- mode : Text ; buffer-file-coding-system : iso-8859-1-unix -*-


I prefer a simple "coding: iso-8859-15;" – besides this you can check  
the Options -> Mule -> Set Coding Systems menu (with short-cuts).

--
Mit friedvollen Grüßen

   Pete

"A TRUE Klingon warrior does not comment his code."

Re: How do I read and write an iso-8859-1 file in Emacs 23?

[Eli Zaretskii]

> Date: Sun, 28 Mar 2010 20:43:51 +0000
> From: Alan Mackenzie <acm@muc.de>
> 
> the subject just about says everything.

It is strange to read such questions in the year 2010 regarding Emacs
23.

> Emacs 23 insists on fouling up my text, converting (for example) ü
> ("u umlaut") into \374 each time I try to save it.  It then
> complains it can't save \374 because it can't "convert" it.

What does Emacs tell about this character when you type "C-u C-x ="
with point on the ü (before it is converted to \374)?  Also, how did
you insert that character into the buffer?

I suspect that something causes Emacs to treat it as a raw byte \374,
rather than a Latin-1 character.  (Yes, Emacs can distinguish between
these two.)

> In desperation, I tried putting this on the first line of the text:
> 
>     -*- mode : Text ; buffer-file-coding-system : iso-8859-1-unix -*-
> 
> .  Should this help?

Yes.  But it shouldn't be needed in most situations.

> Is it causing me problems?

It shouldn't.

> What am I missing here?  All I want to do is read an 8859-1 text file,
> edit it, and write it back again.  How do I tell Emacs that an 0xFC
> character in the file is actually a "u umlaut", and not anything else.

If you have this trouble in a file you visited and did not modify yet,
it could be that the file includes some raw bytes that don't fit any
encoding known to Emacs, or perhaps Emacs detected the encoding
incorrectly.  What does `buffer-file-coding-system' evaluate to in
this buffer, immediately after you visit the file?

> Why is Emacs insisting on trying to be so clever?

Because it's Emacs ;-)

Re: How do I read and write an iso-8859-1 file in Emacs 23?

[Alan Mackenzie]

Hi, Eli,

On Mon, Mar 29, 2010 at 09:33:13AM +0300, Eli Zaretskii wrote:
> > Date: Sun, 28 Mar 2010 20:43:51 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > the subject just about says everything.

> It is strange to read such questions in the year 2010 regarding Emacs
> 23.

I feel that Emacs 23 is less stable in this respect than Emacs 22.

> > Emacs 23 insists on fouling up my text, converting (for example) ü
> > ("u umlaut") into \374 each time I try to save it.  It then
> > complains it can't save \374 because it can't "convert" it.

> What does Emacs tell about this character when you type "C-u C-x ="
> with point on the ü (before it is converted to \374)?  Also, how did
> you insert that character into the buffer?

My buffer is now doing the Right Thing, both displaying a ü ("u umlaut")
as it should be, and saving it correctly as the single byte 0xfc.
Previously, it was sometimes being displayed as "\374" as I typed.  I
don't know exactly what I did to achieve this; I'm thoroughly confused
about it.

To insert the ü, I typed a key-combination programmed to generate 0xFC
on a Linux virtual terminal.

> I suspect that something causes Emacs to treat it as a raw byte \374,
> rather than a Latin-1 character.  (Yes, Emacs can distinguish between
> these two.)

> > In desperation, I tried putting this on the first line of the text:

> >     -*- mode : Text ; buffer-file-coding-system : iso-8859-1-unix -*-

> > .  Should this help?

> Yes.  But it shouldn't be needed in most situations.

I've since removed it.

> > Is it causing me problems?

> It shouldn't.

Thanks!

> > What am I missing here?  All I want to do is read an 8859-1 text file,
> > edit it, and write it back again.  How do I tell Emacs that an 0xFC
> > character in the file is actually a "u umlaut", and not anything else.

> If you have this trouble in a file you visited and did not modify yet,
> it could be that the file includes some raw bytes that don't fit any
> encoding known to Emacs, or perhaps Emacs detected the encoding
> incorrectly.  What does `buffer-file-coding-system' evaluate to in
> this buffer, immediately after you visit the file?

I've lost that info, now.  It was probably raw-text or no-translation
(whatever the difference is between these two).

> > Why is Emacs insisting on trying to be so clever?

> Because it's Emacs ;-)

Ah, OK!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: How do I read and write an iso-8859-1 file in Emacs 23?

[Andreas Röhler]

Alan Mackenzie wrote:
> Hi, Eli,
> 
> On Mon, Mar 29, 2010 at 09:33:13AM +0300, Eli Zaretskii wrote:
>>> Date: Sun, 28 Mar 2010 20:43:51 +0000
>>> From: Alan Mackenzie <acm@muc.de>
> 
>>> the subject just about says everything.
> 
>> It is strange to read such questions in the year 2010 regarding Emacs
>> 23.
> 
> I feel that Emacs 23 is less stable in this respect than Emacs 22.
> 
>>> Emacs 23 insists on fouling up my text, converting (for example) ü
>>> ("u umlaut") into \374 each time I try to save it.  It then
>>> complains it can't save \374 because it can't "convert" it.
> 
>> What does Emacs tell about this character when you type "C-u C-x ="
>> with point on the ü (before it is converted to \374)?  Also, how did
>> you insert that character into the buffer?
> 
> My buffer is now doing the Right Thing, both displaying a ü ("u umlaut")
> as it should be, and saving it correctly as the single byte 0xfc.
> Previously, it was sometimes being displayed as "\374" as I typed.  I
> don't know exactly what I did to achieve this; I'm thoroughly confused
> about it.

That's a very old, known issue. Reported it years ago.
As it happens seldom, I'm able to live with.

It happens sometimes, if text is pasted from an email.

Than umlauts are displayed as (their) numbers.

Workaround is to mark the whole buffer, copy it into another one.
In the next buffer umlauts are shown correctly.

Cheers


Andreas

--
https://code.launchpad.net/~a-roehler/python-mode
https://code.launchpad.net/s-x-emacs-werkstatt/




> 
> To insert the ü, I typed a key-combination programmed to generate 0xFC
> on a Linux virtual terminal.
> 
>> I suspect that something causes Emacs to treat it as a raw byte \374,
>> rather than a Latin-1 character.  (Yes, Emacs can distinguish between
>> these two.)
> 
>>> In desperation, I tried putting this on the first line of the text:
> 
>>>     -*- mode : Text ; buffer-file-coding-system : iso-8859-1-unix -*-
> 
>>> .  Should this help?
> 
>> Yes.  But it shouldn't be needed in most situations.
> 
> I've since removed it.
> 
>>> Is it causing me problems?
> 
>> It shouldn't.
> 
> Thanks!
> 
>>> What am I missing here?  All I want to do is read an 8859-1 text file,
>>> edit it, and write it back again.  How do I tell Emacs that an 0xFC
>>> character in the file is actually a "u umlaut", and not anything else.
> 
>> If you have this trouble in a file you visited and did not modify yet,
>> it could be that the file includes some raw bytes that don't fit any
>> encoding known to Emacs, or perhaps Emacs detected the encoding
>> incorrectly.  What does `buffer-file-coding-system' evaluate to in
>> this buffer, immediately after you visit the file?
> 
> I've lost that info, now.  It was probably raw-text or no-translation
> (whatever the difference is between these two).
> 
>>> Why is Emacs insisting on trying to be so clever?
> 
>> Because it's Emacs ;-)
> 
> Ah, OK!
>