"Wedler, Christoph" <christoph.wedler(a)sap.com> writes:
> What's wrong with
> (setq file-coding-system-alist
> (append file-coding-system-alist '(("." . undecided-dos)))
> as a workaround?
It doesn't work:
1. Use the above appended list
2. Open a new file foo.txt with two line of "ab".
3. You see the modeline is still "ISO8" (and
`buffer-file-coding-system' is iso-2208-8), but this would be
acceptable, although not nice (since I also see ISO8 for Unix
endings and ISO8:T for dos)
4. Save the buffer, the length is 6 bytes (i.e., Unix endings)
5. Kill the buffer, re-read it.
6. Modeline ISO8:T, and `buffer-file-coding-system' is #<coding_system
iso-2022-8-dos> -- huh?
7. delete your entry from file-coding-system-alist
8. Kill the buffer, re-read it.
9. Modeline ISO8, and `buffer-file-coding-system' is #<coding_system
iso-2022-8-unix>
Did you try this?
(setq-default default-buffer-file-coding-system 'iso-8859-1-dos)
I didn't test it with non-MULE file-coding XEmacs but it
works with MULE and it should work in your case, too.
BTW, I haven't seen one reason by anyone, why toggling from eol
type nil
to some other (whether unix, dos or mac) is bad.
OK, if you insist...
First, it simply doesn't work.
You have LF and you want it to conver to CR. You need to
do M-x toggle-buffer-coding-system twice to get CR from
LF. Then the default becomes CRLF even if the last one
choosed by user is LF.
You may say, 'OK, let's change default always'. But I don't
think it is a good change because it surprises user
Suppose you are living in Unix world. Normally, default
EOL type is nil because nil means LF. Then you wanted to
copy a file to Windows so you changed it to CRLF.
Suddenly, all new files become CRLF while you only
wanted one file to be CRLF.
If the functionality to change default EOL type is desired,
it should be done by different function. The above are
reason why I think overloading toggle-buffer-coding-system
is not a good idea.
--
Yoshiki Hayashi