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: Tue, 30 Oct 2012 13:12:36 -0700 Message-ID: <509034B4.7020301@dancol.org> References: <50750955.4020802@dancol.org> <5088B1F4.90302@dancol.org> <508F5319.4090604@dancol.org> <508FEBD8.8090505@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA6D5B400D4E010B1ACD306A4" X-Trace: ger.gmane.org 1351627976 18089 80.91.229.3 (30 Oct 2012 20:12:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2012 20:12:56 +0000 (UTC) Cc: Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 30 21:13:02 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 1TTIBI-00039A-2L for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2012 21:13:00 +0100 Original-Received: from localhost ([::1]:55308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTIB9-0003dK-HA for ged-emacs-devel@m.gmane.org; Tue, 30 Oct 2012 16:12:51 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTIB1-0003c2-NC for emacs-devel@gnu.org; Tue, 30 Oct 2012 16:12:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTIB0-0006xW-9T for emacs-devel@gnu.org; Tue, 30 Oct 2012 16:12:43 -0400 Original-Received: from dancol.org ([96.126.100.184]:44835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTIB0-0006xN-3D for emacs-devel@gnu.org; Tue, 30 Oct 2012 16:12:42 -0400 Original-Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[0.0.0.0]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TTIAy-00075s-RR; Tue, 30 Oct 2012 13:12:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 In-Reply-To: X-Enigmail-Version: 1.4.5 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:154592 Archived-At: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA6D5B400D4E010B1ACD306A4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 10/30/2012 11:58 AM, Stefan Monnier wrote: >>> Hmm... that's odd. Can you give me some details: >>> - tell me exactly which text you typed in the minibuffer. >> I typed "c:\bin\" in the minibuffer and hit tab. After hitting tab, th= e >> minibuffer contained "c:/usr/bin", with point at the end. >>> - also tell me how the rfn-eshadow highlights the file name at each s= tep. >> Now that you mention it, I do see that the leading "c:" in the >> minibuffer is highlighted. That explains why we're substituting >> "c:/usr/bin" and not "/usr/bin". >=20 > Right. > The "c:" is highlighted because (s-i-f-n "c:\\bin") =3D (s-i-f-n "\\bin= "). > Now the problem is that when you replace \bin by /usr/bin suddenly that= > same rule doesn't apply any more. >=20 > Hmm... I think the core of the problem here is that minibuffer > completion is actually only performed on "the current field" which is > usually the whole minibuffer content, but not with rfn-eshadow. > To fix this, we should invert the relationship between > minibuffer-complete and completion-in-region (i.e. minibuffer-complete > should call completion-in-region rather than the other way around). > This would probably be a good change, but we can't do it for 24.3. >=20 > You should be able to work around this problem by removing "field > shadow" from file-name-shadow-properties. Doing that globally will break normal file shadowing, which we want to ke= ep working. >>> Right. BTW I'm not convinced this is the right pattern to use for yo= ur >>> file-name-handler. I think catching "\\[a-zA-Z]:" or something along= >>> these lines might be a better choice. >> Not all paths I want to catch are absolute, >=20 > Why not? Which non-absolute file names [we only use "path" for lists > of directories, as in $INFOPATH] would you need/want to rewrite? > Do you just want to replace \ with / in relative file names or is there= > more to it? Remember that the mapping of Cygwin names to Windows ones is *arbitrary*.= Any approach that's based on "replacing slashes" is prone to failure. To a Cy= gwin Emacs, it's as if Windows file names were written in encrypted EBCDIC. Em= acs must treat Windows filenames as opaque blobs to be passed to cygwin-convert-path-from-windows. Relative file names come up during builds. Say I'm editing foo.c and the = build system outputs "objchk\x86\foo.o" in some message: I want to be able to a= ppend this relative path and get back a full Cygwin path. >> Even "absolute" paths can be drive-letter-relative and begin with >> a simple backslash. >=20 > Right, that's what triggers the above problem. >=20 >>> BTW, does Cygwin allow backslashes in file-names or does it interpret= it >>> as a separator, like Windows does? >> Cygwin interprets backslashes as separators. >=20 > So Cygin itself treats "\\bin" and "/bin" as equivalent No --- Cygwin treats "\\bin" just as Windows would: it's a drive-letter-r= elative Windows path. "/bin" is a perfectly normal POSIX path. > , but your > rewrite rules treat "\\bin" as a Windows file name and rewrite it to > "/usr/bin"? Yes. > If you limit yourself to: > - rewrite "\\`[a-zA-Z]:" to "/cygdrive/c" (regardless if it is followed= Not all Cygwin installations use "cygdrive". Every instance of the word "cygdrive" in Emacs is a bug. > by backslashes or forwardslashes). > - rewrite \ to / everywhere. > This should cover the main needs without tripping over the above proble= m. This approach doesn't work either. The resulting POSIX file names alias t= he same files named with mounted Cygwin paths. "/cygdrive/c/bin/ls.exe" and "/bin/ls.exe" refer to the same file, but be= cause the paths differ, Emacs will consider these as two distinct files. Also, = access semantics differ between drive-prefix-prefixed paths and native Cygwin pa= ths. --------------enigA6D5B400D4E010B1ACD306A4 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 (Cygwin) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCQNLcACgkQ17c2LVA10VuqJQCfRwS5r2b3XMPkN0O75x+vf4m4 I1UAnRIvSBXlAZ0n5RnJR9y1i05+dEZi =ax7m -----END PGP SIGNATURE----- --------------enigA6D5B400D4E010B1ACD306A4--