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

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> 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
address@hidden