On 3/8/2013 7:03 PM, Daniel Colascione wrote: > On 3/8/2013 7:03 PM, Daniel Colascione wrote: >> On 3/8/2013 1:25 PM, Daniel Colascione wrote: >>> On 3/8/2013 12:53 PM, Eli Zaretskii wrote: >>>>> Date: Fri, 08 Mar 2013 22:33:07 +0200 >>>>> From: Eli Zaretskii >>>>> Cc: 13907@debbugs.gnu.org >>>>> >>>>> 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 for finding that! I've been swamped this week, and I haven't been able to >>> do any investigation. I'll see whether I can come up with a fix this weekend. >>> >> >> The patch below resolves the issue for me. Assuming it's acceptable, where >> should I install it? bzr trunk revision 111999 resolves this bug, the title-bar bug, and a few others relating to mismatches between the Windows GUI encoding and the Cygwin system encoding. Ken, it's probably this change that you want to backport to your Cygwin package.