From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.bugs Subject: bug#18891: Doesn't handle pwd = /C: very well Date: Tue, 04 Nov 2014 20:36:38 +0100 Message-ID: <87k33alpvd.fsf@gmx.de> References: <87d293dtc5.fsf@gmx.de> <83lhnqvqt9.fsf@gnu.org> <87sihysszn.fsf@gmx.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1415130420 13582 80.91.229.3 (4 Nov 2014 19:47:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2014 19:47:00 +0000 (UTC) Cc: 18891@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 04 20:46:52 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1Xlk43-0000H4-Ee for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Nov 2014 20:46:51 +0100 Original-Received: from localhost ([::1]:42654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xlk43-0003BJ-1X for geb-bug-gnu-emacs@m.gmane.org; Tue, 04 Nov 2014 14:46:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43500) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xljuf-0002pt-Gj for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:37:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XljuY-0004Z3-Fk for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:37:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51951) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XljuY-0004Yz-Cs for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:37:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XljuX-0002vu-Og for bug-gnu-emacs@gnu.org; Tue, 04 Nov 2014 14:37:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 04 Nov 2014 19:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18891 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18891-submit@debbugs.gnu.org id=B18891.141512980411237 (code B ref 18891); Tue, 04 Nov 2014 19:37:01 +0000 Original-Received: (at 18891) by debbugs.gnu.org; 4 Nov 2014 19:36:44 +0000 Original-Received: from localhost ([127.0.0.1]:49160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XljuG-0002vB-4Z for submit@debbugs.gnu.org; Tue, 04 Nov 2014 14:36:44 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:59183) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XljuE-0002v3-AL for 18891@debbugs.gnu.org; Tue, 04 Nov 2014 14:36:43 -0500 Original-Received: from detlef.gmx.de ([87.146.57.22]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LzGV3-1Y7eWE12av-014RpQ; Tue, 04 Nov 2014 20:36:39 +0100 In-Reply-To: (Glenn Morris's message of "Tue, 04 Nov 2014 14:11:47 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-Provags-ID: V03:K0:CbcDz80GtRGEpcvYLV16wh81kdwH3OwKO1FSGWETZW/Db7TQH3j BMDiRQ7iTVifqrJL5j3ZgsPb1ipwP1DyD8WLu/mWgY+zbyYp88x+PZXpluAPWgBEFI9C2pI wFoTAho87zgbGSfobJ/yYqikqrbUvvkw5icA+s2uOqTTIDRtEeM6lUe86/mMgnXdffhlMPW qYkM6+zYPqaNdo+VhKYAQ== X-UI-Out-Filterresults: notjunk:1; X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95497 Glenn Morris writes: > I don't consider a performance penalty an undesired side effect, but > rather necessary to avoid a completely incorrect result, such as we have > in this case. The "unnecessary result" is an error in `file-attributes'. >> (substitute-in-file-name "/C:/$FOO") requires the expansion of >> $FOO. That's the task of Tramp, according to that file name. Nothing you >> can check before invoking Tramp, because you don't know the value of $FOO. > > Why can't it be checked before Tramp? > > What if "FOO = foo" in the local environment, and "/C:/foo" > is a real directory on the local machine? `substitute-in-file-name' is an operation supporting file name handlers. This handler must be called, instead of expanding an environment variable locally. That's the design, and the promise by the API. Everything could be changed, of course. But please then with a corresponding *design* change. And `substitute-in-file-name' was just the very first example which came to my mind, without thinking about seriously. There are many other operations supporting file name handlers, which must be investigated for this kind of changes as well. For the records: I do not oppose fundamentally such changes. I just resist to change something on-the-fly, without redesign. Best regards, Michael.