[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non

From: Ken Brown
Subject: bug#13907: 24.3.50; cygw32 build mishandles drag-n-dropped file with non-ASCII characters in name
Date: Fri, 08 Mar 2013 16:03:25 -0500
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2

On 3/8/2013 3:53 PM, Eli Zaretskii wrote:
Date: Fri, 08 Mar 2013 22:33:07 +0200
From: Eli Zaretskii <address@hidden>
Cc: address@hidden

And one more question: what is the value of file-name _before_ it is
passed to cygwin-convert-file-name-from-windows?  Does it perhaps
already have the U-umlaut replaced by a blank?

I think the problem is on the C level, not on the Lisp level.  Take a
look at w32term.c:construct_drag_n_drop -- it uses ANSI version of
DragQueryFile to get the file name, then decodes it by DECODE_FILE.
But DECODE_FILE uses UTF-8 in the cygw32 build, so this is
inappropriate for decoding file names that come from Windows APIs.

Instead, in the cygw32 build, construct_drag_n_drop should use
DragQueryFileW and convert the file name to the internal Emacs
representation using from_unicode.

Thanks! You solved it while I was trying to get the answers to your questions. For the record, here's what happens in my example:

The value of file-name that is passed to cygwin-convert-file-name-from-windows is "C:\\cygwin\\tmp\\\334.txt". The converted file name is then "/tmp/ .txt".

I'll leave it to Daniel to fix this, since it's his code.

Thanks again, Eli.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]