[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can't save in iso-8859-13
From: |
Kenichi Handa |
Subject: |
Re: Can't save in iso-8859-13 |
Date: |
Mon, 4 Apr 2005 20:43:39 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
In article <address@hidden>, Peter Dyballa <address@hidden> writes:
> Am 04.04.2005 um 03:19 schrieb Kenichi Handa:
>> The above script outputs raw bytes 0..255, which is not a
>> valid utf-8 code expected in *shell* buffer. So, Emacs
>> decodes them as raw-byte characters (i.e. characters
>> belonging to charsets eight-bit-control and
>> eight-bit-graphic).
>>
>> If you want to get iso-8859-13 characters in *shell* buffer,
>> you must change the process coding systems of the buffer to
>> iso-latin-7 by C-x RET p iso-latin-7 RET iso-latin-7 RET.
> My script indeed produces only raw output, which, to become valid
> UTF-8, would need an introductory C2 or C3 character. The question is:
> why were these raw characters converted into valid UTF-8
They were not. Why do you think "those raw characters were
converted into valid UTF-8"?
You wrote:
> In shell I only saw octal representation.
So, those raw characters were NOT recognized as valid UTF-8,
and thus not converted into normal Emacs characters.
> and why was this not converted into ISO 8859-13 upon
> inserting into the file buffer?
As far as you are copying from a multibyte byffer to a
multibyte buffer of Emacs, no character is converted upon
inserting.
> Or at least when saving the file?
Because they are raw-byte characters.
> My usual selection-coding-system seems to be
> compound-text-with-extensions, open to accept anything.
Why is selection-coding-system relevant to the current
problem?
---
Ken'ichi HANDA
address@hidden