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: Mon, 21 Apr 2008 17:13:32 +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 1208790977 16496 80.91.229.12 (21 Apr 2008 15:16:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2008 15:16:17 +0000 (UTC) Cc: 'Emacs-Devel' , Drew Adams , 'Jason Rumney' To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 17:16:48 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 1JnxjX-0007Fi-Gz for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 17:15:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jnxht-0002IH-Mx for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 11:13:25 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jnxhp-0002I1-Sl for emacs-devel@gnu.org; Mon, 21 Apr 2008 11:13:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jnxhi-0002H7-EF for emacs-devel@gnu.org; Mon, 21 Apr 2008 11:13:19 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jnxhi-0002H4-82 for emacs-devel@gnu.org; Mon, 21 Apr 2008 11:13:14 -0400 Original-Received: from mailrelay2.alcatel.de ([194.113.59.96]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JnxhH-0005Yh-P1; Mon, 21 Apr 2008 11:12:50 -0400 Original-Received: from slbhab.alcatel.de (slbhab.bln.sel.alcatel.de [149.204.63.218]) by mailrelay2.alcatel.de (8.13.8/8.13.8/ICT) with ESMTP id m3LFCHYF002544; Mon, 21 Apr 2008 17:12:18 +0200 In-Reply-To: (Stefan Monnier's message of "Mon, 21 Apr 2008 10:33:57 -0400") User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (hpux) X-Scanned-By: MIMEDefang 2.57 on 149.204.45.73 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:95637 Archived-At: Stefan Monnier writes: Hi Stefan, >> * file-remote-p returns t, if a file is not directly accessible by >> underlying operating system's means. Such files always need some >> special file name handler functions in Emacs for proper >> handling. Such (absolute) file names cannot be used literally >> outside functions, which support file name handlers. > > Please read the docstring of file-remote-p, it has "nothing" to do > with the above. What you describe can misclassify both ways: remote > access can be provided by the OS (using NFS/AFS/SSHFS/...), and local > access can be provided by file-name-handlers (e.g. file:// URLs). We have had this discussion already weeks ago, and I couldn't convince you. So I shouldn't try it again. I just see this function from a practical point of view, providing an implementation for a special case (Tramp syntax). file-remote-p is based on file name handler functions, that means it works over the file name syntax. That's why I am not creative enough to see how to implement your interpretation of that function. I'm keeping quiet now. > Stefan Best regards, Michael.