Re: Carbon Emacs won't start when installed in certain paths
On Wed, 09 May 2007 17:36:37 +0900, YAMAMOTO Mitsuharu [EMAIL
PROTECTED] said:
Though the non-ASCII unibyte `default-directory' case seems to be
sufficient for the originally reported problem, we should also handle
the following cases in order to make Fexpand_file_name consistent and
exhaustive with respect to non-ASCII unibyte file names:
1. Case that ~ or ~user is expanded to a non-ASCII file name:
This case is similar to the non-ASCII unibyte `default-directory'
case.
2. Case that the argument `name' is in non-ASCII unibyte and
`default-directory' is in multibyte:
This case may return a wrong result either with or without my
previous patch.
I tried handling these cases (with DECODE_FILE instead of
string_to_multibyte). What's pointed to by `newdir' previously is now
stored in a Lisp string `new_directory' until adjustments of
multibyteness has been completed.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/fileio.c
===
RCS file: /cvsroot/emacs/emacs/src/fileio.c,v
retrieving revision 1.580
diff -c -p -r1.580 fileio.c
*** src/fileio.c22 Mar 2007 12:15:04 - 1.580
--- src/fileio.c10 May 2007 09:09:53 -
*** See also the function `substitute-in-fil
*** 1060,1067
int collapse_newdir = 1;
int is_escaped = 0;
#endif /* DOS_NT */
! int length;
! Lisp_Object handler, result;
int multibyte;
CHECK_STRING (name);
--- 1060,1066
int collapse_newdir = 1;
int is_escaped = 0;
#endif /* DOS_NT */
! Lisp_Object handler, new_directory, result;
int multibyte;
CHECK_STRING (name);
*** See also the function `substitute-in-fil
*** 1345,1351
default_directory if nm is not absolute, and finally collapse /./
and /foo/../ sequences.
! We set newdir to be the appropriate prefix if one is needed:
- the relevant user directory if nm starts with ~ or ~user
- the specified drive's working dir (DOS/NT only) if nm does not
start with /
--- 1344,1350
default_directory if nm is not absolute, and finally collapse /./
and /foo/../ sequences.
! We set new_directory to be the appropriate prefix if one is needed:
- the relevant user directory if nm starts with ~ or ~user
- the specified drive's working dir (DOS/NT only) if nm does not
start with /
*** See also the function `substitute-in-fil
*** 1356,1362
return an absolute name, if the final prefix is not absolute we
append it to the current working directory. */
! newdir = 0;
if (nm[0] == '~') /* prefix ~ */
{
--- 1355,1361
return an absolute name, if the final prefix is not absolute we
append it to the current working directory. */
! new_directory = Qnil;
if (nm[0] == '~') /* prefix ~ */
{
*** See also the function `substitute-in-fil
*** 1366,1373
#endif /* VMS */
|| nm[1] == 0)/* ~ by itself */
{
! if (!(newdir = (unsigned char *) egetenv (HOME)))
! newdir = (unsigned char *) ;
nm++;
#ifdef DOS_NT
collapse_newdir = 0;
--- 1365,1376
#endif /* VMS */
|| nm[1] == 0)/* ~ by itself */
{
! unsigned char *homedir = (unsigned char *) egetenv (HOME);
!
! if (homedir)
! new_directory = make_unibyte_string (homedir, strlen (homedir));
! else
! new_directory = empty_string;
nm++;
#ifdef DOS_NT
collapse_newdir = 0;
*** See also the function `substitute-in-fil
*** 1392,1398
UNBLOCK_INPUT;
if (pw)
{
! newdir = (unsigned char *) pw - pw_dir;
#ifdef VMS
nm = p + 1; /* skip the terminator */
#else
--- 1395,1403
UNBLOCK_INPUT;
if (pw)
{
! unsigned char *homedir = (unsigned char *) pw - pw_dir;
!
! new_directory = make_unibyte_string (homedir, strlen (homedir));
#ifdef VMS
nm = p + 1; /* skip the terminator */
#else
*** See also the function `substitute-in-fil
*** 1411,1433
#ifdef DOS_NT
/* On DOS and Windows, nm is absolute if a drive name was specified;
use the drive's current directory as the prefix if needed. */
! if (!newdir drive)
{
/* Get default directory if needed to make nm absolute. */
if (!IS_DIRECTORY_SEP (nm[0]))
{
! newdir = alloca (MAXPATHLEN + 1);
! if (!getdefdir (toupper (drive) - 'A' + 1, newdir))
! newdir = NULL;
}
! if (!newdir)
{
/* Either nm starts with /, or drive isn't mounted. */
! newdir = alloca (4);
Re: Carbon Emacs won't start when installed in certain paths
On Tue, 08 May 2007 03:07:12 -0400, Stefan Monnier [EMAIL PROTECTED] said: If we allow non-ASCII unibyte strings for file names, maybe we need to change ENCODE_FILE and Fexpand_file_name as below, and rule out the use of concat in favor of expand-file-name to avoid implicit string-make-multibyte for non-ASCII bytes. I think it would make a lot of sense. Except I'd stay clear of string_to_multibyte and use DECODE_FILE instead. Then we have to be careful about the place to use DECODE_FILE, because it may cause GC, and the comment around the recursive call of Fexpand_file_name also applies to this situation. Though the non-ASCII unibyte `default-directory' case seems to be sufficient for the originally reported problem, we should also handle the following cases in order to make Fexpand_file_name consistent and exhaustive with respect to non-ASCII unibyte file names: 1. Case that ~ or ~user is expanded to a non-ASCII file name: This case is similar to the non-ASCII unibyte `default-directory' case. 2. Case that the argument `name' is in non-ASCII unibyte and `default-directory' is in multibyte: This case may return a wrong result either with or without my previous patch. By the way, I noticed that current_buffer-directory mentioned above is decoded with local-coding-system in command-line (startup.el) after coding systems are ready. Why not (default-)file-name-coding-system? Probably an oversight. Handa-san, could you comment on this? YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
Then we have to be careful about the place to use DECODE_FILE, because it may cause GC, and the comment around the recursive call of Fexpand_file_name also applies to this situation. Indeed. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
Why not just keep it in unibyte form? Because the current ENCODE_FILE seems to assume that file name strings are in multibyte or ASCII-only unibyte. Also, the initialization of current_buffer-directory in init_buffer (buffer.c) does the same thing. If we allow non-ASCII unibyte strings for file names, maybe we need to change ENCODE_FILE and Fexpand_file_name as below, and rule out the use of concat in favor of expand-file-name to avoid implicit string-make-multibyte for non-ASCII bytes. I think it would make a lot of sense. Except I'd stay clear of string_to_multibyte and use DECODE_FILE instead. By the way, I noticed that current_buffer-directory mentioned above is decoded with local-coding-system in command-line (startup.el) after coding systems are ready. Why not (default-)file-name-coding-system? Probably an oversight. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
+ /* 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. */ Vdata_directory ! = Ffile_name_as_directory (string_to_multibyte !(make_unibyte_string (data_dir, ! strlen (data_dir; Vdoc_directory ! = Ffile_name_as_directory (string_to_multibyte !(make_unibyte_string (doc_dir, ! strlen (doc_dir; Why not just keep it in unibyte form? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On 10 Apr 2007, at 03:59, YAMAMOTO Mitsuharu wrote: I think he is using Carbon Emacs with self-contained setting which puts subdirectories for runtime (lisp, etc, libexec, ...) below the Emacs.app directory so as to make the application bundle relocatable. Yes, that's correct. That requires some changes here and there. Though I just tried that, it may not be exhaustive and I'm not sure if it is safe to use ENCODE_FILE in init_callproc. Also, this kind of changes may not be appropriate at this stage. I tried your patch and unfortunately, it does not fix the startup problem. Error messages are the same. The good news is that I can start up an Emacs with -Q and -nw (as before, complaining about encoded-kb), but then, `load-file' works with a file that resides inside the offending path, which it didn't before. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On Tue, 10 Apr 2007 10:36:08 -0400, Stefan Monnier [EMAIL PROTECTED] said: + /* 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. */ Vdata_directory ! = Ffile_name_as_directory (string_to_multibyte ! (make_unibyte_string (data_dir, ! strlen (data_dir; Vdoc_directory ! = Ffile_name_as_directory (string_to_multibyte ! (make_unibyte_string (doc_dir, ! strlen (doc_dir; Why not just keep it in unibyte form? Because the current ENCODE_FILE seems to assume that file name strings are in multibyte or ASCII-only unibyte. Also, the initialization of current_buffer-directory in init_buffer (buffer.c) does the same thing. If we allow non-ASCII unibyte strings for file names, maybe we need to change ENCODE_FILE and Fexpand_file_name as below, and rule out the use of concat in favor of expand-file-name to avoid implicit string-make-multibyte for non-ASCII bytes. By the way, I noticed that current_buffer-directory mentioned above is decoded with local-coding-system in command-line (startup.el) after coding systems are ready. Why not (default-)file-name-coding-system? ;; Decode all default-directory. (if (and default-enable-multibyte-characters locale-coding-system) (save-excursion (dolist (elt (buffer-list)) (set-buffer elt) (if default-directory (setq default-directory (decode-coding-string default-directory locale-coding-system t (setq command-line-default-directory (decode-coding-string command-line-default-directory locale-coding-system t YAMAMOTO Mitsuharu [EMAIL PROTECTED] Index: src/buffer.c === RCS file: /cvsroot/emacs/emacs/src/buffer.c,v retrieving revision 1.525 diff -c -p -r1.525 buffer.c *** src/buffer.c29 Mar 2007 15:58:34 - 1.525 --- src/buffer.c11 Apr 2007 00:54:42 - *** init_buffer () *** 5211,5222 #endif /* not VMS */ current_buffer-directory = make_unibyte_string (pwd, strlen (pwd)); - if (! NILP (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. */ - current_buffer-directory - = string_to_multibyte (current_buffer-directory); /* Add /: to the front of the name if it would otherwise be treated as magic. */ --- 5211,5216 Index: src/callproc.c === RCS file: /cvsroot/emacs/emacs/src/callproc.c,v retrieving revision 1.221 diff -c -p -r1.221 callproc.c *** src/callproc.c 17 Feb 2007 01:59:00 - 1.221 --- src/callproc.c 11 Apr 2007 00:54:42 - *** init_callproc_1 () *** 1522,1533 char *data_dir = egetenv (EMACSDATA); char *doc_dir = egetenv (EMACSDOC); Vdata_directory ! = Ffile_name_as_directory (build_string (data_dir ? data_dir !: PATH_DATA)); Vdoc_directory ! = Ffile_name_as_directory (build_string (doc_dir ? doc_dir !: PATH_DOC)); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ --- 1522,1536 char *data_dir = egetenv (EMACSDATA); char *doc_dir = egetenv (EMACSDOC); + if (!data_dir) data_dir = PATH_DATA; + if (!doc_dir) doc_dir = PATH_DOC; + Vdata_directory ! = Ffile_name_as_directory (make_unibyte_string (data_dir, ! strlen (data_dir))); Vdoc_directory ! = Ffile_name_as_directory (make_unibyte_string (doc_dir, ! strlen (doc_dir))); /* Check the EMACSPATH environment variable, defaulting to the PATH_EXEC path from epaths.h. */ Index: src/coding.h === RCS file: /cvsroot/emacs/emacs/src/coding.h,v retrieving revision 1.83 diff -c -p -r1.83 coding.h *** src/coding.h21 Jan 2007 20:49:26 - 1.83 --- src/coding.h11 Apr 2007 00:54:42 - *** struct coding_system *** 580,592 /* Encode the file name NAME using the specified coding system for file names, if any. */ #define ENCODE_FILE(name)\ ! (! NILP (Vfile_name_coding_system)
Carbon Emacs won't start when installed in certain paths
Emacs (recent CVS build, Carbon) will not start when installed in directories with certain file names. For example when I install the .app bundle in /Applications/Pour Développement, it refuses to run. When started from a terminal, the error messages I'm getting are lucy:/Applications/Pour DeÌveloppement dr$ Aquamacs\ Emacs\ Yesterday.app/Contents/MacOS/Aqu* Warning: arch-dependent data dir (/usr/local/libexec/emacs/22.0.96/ powerpc-apple-darwin7.9.0/) does not exist. Warning: arch-independent data dir (/usr/local/share/emacs/22.0.96/ etc/) does not exist. Cannot open load file: term/mac-win (Not that the first two warnings are normal.) This error obviously occurs before loading any user-specific settings, so I'm not sending the Emacs debug log. N.B.: This build is compiled on OS X 10.3.9. I am testing on 10.4.9 (PPC). The filesystem is the normal Mac filesystem (Mac OS Extended, Journaled). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
Cannot open load file: term/mac-win [...] This error obviously occurs before loading any user-specific settings, so I'm not sending the Emacs debug log. Actually, this is not obvious at all to me. AFAIK the term-specific setup file (such as term/xterm or term/x-win or term/mac-win) is loaded at the very end, after site-start, .emacs, and default.el were loaded. So try it with -Q. This said, I wouldn't be surprised if building (and/or installing) doesn't work correctly in a directory whose complete filename contains spaces and/or non-ascii letters. Among other things, I seem to remember a problem where some hardcoded file names are created at dump time before the utf-8 coding system exists, so when they get used later on, they may suffer some problems. Please try and diagnosticate as much as you can, and we'll then add a note about it in PROBLEMS (at least, if that's the problem I'm thinking of, the solution is not immediate). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On 9 Apr 2007, at 20:35, Stefan Monnier wrote: So try it with -Q. OK, same story, see below. This said, I wouldn't be surprised if building (and/or installing) doesn't work correctly in a directory whose complete filename contains spaces and/or non-ascii letters. Spaces are definitely fine. Among other things, I seem to remember a problem where some hardcoded file names are created at dump time before the utf-8 coding system exists, so when they get used later on, they may suffer some problems. Please try and diagnosticate as much as you can, and we'll then add a note about it in PROBLEMS (at least, if that's the problem I'm thinking of, the solution is not immediate). When started with -nw, loading of encoded-kb fails, yet Emacs starts up. It is marginally usable - files can be opened (find-file) just fine from the path with the non-ASCII characters. However, calling load-file manually won't work (with one of those paths). In a successfully started Emacs (-Q), files from the special path can be opened (find-file) and sourced (load-file) perfectly, even though the *Completions* buffer and the entry in *Messages* will not display the right characters. I've tried this with a directory named Täst, which shows up in Emacs as in the attached screenshot. lucy:/Applications dr$ mv Emacs.app Pour\ De\314\201veloppement/ lucy:/Applications dr$ cd Pour\ De\314\201veloppement/ lucy:/Applications/Pour DeÌveloppement dr$ ls Aquamacs Emacs Yesterday.app Emacs.app lucy:/Applications/Pour DeÌveloppement dr$ open Emacs.app/ lucy:/Applications/Pour DeÌveloppement dr$ Emacs.app/Contents/MacOS/ Emacs -Q Warning: arch-dependent data dir (/usr/local/libexec/emacs/22.0.96/ powerpc-apple-darwin7.9.0/) does not exist. Warning: arch-independent data dir (/usr/local/share/emacs/22.0.96/ etc/) does not exist. Cannot open load file: term/mac-win Start with -nw: (Emacs.app/Contents/MacOS/Emacs -debug-init) set-keyboard-coding-system: Cannot open load file: encoded-kb ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Carbon Emacs won't start when installed in certain paths
On Mon, 09 Apr 2007 15:35:26 -0400, Stefan Monnier [EMAIL PROTECTED]
said:
This said, I wouldn't be surprised if building (and/or installing)
doesn't work correctly in a directory whose complete filename
contains spaces and/or non-ascii letters.
I think he is using Carbon Emacs with self-contained setting which
puts subdirectories for runtime (lisp, etc, libexec, ...) below the
Emacs.app directory so as to make the application bundle relocatable.
I'm not familiar with the self-contained setting at all (it is
designed and coded by Steven Tamm, IIUC). But I think that at least
we need to handle non-ASCII environment variables (encoded with
file-name-coding-system, not emacs-mule) such as EMACSLOADPATH in
order to deal with the case that Emacs.app is located at a non-ASCII
directory.
That requires some changes here and there. Though I just tried that,
it may not be exhaustive and I'm not sure if it is safe to use
ENCODE_FILE in init_callproc. Also, this kind of changes may not be
appropriate at this stage.
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
Index: src/callproc.c
===
RCS file: /cvsroot/emacs/emacs/src/callproc.c,v
retrieving revision 1.221
diff -c -p -r1.221 callproc.c
*** src/callproc.c 17 Feb 2007 01:59:00 - 1.221
--- src/callproc.c 10 Apr 2007 02:29:20 -
*** init_callproc_1 ()
*** 1522,1533
char *data_dir = egetenv (EMACSDATA);
char *doc_dir = egetenv (EMACSDOC);
Vdata_directory
! = Ffile_name_as_directory (build_string (data_dir ? data_dir
!: PATH_DATA));
Vdoc_directory
! = Ffile_name_as_directory (build_string (doc_dir ? doc_dir
!: PATH_DOC));
/* Check the EMACSPATH environment variable, defaulting to the
PATH_EXEC path from epaths.h. */
--- 1522,1541
char *data_dir = egetenv (EMACSDATA);
char *doc_dir = egetenv (EMACSDOC);
+ if (!data_dir) data_dir = PATH_DATA;
+ if (!doc_dir) doc_dir = PATH_DOC;
+
+ /* 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. */
Vdata_directory
! = Ffile_name_as_directory (string_to_multibyte
! (make_unibyte_string (data_dir,
!strlen (data_dir;
Vdoc_directory
! = Ffile_name_as_directory (string_to_multibyte
! (make_unibyte_string (doc_dir,
!strlen (doc_dir;
/* Check the EMACSPATH environment variable, defaulting to the
PATH_EXEC path from epaths.h. */
*** init_callproc ()
*** 1605,1617
#endif
{
tempdir = Fdirectory_file_name (Vexec_directory);
! if (access (SDATA (tempdir), 0) 0)
dir_warning (Warning: arch-dependent data dir (%s) does not exist.\n,
Vexec_directory);
}
tempdir = Fdirectory_file_name (Vdata_directory);
! if (access (SDATA (tempdir), 0) 0)
dir_warning (Warning: arch-independent data dir (%s) does not exist.\n,
Vdata_directory);
--- 1613,1625
#endif
{
tempdir = Fdirectory_file_name (Vexec_directory);
! if (access (SDATA (ENCODE_FILE (tempdir)), 0) 0)
dir_warning (Warning: arch-dependent data dir (%s) does not exist.\n,
Vexec_directory);
}
tempdir = Fdirectory_file_name (Vdata_directory);
! if (access (SDATA (ENCODE_FILE (tempdir)), 0) 0)
dir_warning (Warning: arch-independent data dir (%s) does not exist.\n,
Vdata_directory);
Index: src/emacs.c
===
RCS file: /cvsroot/emacs/emacs/src/emacs.c,v
retrieving revision 1.401
diff -c -p -r1.401 emacs.c
*** src/emacs.c 3 Apr 2007 15:25:28 - 1.401
--- src/emacs.c 10 Apr 2007 02:29:20 -
*** decode_env_path (evarname, defalt)
*** 2379,2385
{
p = index (path, SEPCHAR);
if (!p) p = path + strlen (path);
! element = (p - path ? make_string (path, p - path)
: build_string (.));
/* Add /: to the front of the name
--- 2379,2389
{
p = index (path, SEPCHAR);
if (!p) p = path + strlen (path);
! /* 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. */
! element = (p - path
!? string_to_multibyte (make_unibyte_string (path, p - path))
: build_string (.));
/* Add /: to the front of the name
Index: src/lread.c
