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 22:29:20 +0200 Message-ID: <87ej8zymsf.fsf@gmx.de> 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 1208809712 1207 80.91.229.12 (21 Apr 2008 20:28:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Apr 2008 20:28:32 +0000 (UTC) Cc: Eli Zaretskii , 'Jason Rumney' , Drew Adams , 'Emacs-Devel' To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 21 22:29:06 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 1Jo2d1-0003St-1h for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 22:28:46 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jo2c7-0003J1-H6 for ged-emacs-devel@m.gmane.org; Mon, 21 Apr 2008 16:27:47 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Jo2c2-0003Io-Mp for emacs-devel@gnu.org; Mon, 21 Apr 2008 16:27:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Jo2bx-0003IZ-6w for emacs-devel@gnu.org; Mon, 21 Apr 2008 16:27:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Jo2bx-0003IW-1L for emacs-devel@gnu.org; Mon, 21 Apr 2008 16:27:37 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1Jo2bt-0003iT-VR for emacs-devel@gnu.org; Mon, 21 Apr 2008 16:27:37 -0400 Original-Received: (qmail invoked by alias); 21 Apr 2008 20:26:56 -0000 Original-Received: from p57A2189C.dip0.t-ipconnect.de (EHLO arthur.local) [87.162.24.156] by mail.gmx.net (mp023) with SMTP; 21 Apr 2008 22:26:56 +0200 X-Authenticated: #3708877 X-Provags-ID: V01U2FsdGVkX18JURcKr6UJfTAWdYgexGOixqe2kABxHoJ7UflIe+ etZXDlPmP7g1I4 In-Reply-To: (Stefan Monnier's message of "Mon, 21 Apr 2008 12:17:01 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:95701 Archived-At: Stefan Monnier writes: > I know it started as a file-name-handler-only thingy, but its new > docstring and this discussion shows that it goes further than that. Please don't let us decide because of the docstring. It was changed not so long ago, without a corresponding implementation, as Eli has shown. So it represents your intentions for file-remote-p - which I do respect, but which I don't share (yet). >> That's why I am not creative enough to see how to implement your >> interpretation of that function. > > Maybe you're thinking of "how can I implement it in Tramp" whereas the > Tramp-side of that function is already implemented and this thread is > not only concerned about its behavior for non-file-name-handled files. I wouldn't have so much problems with your proposal if file-remote-p would be used just for the decision "Is the access fast or slow". But that's not the only use case for file-remote-p. This function is used also in cases for the decision "Do I need special handling for accessing this file". Most cases, this question doesn't arise, because the file name handler functions decide it silently. But there are cases, those functions are not sufficient. > Stefan Best regards, Michael.