GNU bug report logs -
#15260
cannot build in a directory with non-ascii characters
Previous Next
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
View this message in rfc822 format
> Date: Thu, 31 Oct 2013 21:33:22 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15260 <at> debbugs.gnu.org
>
> > > +;; 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?
This bug report was last modified 11 years and 201 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.