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

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

[sssslang]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

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.


[-- Attachment #2: emacs_win32_pathenc.path --]
[-- Type: application/octet-stream, Size: 1138 bytes --]

--- 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);
 	}

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

[Glenn Morris]

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'.

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

[Eli Zaretskii]

> From: sssslang <sssslang@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)" ?

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

[Stefan Monnier]

> 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);
>  	}