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