From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: testing for a remote file to include file on a Windows mapped drive Date: Tue, 22 Apr 2008 17:17:49 +0200 Message-ID: References: <87bq781bf7.fsf@gmx.de> <000a01c8a314$5fff7630$0200a8c0@us.oracle.com> <000d01c8a324$97820590$0200a8c0@us.oracle.com> <000f01c8a334$b2a40660$0200a8c0@us.oracle.com> <000101c8a37f$eeb543d0$0200a8c0@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1208877520 14793 80.91.229.12 (22 Apr 2008 15:18:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2008 15:18:40 +0000 (UTC) Cc: Eli Zaretskii , jasonr@gnu.org, michael.albinus@gmx.de, drew.adams@oracle.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 17:19:12 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JoKFY-0006aK-N5 for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2008 17:17:41 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoKEt-00043E-0e for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2008 11:16:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JoKEn-00042J-Ba for emacs-devel@gnu.org; Tue, 22 Apr 2008 11:16:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JoKEk-00041g-RW for emacs-devel@gnu.org; Tue, 22 Apr 2008 11:16:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoKEk-00041d-JO for emacs-devel@gnu.org; Tue, 22 Apr 2008 11:16:50 -0400 Original-Received: from mailrelay1.alcatel.de ([194.113.59.95]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JoKEY-0003C0-Iq; Tue, 22 Apr 2008 11:16:39 -0400 Original-Received: from slbhab.alcatel.de (slbhab.bln.sel.alcatel.de [149.204.63.218]) by mailrelay1.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id m3MFGY5L017667; Tue, 22 Apr 2008 17:16:35 +0200 In-Reply-To: (Stefan Monnier's message of "Mon, 21 Apr 2008 22:46:49 -0400") User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (hpux) X-Scanned-By: MIMEDefang 2.57 on 149.204.45.72 X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:95772 Archived-At: Stefan Monnier writes: >> So a file that does not have a handler is _never_ remote. > > That's irrelevant: look at the uses, and you'll see that most of them > use file-remote-p in the sense described in the docstring, so all that's > needed is to provide an implementation for the unhandled files. > > This may require some changes in file-relative-name, because this one > does use file-remote-p in a more specific way, but everything else I've > looked at uses file-remote-p as a way to test "fast&reliable or not". I have available a checkout from April 7th. Scanning lisp/*, there are 40 places file-remote-p is called. Let's not regard the 17 calls of tramp*.el, they could be replaced simply by another, Tramp internal, function. >From the other 23 calls, I would count 5 calls related to the question "Is the access slow"; the other calls are due to the file name handler thingies, which require another implementation of the respective functionality. And, if you say that the calls of file-remote-p shall be replaced by something else, which is closer to the file name handler functionality: which function do you have in mind? Back in February, you've spoken about file-local-name/unhandled-file-name. These functions don't exist (yet). Stefan, honestly: I don't understand why file-remote-p needs such a redefinition. I assume there is a plan behind, which we don't know. It would really be helpful if we could understand your intention of this change. One explanation, also in February, was that you want to have (file-remote-p "file:///toto/titi") => nil But with the same reasoning, you could say (file-remote-p "/sudo:$USER@localhost:/toto/titi") => nil And that doesn't work, IMHO. > Stefan Best regards, Michael.