filename coding systems and w32-*-file-name functions

filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

Is this to be expected (I don't think so) or should I file a bug report?

ELISP> temporary-file-directory
"c:/DOCUME~1/Juanma/CONFIG~1/Temp/"

ELISP> (w32-long-file-name temporary-file-directory)
"c:/Documents and Settings/Juanma/Configuraci\363n local/Temp/"

ELISP> (decode-coding-string (w32-long-file-name
temporary-file-directory) file-name-coding-system)
#("c:/Documents and Settings/Juanma/Configuración local/Temp/" 0 58
  (charset windows-1252))                 ;;; this one is the correct name

ELISP> (let ((dir (read-directory-name "Dir: ")))    ;;; c:/acción
         (list dir
               (w32-short-file-name dir)
               (w32-long-file-name dir)))
("c:/acción/" nil nil)

ELISP> (let ((dir (read-directory-name "Dir: ")))    ;;; c:/accion
         (list dir
               (w32-short-file-name dir)
               (w32-long-file-name dir)))
("c:/accion/" "c:/accion/" "c:/accion/")

So it seems like w32-(long|short)-file-name have issues with coding
systems and should use (default-)file-name-coding-system.

             Juanma

Re: filename coding systems and w32-*-file-name functions

[martin rudalics]

 > So it seems like w32-(long|short)-file-name have issues with coding
 > systems and should use (default-)file-name-coding-system.

Isn't this bug#38 in Castilian disguise?

martin

Re: filename coding systems and w32-*-file-name functions

[Jason Rumney]

martin rudalics wrote:
> > So it seems like w32-(long|short)-file-name have issues with coding
> > systems and should use (default-)file-name-coding-system.
>
> Isn't this bug#38 in Castilian disguise?

Not quite. Bug #38 only surfaces when using environment variables in 
filenames.

Re: filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

On Thu, Nov 27, 2008 at 15:24, Jason Rumney <jasonr@f2s.com> wrote:

> Not quite. Bug #38 only surfaces when using environment variables in
> filenames.

Not only that, but #38 happens on GNU/Linux (the OP is using RedHat),
while this bug is specifically related to two w32 functions calling
Windows APIs without encoding the filenames.

What do we do about it? Is my "fix" (see bug report below) on the right track?

http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1433

  Juanma

Re: filename coding systems and w32-*-file-name functions

[Jason Rumney]

Juanma Barranquero wrote:
> What do we do about it? Is my "fix" (see bug report below) on the right track?
>   

I think so.

Re: filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

On Thu, Nov 27, 2008 at 15:59, Jason Rumney <jasonr@f2s.com> wrote:

> I think so.

OK. Then, it is the convoluted

  filename = DECODE_FILE (build_string (longname));
  return build_string (SDATA (filename));

needed, or would it suffice

  return build_string (DECODE_FILE (longname));

even if it makes the function return

  #("c:/acción/" 0 10
      (charset windows-1252))

instead of just "c:/acción/"?

  Juanma

Re: filename coding systems and w32-*-file-name functions

[Eli Zaretskii]

> Date: Thu, 27 Nov 2008 16:03:10 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: martin rudalics <rudalics@gmx.at>, Emacs Devel <emacs-devel@gnu.org>
> 
>   return build_string (DECODE_FILE (longname));

This cannot be right, since DECODE_FILE produces a Lisp_Object,
whereas build_string takes a "char *" argument.  That's why you need
SDATA.

Re: filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

On Thu, Nov 27, 2008 at 20:53, Eli Zaretskii <eliz@gnu.org> wrote:

> This cannot be right, since DECODE_FILE produces a Lisp_Object,
> whereas build_string takes a "char *" argument.  That's why you need
> SDATA.

A transcription error; in the patch I have the SDATA.

But still I don't know why I do need  build_string (SDATA (DECODE_FILE
(build_string (longname))));

  Juanma

Re: filename coding systems and w32-*-file-name functions

[Eli Zaretskii]

> Date: Thu, 27 Nov 2008 21:24:21 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: jasonr@f2s.com, rudalics@gmx.at, emacs-devel@gnu.org
> 
> But still I don't know why I do need  build_string (SDATA (DECODE_FILE
> (build_string (longname))));

Sorry, I don't understand what you don't know; could you please
elaborate?

Re: filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

On Thu, Nov 27, 2008 at 21:40, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 27 Nov 2008 21:24:21 +0100
>> From: "Juanma Barranquero" <lekktu@gmail.com>
>> Cc: jasonr@f2s.com, rudalics@gmx.at, emacs-devel@gnu.org
>>
>> But still I don't know why I do need  build_string (SDATA (DECODE_FILE
>> (build_string (longname))));
>
> Sorry, I don't understand what you don't know; could you please
> elaborate?

As I explained in a previous message, I though that

   return DECODE_FILE (build_string (longname));

should suffice, but then w32-long-file-name returns

   #("c:/acción/" 0 10
     (charset windows-1252))

instead of just "c:/acción".

  Juanma

Re: filename coding systems and w32-*-file-name functions

[Eli Zaretskii]

> Date: Thu, 27 Nov 2008 23:16:14 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: jasonr@f2s.com, rudalics@gmx.at, emacs-devel@gnu.org
> 
> As I explained in a previous message, I though that
> 
>    return DECODE_FILE (build_string (longname));
> 
> should suffice, but then w32-long-file-name returns
> 
>    #("c:/acción/" 0 10
>      (charset windows-1252))

I don't see anything wrong with this return value.  So I think you can
use it without any trouble.

Re: filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

On Fri, Nov 28, 2008 at 09:36, Eli Zaretskii <eliz@gnu.org> wrote:

> I don't see anything wrong with this return value.  So I think you can
> use it without any trouble.

I've committed that fix.

And, in a related note: some time ago, I changed `w32-list-locales'
(from w32-fns.el) to decode the output of `w32-get-locale-info'. But,
in fact, I don't think that should be done at the lisp level; there's
no reason why `w32-get-locale-info' shouldn't use DECODE_SYSTEM for
the long form of the locale name.

As for using DECODE_SYSTEM when the LONGFORM argument is a LCTYPE
constant, I'm not sure. On one hand, I don't think that

  ELISP> (w32-get-locale-info (w32-get-current-locale-id) 2)
  "Espa\361ol - Espa\361a (alfabetizaci\363n tradicional)^@"

is very useful. On the other hand, the LCTYPE results are
null-terminated strings so I don't know what it the intended use.

Comments?

TIA,

   Juanma

Re: filename coding systems and w32-*-file-name functions

[Juanma Barranquero]

On Sun, Nov 30, 2008 at 03:08, Juanma Barranquero <lekktu@gmail.com> wrote:

> And, in a related note: some time ago, I changed `w32-list-locales'
> (from w32-fns.el) to decode the output of `w32-get-locale-info'. But,
> in fact, I don't think that should be done at the lisp level; there's
> no reason why `w32-get-locale-info' shouldn't use DECODE_SYSTEM for
> the long form of the locale name.

No answer, so I'll change w32-get-locale-info to use DECODE_SYSTEM for
the long form of the locale name, unless somebody opposes.

> As for using DECODE_SYSTEM when the LONGFORM argument is a LCTYPE
> constant, I'm not sure. On one hand, I don't think that
>
>  ELISP> (w32-get-locale-info (w32-get-current-locale-id) 2)
>  "Espa\361ol - Espa\361a (alfabetizaci\363n tradicional)^@"
>
> is very useful. On the other hand, the LCTYPE results are
> null-terminated strings so I don't know what it the intended use.

What about that? Makes sense to use DECODE_SYSTEM for the LCTYPE results?

TIA,

    Juanma