[Top][All Lists]

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

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

From: Ken Brown
Subject: Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file names
Date: Wed, 01 Jul 2015 10:14:20 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0

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 <address@hidden>
Commit: Michael R. Mauger <address@hidden>

     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
+                   (when (and (eq system-type 'cygwin)
+                              (fboundp

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.


reply via email to

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