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

[Eli Zaretskii]

> From: Kenichi Handa <address@hidden>
> CC: address@hidden, address@hidden
> Date: Wed, 12 Apr 2006 17:13:51 +0900
> 
> >> 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.

> > or do we want the inserted file to determine EOL
> > conversion as well?
> 
> Yes, because it's the behavior on Unix/GNU-Linux.
> 
> > I tend to think that we want XXX-dos regardless of the
> > inserted file.
> 
> With my change, even if the inserted file has no newline,
> and thus EOL part of the buffer-file-coding-system is still
> not decided, when a user input a newline in that buffer, it
> is encoded into CRLF.  Isn't it not enough?

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.  Why
should this be different under LANG=C?

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.