bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Sat, 26 Oct 2013 10:50:06 +0300

> Date: Fri, 25 Oct 2013 22:27:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 15260@debbugs.gnu.org
> 
> > Date: Fri, 25 Oct 2013 21:46:52 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 15260@debbugs.gnu.org
> > 
> > > but there are still
> > > problems later on, again related to Emacs mistakenly believing that
> > > certain directories do not exist, when they do (Warning: arch-dependent
> > > data dir `...' No such file or directory; etc).
> > > 
> > > The "non-ascii srcdir == builddir" case fails even earlier, due to not
> > > finding etc.
> > 
> > OK, I will take a closer look.  Thanks for the info.
> 
> I think I see the problem.  All those PATH_* variables that come from
> epaths.h yield encoded file names (because they were written by the
> shell).  But we never decode them before using them in init_callproc
> and init_callproc_1.  Similar things happen with decode_env_path: it
> calls 'getenv', but never decodes the values it gets from that.
> 
> I will take a crack on fixing these.

We definitely need to decode file names in init_callproc_1,
init_callproc, and init_lread.

But here's where things get hairy: when temacs starts, preloaded Lisp
files are not yet loaded, and consequently file-name-coding-system and
default-file-name-coding-system are both nil.  In such a case,
currently DECODE_FILE is a no-op.

So we need some way of getting temacs to know what coding-system to
use to decode file names during its initialization phase, without
relying on the database we have in locale-language-names.  This
probably calls for a separate variable, init-file-name-coding-system,
say.  But how to assign a correct value to it?

I understand that most Posix systems nowadays use UTF-8 for file
names, so I guess we can fall back on that.  On MS-Windows, there's a
system call that returns the necessary information, so there's no
problem for MS-Windows.  The question is what to do for Posix systems
that don't use UTF-8?  I see 2 possibilities:

 . Try to parse the value of LANG with some shell or Sed script, and
   come up with a suitable value.

 . Ask the user to specify the encoding as a switch to the configure
   script.

In both cases, communicate the value to temacs via --eval on its
command line.

Comments and opinions are welcome.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]