GNU bug report logs - #15260
cannot build in a directory with non-ascii characters

Previous Next

Package: emacs;

Reported by: Glenn Morris <rgm <at> gnu.org>

Date: Tue, 3 Sep 2013 17:47:02 UTC

Severity: wishlist

Found in version 24.3

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #133 received at 15260 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rgm <at> gnu.org, 15260 <at> debbugs.gnu.org, handa <at> gnu.org
Subject: Re: bug#15260: cannot build in a directory with non-ascii characters
Date: Thu, 31 Oct 2013 21:33:22 +0200
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Glenn Morris <rgm <at> gnu.org>,  15260 <at> debbugs.gnu.org,  Kenichi Handa <handa <at> gnu.org>
> Date: Thu, 31 Oct 2013 15:24:57 -0400
> 
> > Below is what I came up with.  This survived several bootstraps, both
> 
> Thanks, Eli.
> 
> > +;; 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.




This bug report was last modified 11 years and 202 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.