[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file na
From: |
Eli Zaretskii |
Subject: |
Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file names |
Date: |
Wed, 01 Jul 2015 18:47:55 +0300 |
> Date: Wed, 01 Jul 2015 10:14:20 -0400
> From: Ken Brown <address@hidden>
> Cc: address@hidden
>
> I've tested this a little with file names containing UTF-8-encoded
> Chinese and other non-ASCII characters, and it appears to work OK. But
> I *think* it only works because of accidental implementation details of
> cygwin-convert-file-name-from-windows (and the underlying Cygwin
> function cygwin_conv_path). Basically, it seems that these functions
> don't actually try to do any conversion if they are given a multibyte
> string instead of the expected UTF-16 string.
That was also my conclusion.
> So even though this change *might* be harmless, I think it could lead to
> bugs later if implementations change. I don't think
> cygwin-convert-file-name-from-windows should be called on a file name
> that is not known to be a (UTF-16-encoded) Windows file name.
The UTF-16 encoding is not an issue, because
cygwin-convert-file-name-from-windows calls to_unicode to ensure that.
I think this code needs to look at the result of expand-file-name for
the file and the default directory in effect, and check whether the
result begins with a drive letter. If it does, it should call
cygwin-convert-file-name-from-windows.