[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: How do I read and write an iso-8859-1 file in Emacs 23?
From: |
Alan Mackenzie |
Subject: |
Re: How do I read and write an iso-8859-1 file in Emacs 23? |
Date: |
Tue, 30 Mar 2010 10:42:22 +0000 |
User-agent: |
Mutt/1.5.9i |
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).