Re: Wrong type argument: arrayp, nil with LANG=C under Windows

[Eli Zaretskii]

> From: Kenichi Handa <address@hidden>
> CC: address@hidden, address@hidden
> Date: Thu, 13 Apr 2006 15:25:18 +0900
> 
> In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
> 
> >> >> If buffer-file-coding-system is dos, and some other file is
> >> >> inserted with decoding, the buffer-file-coding-system is
> >> >> changed to XXX-dos where, XXX part is the text-encoding part
> >> >> of the coding-system used for that decoding.
> >> 
> >> > Do we want it to change to XXX-dos on Windows,
> >> 
> >> What do you mean by "it" above?
> 
> > The value of buffer-file-coding-system.
> 
> Then, I don't understand why you ask it in this context.
> Do you actually mean default-buffer-file-coding-system?

No.

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.

> > 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.  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.

> > 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 treating
LANG=C in such a special way is not right.