bug#44513: default value of file-name-coding-system

[Eli Zaretskii <eliz@gnu.org>]

On November 8, 2020 2:27:03 PM GMT+02:00, Boruch Baum <boruch_baum@gmx.com> wrote:
> On 2020-11-08 13:29, Eli Zaretskii wrote:
> > On November 8, 2020 11:15:50 AM GMT+02:00, Boruch Baum
> <boruch_baum@gmx.com> wrote:
> > > Shouldn't emacs ship with the default value of variable
> > > file-name-coding-system being equal to that of the default value
> of
> > > default-file-name-coding-system?
> > >
> > >                  file-name-coding-system  => nil
> > >   (default-value file-name-coding-system) => nil
> > >          default-file-name-coding-system  => utf-8-unix
> >
> > These are 2 separate variables, see the doc string of
> default-file-name-coding-system.  One is for the user to set, thus nil
> by default, the other is what Emacs thinks should be the OS default. 
> They are separate because Unix filesystems traditionally treat file
> names as byte streams, without imposing any encoding restrictions on
> them.
> 
> I'm proposing that even the one that's 'for the user to set' should
> have
> a sane default. I'm a user, and it never occurred to me I needed to
> set
> that variable (among all the other emacs variables begging a
> customization). What percentage of users do you think install emacs
> and
> on their own initiative say, "Of course, I now need to set
> file-name-coding-system". If so, maybe it should be part of the
> official
> emacs tutorial (sarcasm)?

I completely agree with the sane default requirement.  Which is why the default is nil, and why users are not required to set file-name-coding-system: nil does TRT.  You can see that every day in Emacs if you use non-ASCII file names, because Emacs encodes every file name it passes to the system APIs.

The original issue, btw, was not about what users should do, it was about what Lisp programs processing and interpreting file names should do: they should consult default-file-name-coding-system if the user variable is nil, as it usually is.