Re: Carbon Emacs won't start when installed in certain paths

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 08 May 2007 03:07:12 -0400, Stefan Monnier <address@hidden> 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
                                address@hidden