Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file names

[Michael Mauger <michael@mauger.com>]

On Wednesday, July 1, 2015 10:14 AM, Ken Brown <kbrown@cornell.edu> wrte:

>
>
>On 6/29/2015 10:40 PM, Ken Brown wrote:
>> On 6/29/2015 8:59 PM, Michael Mauger wrote:
>>> branch: master
>>> commit 7466a4ded6ded0bea50151395b7a0fccc5dfd167
>>> Author: Michael R. Mauger <michael@mauger.com>
>>> Commit: Michael R. Mauger <michael@mauger.com>
>>>
>>>      Cygwin emacsclient handles w32 file names
>>> ---
>>>   lisp/server.el |    3 +++
>>>   1 files changed, 3 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/lisp/server.el b/lisp/server.el
>>> index 2007635..ce19b3c 100644
>>> --- a/lisp/server.el
>>> +++ b/lisp/server.el
>>> @@ -1167,6 +1167,9 @@ The following commands are accepted by the client:
>>>                    (let ((file (pop args-left)))
>>>                      (if coding-system
>>>                          (setq file (decode-coding-string file
>>> coding-system)))
>>> +                   (when (and (eq system-type 'cygwin)
>>> +                              (fboundp
>>> 'cygwin-convert-file-name-from-windows))
>>
>> There's no need for the 'fboundp ...' here;
>> cygwin-convert-file-name-from-windows is defined in all Cygwin builds.
>>
>>> +                     (setq file
>>> (cygwin-convert-file-name-from-windows file)))
>>>                      (setq file (expand-file-name file dir))
>>>                      (push (cons file filepos) files)
>>>                      (server-log (format "New file: %s %s"
>>
>> Are you sure that emacsclient will still handle ordinary Cygwin file
>> names properly after this change?  I'm concerned about file names that
>> contain characters from the (default) UTF-8 character set.  I'm not very
>> familiar with exactly how cygwin-convert-file-name-from-windows works,
>> but its name suggests that it should be given a file name that's
>> understood by Windows.
>
>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.
>
>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.  If you 
>look at the (very few) places in the emacs code where that function is 
>currently called, you'll see that the argument is indeed known to be a 
>Windows file name.
>
>Ken
>


While I think there may be legit concerns about the character encoding, 

the entire Cygwin environment is susceptible to such problems so I do 

not think it is a risky new exposure.  What this enables is to use the
cygwin'ified emacsclient to be used as a file handler under MSWindows.  

MSWindows passes the full file path to the emacsclient process and this
will translate the file name to the equivalent cygwin path. Passing a 

cygwin file name through this function seems to return the file name 

unmolested so it doesn't require a lot of guarding for file name syntax
before calling it (But I will defer to Ken who knows the internal 

workings of cygwin far better than I).

I use the above version of the patch on both cygwin and GNU/Linux ports
of Emacs daily.