GNU bug report logs - #9735
win32 emacs cannot load doc string from files which has non-ascii characters in path

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9735 in the body.
You can then email your comments to 9735 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: sssslang <sssslang <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: win32 emacs cannot load doc string from files which has non-ascii
	characters in path
Date: Wed, 12 Oct 2011 20:09:52 +0800

[Message part 1 (text/plain, inline)]

Hello everyone. I found my emacs cannot start when I put it in a folder with a non-latin name under Windows XP. This can be reproduced by the following steps:

1. make path to emacs.exe contains some non-latin characters
2. execute: emacs.exe -Q
3. (require 'cl)

Then an error message will appear:

Debugger entered--Lisp error: (error "Cannot open doc string file \"c:/xxxxx/eamacs23/lisp/emacs-lisp/cl.elc\"")
 cl-random-time()

I use emacs-23.2 and codepage936 on my Windows box. And the "xxxxx" in the error message should be the non-latin characters but is something like "\301\226" now. Except "cl" and "calendar", other elisp sources seems can be loaded without problem. I don't know what makes the difference, but the error maybe caused by incorrect path encoding. The attached patch works on my machine, but it didn't have enough test. Hopes somebody could improve it.

[emacs_win32_pathenc.path (application/octet-stream, attachment)]

Message #8 received at 9735 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: sssslang <sssslang <at> gmail.com>
Cc: 9735 <at> debbugs.gnu.org
Subject: Re: bug#9735: win32 emacs cannot load doc string from files which has
	non-ascii characters in path
Date: Wed, 12 Oct 2011 12:28:13 -0400

sssslang wrote:

> Except "cl" and "calendar", other elisp sources seems can be loaded
> without problem.

The common factor here is probably that these are files that use
`byte-compile-dynamic: t'.

Message #11 received at 9735 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: sssslang <sssslang <at> gmail.com>
Cc: 9735 <at> debbugs.gnu.org
Subject: Re: bug#9735: win32 emacs cannot load doc string from files which
	has	non-ascii characters in path
Date: Wed, 12 Oct 2011 18:36:19 +0200

> From: sssslang <sssslang <at> gmail.com>
> Date: Wed, 12 Oct 2011 20:09:52 +0800
> 
> 1. make path to emacs.exe contains some non-latin characters
> 2. execute: emacs.exe -Q
> 3. (require 'cl)
> 
> Then an error message will appear:
> 
> Debugger entered--Lisp error: (error "Cannot open doc string file \"c:/xxxxx/eamacs23/lisp/emacs-lisp/cl.elc\"")
>  cl-random-time()
> 
> I use emacs-23.2 and codepage936 on my Windows box. And the "xxxxx" in the error message should be the non-latin characters but is something like "\301\226" now. Except "cl" and "calendar", other elisp sources seems can be loaded without problem. I don't know what makes the difference, but the error maybe caused by incorrect path encoding. The attached patch works on my machine, but it didn't have enough test. Hopes somebody could improve it.

Does it help to type

   C-x RET F cp936 RET

before you evaluate "(require 'cl)" ?

Message #16 received at 9735-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: sssslang <sssslang <at> gmail.com>
Cc: 9735-done <at> debbugs.gnu.org
Subject: Re: bug#9735: win32 emacs cannot load doc string from files which has
	non-ascii characters in path
Date: Wed, 12 Oct 2011 15:08:12 -0400

> I use emacs-23.2 and codepage936 on my Windows box. And the "xxxxx" in the
> error message should be the non-latin characters but is something like
> "\301\226" now. Except "cl" and "calendar", other elisp sources seems can be
> loaded without problem. I don't know what makes the difference, but the
> error maybe caused by incorrect path encoding. The attached patch works on
> my machine, but it didn't have enough test. Hopes somebody could improve it.

The patch is doing the right thing, thank you.  I installed
a slightly different one to call ENCODE_FILE fewer times.


        Stefan


> --- emacs-23.2/src/doc.c	2010-04-04 06:26:07.000000000 +0800
> +++ emacs-23.2/src/doc.c	2011-10-12 17:19:54.000000000 +0800
> @@ -142,17 +142,17 @@
>    tem = Ffile_name_absolute_p (file);
>    if (NILP (tem))
>      {
> -      minsize = SCHARS (Vdoc_directory);
> +      minsize = SCHARS (ENCODE_FILE (Vdoc_directory));
>        /* sizeof ("../etc/") == 8 */
>        if (minsize < 8)
>  	minsize = 8;
> -      name = (char *) alloca (minsize + SCHARS (file) + 8);
> -      strcpy (name, SDATA (Vdoc_directory));
> -      strcat (name, SDATA (file));
> +      name = (char *) alloca (minsize + SCHARS (ENCODE_FILE (file)) + 8);
> +      strcpy (name, SDATA (ENCODE_FILE (Vdoc_directory)));
> +      strcat (name, SDATA (ENCODE_FILE (file)));
>      }
>    else
>      {
> -      name = (char *) SDATA (file);
> +      name = (char *) SDATA (ENCODE_FILE(file));
>      }
 
>    fd = emacs_open (name, O_RDONLY, 0);
> @@ -164,7 +164,7 @@
>  	  /* Preparing to dump; DOC file is probably not installed.
>  	     So check in ../etc. */
>  	  strcpy (name, "../etc/");
> -	  strcat (name, SDATA (file));
> +	  strcat (name, SDATA (ENCODE_FILE (file)));
 
>  	  fd = emacs_open (name, O_RDONLY, 0);
>  	}

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.