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

[Kenichi Handa]

In article <address@hidden>, Eli Zaretskii <address@hidden> writes:

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

> But if we don't do that, if the user inserts a Unix-style file into a
> buffer created by visiting a non-existing, she will get a Unix-style
> new file, which is different from what users expect on Windows, I
> think.

Really?  If one inserts a Unix-style file, I guess she wants
to save it with Unix-style.  But, as I don't use Windows
that much, I may be wrong.

At least, I've never heard a complaint about the current
behavior on Unix; i.e. when one inserts a Dos-style file in
a new buffer, it is saved with Dos-style.

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

> Match how?

Leave eol-part of default-buffer-file-coding-system unset
(the same as Unix version).

> In particular, if the changes you suggest will cause the
> first inserted file affect the EOL conversions in the same
> way they do with LANG=C, I think we need to consider this
> behavior more carefully, since it will then become visible
> to every user on Windows.

Yes.  If you think such a change is too dangerous at this
stage or not preferred by Windows users, it is better to set
default-buffer-file-coding-system to `undecided-dos' in
LANG=C case for the current version.  At least, I agree that
LANG=C case should not be different from the other cases in
EOL handling.

---
Kenichi Handa
address@hidden