[PATCH] Pay more attention to the the locale's coding systems on startup

[Aidan Kehoe]

 Ar an triú lá déag de mí na Samhain, scríobh stephen at xemacs.org: 

 >  > Hilarity ensues as-is. When I start up in "/tmp/aidan/за родину!" , I
 >  > can’t open the current directory, even though my init files set the
 >  > file name coding systems appropriately,
 > 
 > Then there's a bug somewhere, isn't there?  

If ‘the startup code trusts the locale-sniffing code’ can be ruled a bug,
sure. The issue is this, from emacs.c:

#ifdef MULE
  init_intl (); /* Figure out the locale and set native and
		   file-name coding systems, initialize the Unicode tables
		   so that we will be able to process non-ASCII from here
		   on out! */
#endif

  init_xemacs_process (); /* Set up the process environment (so that
			     egetenv works), the basic directory variables
			     (exec-directory and so on), and stuff related
			     to subprocesses.  This should be first because
			     many of the functions below call egetenv() to
			     get environment variables. */

#ifdef WIN32_NATIVE
  /*
   * For Win32, call init_environment() to properly enter environment/registry
   * variables into Vprocess_environment.
   */
  init_mswindows_environment ();
#endif

  init_initial_directory ();		/* get the directory to use for the
					   "*scratch*" buffer, etc. */

The init_initial_directory() call uses the value for Qnative determined in
init_intl(). On Unix, in general, there is no better indicator of the coding
system of file names than the charset info in the user-specific locale--it
would be better if there were some means to query the file name charset
specifically, and that’s what we should do for OS X, but in the absence of
that,  we need to check the locale. 

-- 
Santa Maradona, priez pour moi!