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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: sssslang <sssslang <at> gmail.com>
Subject: bug#9735: closed (Re: bug#9735: win32 emacs cannot load doc
 string from files which has non-ascii characters in path)
Date: Wed, 12 Oct 2011 19:09:02 +0000

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

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 9735 <at> debbugs.gnu.org.

-- 
9735: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9735
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

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

[Message part 3 (message/rfc822, inline)]

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 4 (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)]

Previous Next

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