> 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 consist
> 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
ema
> 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
>> 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 s
> 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
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 require
> + /* 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
> !
> 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 Ema
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
> 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 loade
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
11 matches
Mail list logo
