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

[Kenichi Handa]

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?

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

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

---
Kenichi Handa
address@hidden