* filename coding systems and w32-*-file-name functions
@ 2008-11-25 1:38 Juanma Barranquero
2008-11-27 13:41 ` martin rudalics
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2008-11-25 1:38 UTC (permalink / raw
To: Emacs Devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-25 1:38 filename coding systems and w32-*-file-name functions Juanma Barranquero
@ 2008-11-27 13:41 ` martin rudalics
2008-11-27 14:24 ` Jason Rumney
0 siblings, 1 reply; 13+ messages in thread
From: martin rudalics @ 2008-11-27 13:41 UTC (permalink / raw
To: Juanma Barranquero; +Cc: Emacs Devel
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 13:41 ` martin rudalics
@ 2008-11-27 14:24 ` Jason Rumney
2008-11-27 14:46 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Jason Rumney @ 2008-11-27 14:24 UTC (permalink / raw
To: martin rudalics; +Cc: Juanma Barranquero, Emacs Devel
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 14:24 ` Jason Rumney
@ 2008-11-27 14:46 ` Juanma Barranquero
2008-11-27 14:59 ` Jason Rumney
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2008-11-27 14:46 UTC (permalink / raw
To: Jason Rumney; +Cc: martin rudalics, Emacs Devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 14:46 ` Juanma Barranquero
@ 2008-11-27 14:59 ` Jason Rumney
2008-11-27 15:03 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Jason Rumney @ 2008-11-27 14:59 UTC (permalink / raw
To: Juanma Barranquero; +Cc: martin rudalics, Emacs Devel
Juanma Barranquero wrote:
> What do we do about it? Is my "fix" (see bug report below) on the right track?
>
I think so.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 14:59 ` Jason Rumney
@ 2008-11-27 15:03 ` Juanma Barranquero
2008-11-27 19:53 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2008-11-27 15:03 UTC (permalink / raw
To: Jason Rumney; +Cc: martin rudalics, Emacs Devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 15:03 ` Juanma Barranquero
@ 2008-11-27 19:53 ` Eli Zaretskii
2008-11-27 20:24 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-11-27 19:53 UTC (permalink / raw
To: Juanma Barranquero; +Cc: rudalics, jasonr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 19:53 ` Eli Zaretskii
@ 2008-11-27 20:24 ` Juanma Barranquero
2008-11-27 20:40 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2008-11-27 20:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: rudalics, jasonr, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 20:24 ` Juanma Barranquero
@ 2008-11-27 20:40 ` Eli Zaretskii
2008-11-27 22:16 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-11-27 20:40 UTC (permalink / raw
To: Juanma Barranquero; +Cc: rudalics, jasonr, emacs-devel
> 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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 20:40 ` Eli Zaretskii
@ 2008-11-27 22:16 ` Juanma Barranquero
2008-11-28 8:36 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2008-11-27 22:16 UTC (permalink / raw
To: Eli Zaretskii; +Cc: rudalics, jasonr, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-27 22:16 ` Juanma Barranquero
@ 2008-11-28 8:36 ` Eli Zaretskii
2008-11-30 2:08 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2008-11-28 8:36 UTC (permalink / raw
To: Juanma Barranquero; +Cc: rudalics, jasonr, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-28 8:36 ` Eli Zaretskii
@ 2008-11-30 2:08 ` Juanma Barranquero
2008-12-10 10:57 ` Juanma Barranquero
0 siblings, 1 reply; 13+ messages in thread
From: Juanma Barranquero @ 2008-11-30 2:08 UTC (permalink / raw
To: Eli Zaretskii; +Cc: rudalics, jasonr, emacs-devel
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: filename coding systems and w32-*-file-name functions
2008-11-30 2:08 ` Juanma Barranquero
@ 2008-12-10 10:57 ` Juanma Barranquero
0 siblings, 0 replies; 13+ messages in thread
From: Juanma Barranquero @ 2008-12-10 10:57 UTC (permalink / raw
To: Emacs Devel; +Cc: Eli Zaretskii, Jason Rumney
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2008-12-10 10:57 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-11-25 1:38 filename coding systems and w32-*-file-name functions Juanma Barranquero
2008-11-27 13:41 ` martin rudalics
2008-11-27 14:24 ` Jason Rumney
2008-11-27 14:46 ` Juanma Barranquero
2008-11-27 14:59 ` Jason Rumney
2008-11-27 15:03 ` Juanma Barranquero
2008-11-27 19:53 ` Eli Zaretskii
2008-11-27 20:24 ` Juanma Barranquero
2008-11-27 20:40 ` Eli Zaretskii
2008-11-27 22:16 ` Juanma Barranquero
2008-11-28 8:36 ` Eli Zaretskii
2008-11-30 2:08 ` Juanma Barranquero
2008-12-10 10:57 ` Juanma Barranquero
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.