In article <[EMAIL PROTECTED]>, Eli Zaretskii <[EMAIL PROTECTED]> writes:
> You wrote: >> If buffer-file-coding-system is nil, and some other file is >> inserted with decoding, the buffer-file-coding-system is >> changed to the coding-system used for that decoding. > To that, I asked whether on Windows we want in this case > buffer-file-coding-system to change to XXX-dos, where XXX is the > text-encoding part of the coding-system used for that decoding. I still don't understand. If buffer-file-coding-system is nil and you insert a file, buffer-file-coding-system is changed as below (both on Unix and Windows): inserted file buffer-file-coding-system -------------- ------------------------- ascii (no eol) nil ascii (unix eol) undecided-unix ascii (dos eol) undecided-dos latin1 (no eol) iso-latin-1 latin1 (unix eol) iso-latin-1-unix latin1 (dos eol) iso-latin-1-dos Do you see a problem with it? >> > But with LANG set to "English" (or any other language that specifies a >> > preferred coding system in locale-language-names), inserting a file >> > with Unix EOLs does not change the EOL conversion of the buffer. >> >> I think that should be fixed, i.e. >> default-buffer-file-coding-system should not specify >> eol-format. > But that would be a step backwards: the EOL conversion specified by > default-buffer-file-coding-system is how we make Windows use CRLF by > default, and Mac use CR by default. With my recent fix, we don't have to set default-buffer-file-coding-system other than nil for using CRLF by default on Windows. As for Mac, as system_eol_type is not set to CODING_EOL_CR on it, the situation is different. If Mac uses CR by default (I don't know), system_eol_type should be set to CODING_EOL_CR. Setting default-buffer-file-coding-system to undecided-mac is just a workaround. > For example, dos-w32.el says: > (setq-default buffer-file-coding-system 'undecided-dos) > which is how we cause the DOS and Windows ports to use -dos EOL > conversion by default, because all the functions involved in setting > the default coding systems for the current locale and language take > care to copy the EOL conversion from the original default to the new > defaults. I haven't realized that EOL is handled in that way on DOS and Windows. I think we don't have to handle default-buffer-file-coding-system specially on DOS and Windows. >> > In other words, I don't think the value of LANG has anything to say >> > about the preferred EOL conversion. The default EOL conversion should >> > stay according to the platform's conventions, no matter what LANG is >> > set to. Currently, on Windows it stays -dos for any value of LANG >> > except "C", and I don't see anything special about the "C" locale that >> > it should be different from any other locale as far as EOLs are >> > concerned. >> >> I agree on this point. Actually, if a coding system doesn't >> specify an eol-format (e.g. nil, iso-latin-1, raw-text), the >> latest CVS version encodes EOL according to system_eol_type >> (i.e. on Windows, CRLF). > Okay, but with LANG=C, "C-x C-f" still creates new files with a nil > buffer-file-coding-system, and if I insert a Unix-style file into that > buffer, the EOL conversion changes to raw-text-unix. I think that is the correct behavior. At least, that's the behavior on Unix. > I think treating LANG=C in such a special way is not > right. Yes, so, my claim is that it is better to change cases of the other language to match with the LANG=C case. --- Kenichi Handa [EMAIL PROTECTED] _______________________________________________ emacs-pretest-bug mailing list [email protected] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
