Subject: bug#15260: cannot build in a directory with non-ascii characters

From: Eli Zaretskii <[email-masked]>
Date: Fri, 01 Nov 2013 11:27:36 +0200

> Date: Thu, 31 Oct 2013 21:33:22 +0200
> From: Eli Zaretskii <[email-masked]>
> Cc: [email-masked]
> 
> > > +;; Make sure default-directory is unibyte when dumping.  This is
> > > +;; because we cannot decode and encode it correctly (since the locale
> > > +;; environment is not, and should not be, set up).  default-directory
> > > +;; is used every time we call expand-file-name, which we do in every
> > > +;; file primitive.  So the only workable solution to support building
> > > +;; in non-ASCII directories is to manipulate unibyte strings in the
> > > +;; current locale's encoding.
> > > +(if (and (or (equal (nth 3 command-line-args) "dump")
> > > +	     (equal (nth 4 command-line-args) "dump")
> > > +	     (equal (nth 3 command-line-args) "bootstrap")
> > > +	     (equal (nth 4 command-line-args) "bootstrap"))
> > > +	 (multibyte-string-p default-directory))
> > > +    (setq default-directory (string-to-unibyte default-directory)))
> > 
> > I'm not sure I understand this string-to-unibyte.
> > This call seems to only be correct if default-directory holds the
> > undecoded but multibyte name.
> > Why would we have an undecided yet multibyte name?
> 
> This was a necessity before I removed this quirk from init_buffer:
> 
> --- src/buffer.c	2013-10-29 14:46:23 +0000
> +++ src/buffer.c	2013-10-31 16:57:18 +0000
> @@ -5349,13 +5349,10 @@ init_buffer (void)
>        len++;
>      }
>  
> +  /* At this moment, we still don't know how to decode the directory
> +     name.  So, we keep the bytes in unibyte form so that file I/O
> +     routines correctly get the original bytes.  */
>    bset_directory (current_buffer, make_unibyte_string (pwd, len));
> -  if (! NILP (BVAR (&buffer_defaults, enable_multibyte_characters)))
> -    /* At this moment, we still don't know how to decode the
> -       directory name.  So, we keep the bytes in multibyte form so
> -       that ENCODE_FILE correctly gets the original bytes.  */
> -    bset_directory
> -      (current_buffer, string_to_multibyte (BVAR (current_buffer, directory)));
>  
>    /* Add /: to the front of the name
>       if it would otherwise be treated as magic.  */
> 
> After removing that, it's probably not needed anymore, since now
> default-directory should be a unibyte string from the very beginning.

Would you prefer that we error out of default-directory is not a
unibyte string at that point in loadup.el?