[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problem with system_eol_type
From: |
Katsumi Yamaoka |
Subject: |
Re: problem with system_eol_type |
Date: |
Tue, 01 Aug 2006 15:10:27 +0900 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) |
>>>>> In <address@hidden> Stefan Monnier wrote:
>> By the way, why is not CR used in Mac when specifying the coding
>> system `foo', not `foo-eol'?
> Only Mac OS 9 used CR-eol. Mac OS X uses LF, like any other Unix variant.
Thanks. It backs up the validity of the recent change in the
nnheader-insert-head function.
>> Contrary to this argument concerning saving of files, I hope the
>> forms
>> (encode-coding-string "bar\n" 'foo)
>> and
>> (with-temp-buffer
>> (insert "bar\n")
>> (encode-coding-region (point-min) (point-max) 'foo)
>> (buffer-string))
>> always return "bar\n" regardless of the system-type in the
>> future as well.
> Why this discrepancy?
Because (at least) Gnus will need to be fixed here and there if
Emacs is changed so as to return "bar\r\n" or "bar\r" for those
forms. For instance, if there are Latin-1 characters in a
message body, "bar\n" will be encoded by quoted-printable into
"bar=0D\n" or "bar=0D", which is not a good result. I think it
is reasonable that LF is the default eol for strings and
buffer's contents since they are normally used internally in
Emacs.
- Re: problem with system_eol_type,
Katsumi Yamaoka <=