From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: substitute-in-file-name is not distributive Date: Wed, 10 Oct 2012 10:40:34 -0700 Message-ID: <5075B312.8060409@dancol.org> References: <50750955.4020802@dancol.org> <83k3uyz6mi.fsf@gnu.org> <5075A6D5.1070903@dancol.org> <83a9vuz1o1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8C55071F248893A284EC941F" X-Trace: ger.gmane.org 1349890855 25533 80.91.229.3 (10 Oct 2012 17:40:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Oct 2012 17:40:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 10 19:41:00 2012 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 1TM0HD-0006Rr-Hn for ged-emacs-devel@m.gmane.org; Wed, 10 Oct 2012 19:40:59 +0200 Original-Received: from localhost ([::1]:56611 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM0H7-0005Hy-7Z for ged-emacs-devel@m.gmane.org; Wed, 10 Oct 2012 13:40:53 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM0H4-0005HY-8g for emacs-devel@gnu.org; Wed, 10 Oct 2012 13:40:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TM0H2-0002PD-D2 for emacs-devel@gnu.org; Wed, 10 Oct 2012 13:40:50 -0400 Original-Received: from dancol.org ([96.126.100.184]:34557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TM0Gu-0002E2-DO; Wed, 10 Oct 2012 13:40:40 -0400 Original-Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[192.168.1.2]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TM0Gt-0004ra-Ar; Wed, 10 Oct 2012 10:40:39 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 In-Reply-To: <83a9vuz1o1.fsf@gnu.org> X-Enigmail-Version: 1.4.4 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 96.126.100.184 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:154275 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8C55071F248893A284EC941F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/10/12 10:18 AM, Eli Zaretskii wrote: >> Date: Wed, 10 Oct 2012 09:48:21 -0700 >> From: Daniel Colascione >> CC: emacs-devel@gnu.org >> >> Cygwin itself deals adequately with being given Windows paths --- >> it's Emacs that could handle them more elegantly. It's important to note that the Cygwin and Windows path trees can be completely disjoint. Cygwin has its own mount table. I have my system configured so that there's a close resemblance between the two hierarchies, but it doesn't have to be so. c:\foo could map to /qux/bar/spam/blah. > If Cygwin can handle these file names (which is what I thought was the > case), why not change expand-file-name so that the DOS_NT parts there > are also compiled in for Cygwin? >=20 > Hmm... but then typing "C-x C-f /foo/bar TAB" will prepend a drive > letter, perhaps, which is not what you want. Right. I suppose I could change the code so that we understand both kinds of path but prefer POSIX ones, but the approach I have in mind feels more elegant. What happens with my s-i-f-n handler is that read-file-name accepts Windows paths and (when completion works) completes them, but as soon as the user accepts a path, it's converted to a Cygwin path and remains as a Cygwin path through the rest of Emacs. It's pretty elegant in practice. If we do nothing, Emacs treats Windows paths as opaque blobs. From Emacs' point of view, if you try to find-file c:\etc\passwd when default-directory is "/etc", you're asking Emacs to find the file "/etc/c:\\etc\\passwd". That's not right. There are three approaches to solving the problem: 1) Modify the DOS_NT code so that Cygwin Emacs can parse Windows paths. Pass all paths to Cygwin and let Cygwin sort them out. This approach will configure the hell out of other bits of code that assume that we have Windows paths IFF (memq system-time '(windowsnt dos)). It also complicates file-directory-name and friends. 2) Explicitly reject Windows paths and provide a way for the user to trigger path conversion. This approach strikes me as inconvenient. 3) Use a s-i-f-n hook to convert paths to Cygwin ones. This approach works well enough aside from the completion breakage. One way to deal with the completion problem would be to build completions based on the *Windows* path, not the Cygwin path, but it wasn't apparent to me how you could convince the code to do that. There's no file-name-handler-alist handler for "build me a set of completions, but before you call substitute-in-file-name." --------------enig8C55071F248893A284EC941F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlB1sxIACgkQ17c2LVA10Vv8/wCeNtFGKMdrjHZzNWbKVjki2qML f+cAoJjOek0vmpp5dOjCyW4RhMcTt8NU =Jccp -----END PGP SIGNATURE----- --------------enig8C55071F248893A284EC941F--