[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15260: cannot build in a directory with non-ascii characters
From: |
Eli Zaretskii |
Subject: |
bug#15260: cannot build in a directory with non-ascii characters |
Date: |
Thu, 31 Oct 2013 21:33:22 +0200 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>, 15260@debbugs.gnu.org, Kenichi Handa
> <handa@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.
- bug#15260: cannot build in a directory with non-ascii characters, (continued)
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/28
- bug#15260: cannot build in a directory with non-ascii characters, Stefan Monnier, 2013/10/29
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/30
- bug#15260: cannot build in a directory with non-ascii characters, Stefan Monnier, 2013/10/30
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/30
- bug#15260: cannot build in a directory with non-ascii characters, Stefan Monnier, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Stefan Monnier, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Stefan Monnier, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters,
Eli Zaretskii <=
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Stefan Monnier, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Eli Zaretskii, 2013/10/31
- bug#15260: cannot build in a directory with non-ascii characters, Glenn Morris, 2013/10/31