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 20:47:10 +0900
> 
> 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?

I'm not sure.  This gives the first inserted file some kind of special
treatment, and I'm not sure it's justified.

As long as the above is limited to buffer-file-coding-system being
nil, it is a very marginal case, but since you seem to be suggesting
to have this behavior with other encodings as well, it becomes a
greater issue.  See below.

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

> > 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?  Right now, the difference between LANG=C and other
languages is that LANG=C causes the language environment to be reset,
like with other values of LANG, but unlike the other values, we then
don't set the language environment to anything.  This is why the
default buffer-file-coding-system is left at its nil value (as set by
reset-language-environment).  And this is why LANG=C results in a
different behavior wrt EOL conversion of newly created files.

So please describe in more detail what changes do you suggest to make
other languages behave like LANG=C does.  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.