>>>>> 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
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
