"Wedler, Christoph" <christoph.wedler(a)sap.com> writes:
Well, it doesn't contradict the docstring of
default-buffer-file-coding-system:
Default value of `buffer-file-coding-system' for buffers that do not
override it. This is the same as (default-value
'buffer-file-coding-system). This value is used both for buffers
without associated files and for buffers whose files do not have any
apparent coding system.
If you set `default-buffer-file-coding-system' to `iso-2022-8-dos' and
visit a Unix file with ASCII-only characters, this file doesn't probably
have a "apparent coding system", that's why the corresponding is
`#<coding_system iso-2022-8-dos>'.
You mean there's no LF in that file? If a file does
not have EOL, XEmacs has no way to autodetect it. So in
that case, you are seeing the correct behavior.
Err, yes... The wording in my previous message wasn't good: I
just
wanted to say (in the section starting with "But there is no..." and in
earlier messages) that it would be useful to be able to customize that
eol type nil when saving can mean CRLF (or CR) instead of LF.
OK, so we have been talking about different things. No
wonder we don't agree.
It might better if you said "allow toggling of EOL type in
new files" instead in original message. Your original
proposal sounded like you want to add different feature for
toggle-buffer-coding-system.
I still think chaning default-buffer-file will solve most of
the cases but I have no objection to applying your patch.
--
Yoshiki Hayashi