From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Mauger Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 7466a4d: Cygwin emacsclient handles w32 file names Date: Thu, 2 Jul 2015 02:28:30 +0000 (UTC) Message-ID: <1279932406.858501.1435804110079.JavaMail.yahoo@mail.yahoo.com> References: <5593F5BC.4030602@cornell.edu> Reply-To: Michael Mauger NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1435804175 19154 80.91.229.3 (2 Jul 2015 02:29:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Jul 2015 02:29:35 +0000 (UTC) Cc: "emacs-devel@gnu.org" To: Ken Brown Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 02 04:29:24 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZAUFf-0003kc-Pj for ged-emacs-devel@m.gmane.org; Thu, 02 Jul 2015 04:29:24 +0200 Original-Received: from localhost ([::1]:33521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAUFe-0002WI-C0 for ged-emacs-devel@m.gmane.org; Wed, 01 Jul 2015 22:29:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAUFZ-0002W2-SH for emacs-devel@gnu.org; Wed, 01 Jul 2015 22:29:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZAUFT-00035c-6k for emacs-devel@gnu.org; Wed, 01 Jul 2015 22:29:17 -0400 Original-Received: from nm25-vm1.bullet.mail.bf1.yahoo.com ([98.139.212.155]:53186) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZAUFT-00035I-2A for emacs-devel@gnu.org; Wed, 01 Jul 2015 22:29:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435804151; bh=zZKlRa2oAagrBYoIyPr+ZvpFEn56k1bpjUsB7wChTco=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=GOZbHUg8REhe4UWgzm1VbSTvxBn1y8HMbV2w1XBRCjVfsPwelIo32ABSHpMT7Jkj4rqOxRYOY+tkaRHkeoj9isWxtPbe4xdCDFnVWj769rUtwmE9mzLnuL9iOGZyzH7bn0eMDm3FbitSkAYRG2DdyBR2487AEoEC7TrOf5YHC1mz8EuKQ0tqMpELz5cFReRkEFaPt6DYaz6CR5NBbfllurQuRGTwjY7gOOs7sdLkcGBIKlxRUd90XmRM7icHum6CTkOO5LiDop+zqID6JY5FRBacvd32ZT13SrzsT3i7tl4GiioQB4gFXTC+e8Id/wjKNhEXIVdHy+U0rl+RJY2Hrg== Original-Received: from [98.139.170.180] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2015 02:29:11 -0000 Original-Received: from [98.139.212.212] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jul 2015 02:29:09 -0000 Original-Received: from [127.0.0.1] by omp1021.mail.bf1.yahoo.com with NNFMP; 02 Jul 2015 02:29:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 864255.79536.bm@omp1021.mail.bf1.yahoo.com X-YMail-OSG: pTmbMrMVM1lI72iGIxEmufs2dyM2smXkrxl7Sw6zL3EhxykkEfXWikSWgVQgAsC N0jDePmuYexcDUg6XNbCkBV6GEjerL8mN2U5H63BxkP7gvtV.CGQZCPlYp0NKBU.wipzqy8Gswh0 IshaOobx9MKJUe8hAdNQg_CWpx0IPEqrE0RLvUta5vv6XW8nlFbytwA4HjoZ5ffCsqVr_fT8O.Gu b35vEhOLdHu8JB_K1daXSCEJWmd_UpAc43VermtgQ.hOCqCyUjSwQIwkpTKXSQ4mK3B4eOxqI2I0 4TU422GhbdMfoTsHuH6xa.TeyZMQZzVAvqTsnz0y5FQ2eXZKXsDuqbZlLCyOr9OMOCJ8_q1Ts6hx o91R4yvOglwgrLSh3pDK8waBCeJe1uj8mKrzgWGXIkDphWjKG9gDAP3BFMDOSmOPU3vMmbOZhZNI q6RAzIWQBpI1hkI0zhyf7SCmMxgHKKF.B.2mCOptnijI2vJLBYeAmLkdwk15z_MrK5M_JwT3gAiH GRv_1 Original-Received: by 76.13.26.156; Thu, 02 Jul 2015 02:29:10 +0000 In-Reply-To: <5593F5BC.4030602@cornell.edu> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 98.139.212.155 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:187705 Archived-At: On Wednesday, July 1, 2015 10:14 AM, Ken Brown 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 >>> Commit: Michael R. Mauger >>> >>> 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.